ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>CHRIS DISSPAIN: We will start in a couple of minutes, ladies and gentlemen.

Good morning, everybody.

>> Good morning.

>>CHRIS DISSPAIN: Thank you very much, Bernie. Welcome to the sort of second session but the first session in the room of the ccNSO meeting, which is our now traditional discussion with the chairman of ICANN and the CEO of ICANN and that is also traditional in these circumstances. I will hand it over to Paul and he can lead this discussion in any way he chooses.

>>PAUL TWOMEY: Thanks, Chris. One of the themes for this week in terms of operations is as much as possible moving away from sort of the constant presentation of PowerPoint slides that all look the same, and if you have been in three meetings, you are getting sick and tired of seeing the same slides. I can tell you I am sick and tired of presenting them so there are no slides.

I will talk to a couple of topics and see what issues there are for discussion. I think that's where we really want to take things more.

In no particular order, the eIANA project is well on the way. We are hoping that -- I have got David Conrad in the back of the room looking very nervous now because he has got no idea what I am going to say and he doesn't trust what I say any way. David is looking nervous.

We understand that we expect major stage of the software development to be completed by the end of May. I am not exactly certain where implementation will come in. To give you some sense, that is progressing.

We will be doing quite a lot -- there will be quite a lot of testing on that once it's done. And that will include attack testing as well as probably code testing. We will start talking to David about that in ways of testing of code, obviously for security reasons. That is progressing well.

And I think the relationship with NASK is working very well and we are very pleased with the intensity and integrity of their work.

We -- I have asked David, Kim and others, Barbara, in IANA to at this stage also now start thinking -- they have been thinking a lot but I am asking them to think again and take up authentication regimes for the eIANA. Can I just make a personal statement on this so David can decide at some time in the future tell me I was wrong.

It has always been my view about the IANA zone file that it's got risk elements similar to the international banking system. The international banking system to a degree has at the heart of its risk model that nobody trusts anybody. So that's my first assumption, is I don't trust you. Now, you have to prove that I should trust you a little bit. And there are gradations that, I think I trust you which ends up with gradations of types of interaction. If you want to be on the Swift Funds Transfer system, not everybody is on that system. If you want to be on the New York Interchange, not everybody is on that. There are gradations of who people trust of levels of financial interaction.

I think it's inevitable we will have the same sort of thing with the zone file. I think it is inevitable -- this will not be a -- any sort of pejorative statement about individuals or anything but I think it will have to be some layered mechanism of authentication with the growing assumption that we don't trust you. That's not a personal statement, but it is an authentication statement.

So David and Kim and Barbara will talk more about that. Just as in banking, you end up with some people who have to -- (cell phone ringing) -- I thought only I did that sort of thing.

Just as in banking, you end up with things like letters of credit in some markets and full cash transfers in others. We will without a doubt for some ccs and for some parts of the world have letters of credit and potentially for others we might be able to move to funds transfer. I want to set expectations about authentication regimes.

Vint, you wanted to say something?

>>VINT CERF: It is an interesting way to characterize things as I don't trust you or do I do trust you or I trust you a little bit. The biggest concern, I think, I would have is making automatic changes to the zone file through eIANA is that someone else is pretending to be you or someone in your organization has decided to cause a lot of trouble.

So those are the two biggest concerns I would have. Now, interestingly enough, the last one, someone in your organization has decided to cause a lot of trouble could happen today, quite independent of eIANA. Sir?

>>PAUL TWOMEY: It does.

>>VINT CERF: It is very clear that we have sort of all cases to be worried about.

The automatic process is more scary in the sense that it could propagate more quickly and without necessarily a lot of human observation. And so all of these concerns are intended to protect the integrity of what each of the ccTLD operators wishes to have exhibited in the zone file.

So I hope no one takes any offense at all at a concern for strong authentication of these transactions. It is intended to make sure that what you intend is what actually happens.

>>PAUL TWOMEY: I think the other side of this will be probably also move much more to promotion and publication of the results of the change which happens now already but happens -- could be amplified which is the second part of sort of closing the loop on authentication.

So we try as hard to have layered acceptance of risk authentication with dot zz but then we also make certain the result is published fairly widely so if actual manager dot zz now finds out former staff member has done something in their name, it is easy for them to see it and get the correction made.

So that's just sort of a personal perspective. As I said, David and team will keep working that through and may end up with different answers than what I just said but I wanted to give you an expectation about management.

The broader -- another topic that I would like to just draw your attention to and would like to think about and respond to, the President's Strategy Committee is -- we have a series of reviews underway as parts of the organization. There will be review for the GNSO, there will be review for the at-large, there will be review for the NomCom. There will be review for the board. There will be an upcoming review of the root server Advisory Committee. You all have interests in different ways about that. I exhort you to give input to those.

The last one in particular I suspect is one that you will have an interest in.

But we also have a sort of broader view of what are some of the strategy issues facing the whole ICANN community, and that has been posted -- it has been a process for the last 12 months of the President's Strategy Committee -- I'm sorry, Chris -- and you may want to look at that on the Web site and see whether you have got responses or thoughts about that. The board is going to have to consider what it does in response to that over the next little while. And so feedback on that is going to be valuable.

Other topics that are being discussed this week which obviously have great interest, IDNs and DNSsec. Maybe I will make the following comment on IDNs.

At an ICANN as a whole perspective on IDNs, there are several things we think are important. First of all, you will find that ICANN -- we are not having a discussion about if. We are having a discussion about when, okay? If you follow closely this topic over the last years, particularly in some of the technical communities, there have definitely been people who have had more heavy conversation about "if." So, first of all, the ICANN discussion is about "when." The second part of that is that there are -- as Tina reported yesterday, there are a series of dependencies that presently faces ICANN to get the work that we've outlined finished. Those dependencies are work undertaken by the IETF and its interplay with the Unicode consortium.

Further, there's a review to be done by the Security and Stability Advisory Committee. There will be a -- before anything is put in the root, the USG, I expect, will want -- United States Government, the Department of Commerce will want to assure there has been a security check and they have already indicated that from their perspective, which is completely sensible.

And the other dependencies, the work being done by the generic Name Supporting Organization and your own organization about the policy implications that are around the introductions. I don't think personally there is any reason why we can't have some sort of tiered introduction to IDNs, but not all these levers are in our hands. I am interested to hear your issues on the CCs. Perhaps it is worth it.

I will make this observation. From my sins and doing a lot of travel as president of ICANN and invariably when I have a conversation about IDNs in a country essentially what I am really hearing it, please, I want to use my character set on my networks, okay?

Now, that's obvious and fine, but unfortunately that's not the ICANN mandate. We actually have to worry about a single global interpretable Internet which does mean we have to worry about all character sets or languages, if I can use loose language.

And we have to worry about it working on all networks. And that is causing some delay. I know that causes some frustration for people. I understand the push at the local level, please give me my local language and my local -- so I can use my local networks.

But if we are going to have a single interpretable Internet, we actually have to take a little bit more time to ensure that we get a nice solution.

>>CHRIS DISSPAIN: Can I maybe just give you a very brief update on where we've got to. We will is another session on this -- on dot IDN ccTLDs tomorrow.

But following the Sao Paulo meeting, the board asked the GAC and the ccNSO to come up with an issues paper. The current status of that is that we have a first draft about which we met yesterday jointly with the full GAC and the full ccNSO. The likelihood is that first draft will be published for comment within our own environments although it will be open for comment from other areas, too.

And then a second draft prepared and hopefully ratified, agreed, whatever in Puerto Rico and given to the board.

What's abundantly clear is that there are lots and lots of policy issues that need to be sorted out. One of the major starting points which we discussed at some length yesterday is should we consider going down the mandated list route because currently effectively there is a mandated list of ccTLDs, ISO through 166. Should we consider going down the mandated list root of having a mandated list for every character set or should we go down -- let's go out and let everyone choose.

The issue as it interfaces with the gTLD community is very significant. What we call IDN ccTLDs, they call reserved names because they need to reserve them in the gTLD space. And what we call -- we need the reverse. We need to make sure that everything is reserved. And you can't -- and it is not really enough to say well, you know, Australia probably doesn't need dot au in Chinese characters. It may well not but that doesn't mean it won't in 30 years' time.

So you need to make a decision about whether you bother about the fact you need it in 30 years' time or do you say there it is, it is listed, you can't have it, you have no reason to have it but it is there in the same way you reserve country names in new TLDs at the second level, I think.

>>VINT CERF: Yes. Although the reservation in that particular case is quite restricted to the strings that appear in the 3166-1 tables.

>>CHRIS DISSPAIN: Exactly.

>>VINT CERF: The Roman character representations in English. And if I remember right, in French are both reserved or is it only the English?

>>PAUL TWOMEY: It is just the two-letter code, so it is just the two Roman characters.

>>VINT CERF: No, no. We also constrained the names to be reserved so that we don't have people putting those strings into --

>>PAUL TWOMEY: I don't know.

>>VINT CERF: Whether it is both English and French?

>>VINT CERF: There is a hand up back there.

>> (inaudible).

>>CHRIS DISSPAIN: Can we have a little more volume, please? We don't need a microphone. They can't hear us at the back.

>>VINT CERF: That's because they don't have ears?

[ Laughter ]

Do you have ears back there in the rear?

>>CHRIS DISSPAIN: Now, that is loud. That's the sort of area that we're looking at. It's going to be -- it doesn't surprise me that you are saying there are a number of hurdles that you need to overcome in order to get to the point where you can move forward with this.

I suspect our issues paper is probably going to give you some more that you need to come to terms with.

>>VINT CERF: Could I just comment on that? I have been trying to accumulate lists of issues that arise with regard to IDNs and ccTLDs and I don't have a complete list at all. But the idea of a mandated list, of course, has this question of who got to mandate it and on what grounds and what if you don't like the mandate? The other side of the coin is that if each party who is authorized to have a ccTLD chooses whatever they want, what if some of the other parties object? How would resolve that and who is responsible for resolving it? As a board member I am always eager to find somebody else to make that hard decision rather than have the board have to decide.

So if there is a mechanism for resolving disagreements as to what IDN ccTLDs will be acceptable to everyone, it would be important to say what that is.

There is also a question of how many of these iccTLDs should be permitted per country or per authority. Obviously, if you -- if all the languages of the country already are covered by the existing ccTLD that's registered using Roman characters, some people might argue well, then you don't need another one. Others might argue, I have people who speak other languages in my country. I have people in the rest of the world who want to refer to things in my country and they want country codes that are expressible in other character sets so we haven't resolved that and it needs to be sorted out.

I want to emphasize Paul's implicit comment that the interoperability of the system has to be global, that the domain name system is intended to work everywhere. No matter whose network you are on if there is a domain name containing an IDN somewhere, it needs to work everywhere, not just in the networks that might be local to a particular country.

And, finally, as far as issues go, I wonder if anyone here in the ccNSO community has thought about the abuse that is apparently waiting to happen for the Punycoded representation of IDNs. What we are discovering is that you can work backwards from a string that starts out XN-- and then some ASCII characters. It is a fact that some of the browsers, some of the e-mail systems are actually going to display not Unicode, not UGF8 but ASCII Punycode strings.

So if you look up -- if you do a reverse mapping of XN--Coca-Cola, for example, that actually turns into a string of characters in Unicode. There might be some people who would object to the string XN--Coca-Cola because in fact it will appear in some browsers and it will appear in some e-mail systems.

That's another example of a problem and issue that has to be resolved. How will we deal with disputes over deliberate registrations of strings whose Punycode representation is of interest because it might be made visible?

>>CHRIS DISSPAIN: Absolutely. Vint, I think we could -- I will happily give you a list of all the queries and questions we've currently got and we don't think we are anywhere near completed. We don't have any answers, just a lot of questions.

>>VINT CERF: Having a list of issues is tremendously value. Having a sense for who might be able to attack the issue or where is the responsibility for resolving the issue would also be tremendously useful. It may be that some of the issues are not resolvable even within the ICANN framework.

>>CHRIS DISSPAIN: Exactly. And just to take one particular point that you raised about the mandated list or not, I think -- and I have not yet formed a personal opinion about the right way to go. As a starting point we can all say that's how it is done now. We did not choose dot AU. Dot AU was from the ISO list. So the cc community generally -- I am sure there are -- this is not an overall statement. But generally is used to the fact that there is a representation to the country that some is more meaningful than others.

>>VINT CERF: Yes. But before you decide that you should adopt that particular machinery, you should keep in mind where it came from.

>>CHRIS DISSPAIN: Oh, yes.

>>VINT CERF: You understand it was more or less arbitrary set of symbols chosen by the statistics office in the United Nations and is now managed by an ISO group, 3166 management committee. It is not 100% clear to me that they would want to take on the task of creating or maintaining another list of symbols. So you might want to think carefully about what the implications are of adopting the present mechanism because you will be asking it to do something it didn't do before.

>>CHRIS DISSPAIN: Yes, I agree. We, in fact, discussed that at some length yesterday and very nearly came to blows.

[ Laughter ]

That's true, sadly. But, yes, we are aware of the difficulties and we are trying to work our way through it.

If I can move on to something else.

Paul, have you gone through your list? Okay.

There is an awareness in the community at least among some people that the U.S. government has expressed not publicly but has nonetheless expressed the intention that it would be the sole signor of the root for purposes of DNSsec. Some of us are aware of an existence of a report that effectively advises them on how they might do that, should they decide to do that.

You will not be surprised to hear that that does not sit very well with members --

>>VINT CERF: I'm shocked.

>>CHRIS DISSPAIN: Yes, exactly. With members of the ccTLD community and I just wanted to raise it and say that perhaps the time has come for us to start -- us being all of us not just the CCs to start working out a mechanism by which the very least we have a repository for the keys for the top levels and the root itself maybe can be subsumed into that particular repository.

>>VINT CERF: First of all, I'm a strong proponent of DNSsec, I think that no matter what you do, we do have to sign the -- otherwise, none of this is very effective, and third, I'm not necessarily convinced by the paper that was distributed that the only options for signing the root zone are contained in that paper.

To be fair to the people who produced the paper, they were asked to produce that paper and they were given a set of constraints, and the constraints are reflected in the choices that are shown in that paper for signing the root zone file. I would find it very useful if the ccNSO, as a community, were to express either concerns about the proposal or alternatives that they thought would be fully -- or even more acceptable. I think that your voices should be heard.

>>PAUL TWOMEY: I agree with what he said.

[Laughter]

>>CHRIS DISSPAIN: I don't know if there are any government people in the room, but do we know whether the government -- the GAC are aware of this particular --

>>PAUL TWOMEY: I think this is the first communication we have received today of members of the community being aware of that -- of that document. I haven't heard anything from other -- from governments. But that document, I should -- that document was distributed amongst some set of technical people for review and it doesn't surprise me that it's begun to percolate more widely, but --

>>CHRIS DISSPAIN: The expression is "leak" I think rather than "percolate." "Percolate" implies it's bubbled to the top [inaudible] in fact it's sunk down to the level of the ccNSO.

>>PAUL TWOMEY: But anyway, the -- this is probably the first time today we've heard from members of the community this concern in any institutionalized sense. We'll see how it goes during the week but I wouldn't be surprised if the cc's have a perspective, then their governments themselves might have a perspective following behind that.

>>CHRIS DISSPAIN: Can I just then raise the point that I think that there are two -- there are two things. One may have an effect on the other. The first is the signing of the root. The second is the fact as vicinity has quite rightly said, we need to sign the TLD anyway, irrespective of anything else, so --

>> [inaudible].

>>CHRIS DISSPAIN: Yes, I'm sorry. I apologize. We need to sign -- the root needs to be signed but in any event -- ignoring that for now, we need to sign the TLDs, as I understand it. So if we can manage to come up with some sort of mechanism that enables the -- the TLDs to be signed, then it may be that that has an effect on the decision-making process in respect to the -- to the root. Does that make any sense at all?

>>VINT CERF: Yes. There is a line of reasoning which says that getting the TLDs signed or getting lower-level parts of the DNS signed will be swimming uphill if there is an anticipation that in the end, the root zone will be signed by, you know, this method, one of the methods that has been proposed, and that will somehow create an inhibition to even begin signing anything.

I hope that we can overcome that feeling and move ahead. Because I think a massive zoned -- TLD zoned signings will create authority among those who have taken the trouble to introduce signed zones, and when they speak, I think they will have a strong voice because they actually have done this. They've taken it upon themselves to move into the DNSsec domain. No pun intended.

So I'd like to encourage us to move ahead with that in the ccNSO world.

>>CHRIS DISSPAIN: Thank you, Vint. I have one other question, and I will take questions from the floor. Is ICANN involved in planning for and will it be playing in Cyber Storm?

Does everyone know what Cyber Storm is?

>>PAUL TWOMEY: Talk to the microphone.

>>CHRIS DISSPAIN: Sorry. Cyber Storm is the sort of like critical infrastructure war games that with us run last year and there's a new one running next year. Cyber Storm II, the sequel.

>>PAUL TWOMEY: Okay. The history of Cyber Storm is that it's an exercise in one country, the United States. Cyber Storm II is not a fully international exercise. It's a U.S. exercise, and friends, I think.

>>CHRIS DISSPAIN: Yes.

>>PAUL TWOMEY: Yes, we have been involved in discussions along those sorts of lines in the past and we have been involved in discussions with Cyber Storm II.

>>CHRIS DISSPAIN: Okay. All right. And that's as far as you're prepared to go at this stage?

>>PAUL TWOMEY: No, I'm happy I suppose to talk about it. It's one of these exercises that I think formally is not classified but then doesn't get talked that much, or at least the previous one was not classified and did actually appear in press reports but was not talked widely about, so --

>>CHRIS DISSPAIN: Correct, correct. And we're -- yes. I mean, the Australian ADA is going to be involved in it, I believe. But I'm concerned that it -- my understanding is that it's a -- it's not secret by any stretch of the imagination. [inaudible]

>>PAUL TWOMEY: Yes, I can. Rather than talking to Cyber Storm, because we don't necessarily organize it, so it's hard to be a spokesperson for something we don't organize, but can I raise a related issue that I think also came up in dialogue last night with the Security and Stability Advisory Committee. Can I suggest that security is really an issue that I personally think we don't really address properly or sufficiently amongst the constituencies, particularly this group. And I think many of you have ways of talking to other TLDs, people have places they'd like to talk to about security issues. I understand that security of your networks and your registries are not necessarily things that you want to have discussions about in open forums, per se.

On the other hand, the thing I have to tell you I am worried about is I'm -- I'm worried about a pattern of security attacks on gTLDs and on particular parts of TLD zones or particular sets of DNS servers which, because they are juicy targets, are producing more and more and more sophisticated attack capacity, and that if that capacity was shifted to a ccTLD, I'm very worried whether the ccTLDs are prepared for it or could withstand it. I hate to use the analogy, but I'm reminded that in the first world war, the Major Powers developed also the weapon systems to fight each other. For instance, bomber aircraft. And then the United Kingdom was very good at basically running security across North Africa and the Middle East using bomber aircraft against tribes people, and if you'd want back 20 years beforehand, the tribes people had basically the same sort of military technology as the British but the fact that the British had gone through such an acceleration of attack and technology, they were way ahead of anybody else for the next 10 years in that context. Now, it's a very poor analogy, but what I'm trying to make the point about is, I'm worried about people who are getting better and better at attacking major gTLD targets and then having capacity way beyond what some of the cc's have if they turn their attention, so I think we need to --

>>VINT CERF: So you didn't mean to say that the operators of dot UK would planning to bomb other ccTLD operators? Thank you --

[Microphone feedback]

>>VINT CERF: I'm glad that you -- that to clarify that message. I will say that -- two things. First of all, the number of machines available to mount various forms of attack is considerable. There's a lot of debate over how many zombies there are, how many are the bot net armies. I've been quoted as saying there may be as many as 150 million infected machines. That's knotted a hard machine. That's a number that I get from a variety of sources that say there could be that many out of the some billion devices on the Internet. In any event, we've seen some massive attacks against some of the gTLDs and of course there was the February attack against the root operate -- some of the root operations.

So the worry here, I share with -- with Paul. Is that the ccTLD operators may very well be at significant risk, if for some reason it's valuable for someone to launch an attack against a ccTLD target.

The one thing I would like to get from you is whether there, in fact, have been attacks that you know about and are willing to say anything about. It's something that we need to have some ability to detect. We need some warning system that says that the black hat community, which is launching various forms of attack are, in fact, beginning to expand their target base. So I don't know if anyone has anything to say about that.

>>CHRIS DISSPAIN: We had a question or comment there Bernie and a question from Lesley. If we could have the microphone, please. Bernie, could you -- excuse me. Here.

>>BERNARD TURCOTTE: Lesley always has better comments than me anyway.

>>LESLEY COWLEY: Is it on?

>>VINT CERF: Yes, but you have to really speak up.

>>LESLEY COWLEY: Yeah. Lesley Cowley from Nominet.uk who has no attack plans.

[Laughter]

>>LESLEY COWLEY: Just to reassure, really, there are quite a few informal networks of information sharing already happening in the community. Particularly perhaps between the larger cc's and -- who might be more desirable to attack and our counterparts in the gTLDs. We've been liaising from quite some years now. We are vulnerable to attack, of course, and one cannot mitigate against all attacks, but we've done quite an a lot of infrastructure building and risk scenarios, et cetera and we also have a ccNSO mechanism for sharing that through the tech day and we are, as I'm sure are, willing to share some of our learning and some of the options we are pursuing with a view to mitigation against those attacks.

>>VINT CERF: Could I just raise an idea which could be easily shot down, I suppose, but here we are, many of us implementing our own operations with our own equipment, with whatever funds and the resources we have available, potentially facing a concerted attack by people who have stolen substantial computing resources by infecting a variety of machines. Is there any conceivable utility, even just within the ccNSO community or portions of you, to actually build shared infrastructure that could be used to expand your capacity even at need or perhaps even normally, multiple anycast systems in place in a variety of locations. I only raise this thinking that insurance policies often are designed around mutual support on the probability that not everyone will be attacked at once and so by investing in common infrastructure, you help defend everyone.

It's a very not well thought through idea. It's just something I wonder if it's worth discussing at all.

>>CHRIS DISSPAIN: Yes. It is happening, yes. Bernie?

>>BERNARD TURCOTTE: Lesley made many of the points. I think we're working very hard on the tech stuff, the sharing as part of the meetings that go on here, and one of the angles is really this: To at least bring awareness and some of the basic solutions that can be.

Another thing which I guess is a reflection of where we've gotten with this, which is worrisome to some cc's and good to others is that we've actually been asked to be part of the critical infrastructure discussions within our country, to see how we fit in and how our plans are evolving, and within the completion of our most recent strategic plan thinking is the notion that we have to start thinking as critical infrastructure. There's too much riding on us.

>>VINT CERF: Just -- I'm really -- I have exactly the same ambivalent feeling that I think Bernie just expressed. You know, there's the "holy cow, this stuff is really important, that's really cool." The other side of it is, "Holy cow, this stuff is really important. Now what?"

[Laughter]

>>VINT CERF: You know, for some reason, what flashed through my head was the North American treaty organization and I'm thinking, gee, there is an example of a collection of countries who got together and said, "We need to do something in order to protect our collective hides." So there may be some value in thinking along those lines.

>>CHRIS DISSPAIN: Yeah. Does anyone else have any questions or comments to make? Before we wrap this up? Okay.

>>VINT CERF: So could I just make an observation? I think it's -- I can't tell you what a pleasure it is to walk into a ccNSO meeting and not have a huge debate over organizational structure, voting mechanisms, God knows what other --

>>CHRIS DISSPAIN: We're having that after you left.

[Laughter]

>>VINT CERF: Oh, I see. All right. I was sort of hoping that we got to the point where most -- most of our time is spent with dealing with seriously substantive things, making the Internet work better for everybody, and I sincerely hope that's where we're all going to end up because it's a lot more fun and a lot more interesting and a lot more satisfying than figuring out the shape of the table that we'll have debates around.

>>CHRIS DISSPAIN: I agree. Thank you very much.

>>VINT CERF: Thank you very much for having the board here. I appreciate it very much on behalf of the board. Diane?

>>DIANE SCHROEDER: [inaudible] and not when it was scheduled.

>>CHRIS DISSPAIN: Oh, okay. Thank you. Thank you, Vint. We're going to move on to the next item on the agenda which is Patrick -- is Patrick here? Patrick -- yeah, hi, Patrick. Is that really quiet at the back? Really hard to hear?

>> What?

>>CHRIS DISSPAIN: Yeah. Okay.

[Laughter]

>>CHRIS DISSPAIN: And the board is going now, so there's some more chairs coming free for those that need them. And if you want the shelf over here that Alex has been occupying, you're very welcome to take that as well.

Okay. Everyone, if you want to -- if you're at the back and you want to, there is a few seats available further up at the front. But we're going to move on now to the next item on the agenda, which is a presentation by Patrick Jones from ICANN on registry failover. Or as my gender says, registry fall-over, which is similar but different. So ladies and gentlemen -- do you need the projector or --

>>PATRICK JONES: No.

>>CHRIS DISSPAIN: No. So I'll pass you over to Patrick.

>>PATRICK JONES: Thank you very much. Can everyone hear back there?

>>CHRIS DISSPAIN: Yeah.

>>PATRICK JONES: That was a really great transition to follow both Paul and Vint in their discussion on critical infrastructure and some of the issues that are coming up with the ccTLDs and to lead into, you know, my discussion which hopefully will be somewhat brief on my end and I will be able to sort of answer some questions that you may have. We've spent -- as ICANN staff -- the past year trying to ramp up on a registry failover project, and we started some discussions with ccTLD managers at the last meeting in Sao Paulo. We also began to do some outreach in Marrakech. And now as we've started to publish some reports and we've published the report on the existing gTLD registry data escrow requirements, we'll be leading into a period where it would be really great to get feedback and information and try to learn as much as possible what the ccTLDs are doing on contingency planning, escrow, dealing with with either technical issues or other related issues that could potentially come up as ICANN begins to introduce new gTLDs.

This is also of interest to you. I know many of the registry operators in the CC world could be considering applying for IDNs or other new gTLD extensions, so at some point the areas of discussion for gTLDs could be of direct impact on your businesses as you apply for these.

So what I want to do is sort of give you some background information on what we've done so far and where we're headed and, you know, open it up to some discussion.

As I said, we published an initial report on the existing gTLD registry data escrow requirements. That was published on March 5th. We've got an open public comment forum. We really haven't seen any, nor did we expect a lot of, comments on what those requirements state, but what we are looking for is comments from anyone, especially from ccTLDs, on potential changes to the data escrow requirements. The requirements may not be perfect, so where we can learn from the ccTLD experience with escrow of data, it would be very useful for ICANN staff and, you know, we hope to just collect as much information that can help improve the requirements that go into the registry agreements.

We have sent a survey to the gTLD registries on those requirements and what we have -- expect to do is sort of take that feedback, as well as any feedback that comes in from members of the community and put it into sort of a set of ICANN staff recommendations on how escrow should be -- if it should be changed, if anything needs to be improved in the process, and that is expected by the end of April of this year. And then going along with that, ICANN staff is preparing a report on the critical functions of a registry. Examples of TLD transition. And then potential failure scenarios.

This is a comprehensive report that is due to be released on the ICANN Web site. We had hoped this week during the meeting. With some other staff commitments, that's probably not likely, so I would expect it soon. Maybe next week or within the following week. And from that report we'll be collecting a lot of feedback. It may generate a lot of discussion. And the idea is to put all of that -- all the information that we get into a comprehensive plan that comes up for discussion around the San Juan meeting. What we would like to do as staff is the product is really set up for gTLD registries but again, ccTLDs, I believe we can learn a lot from what you're doing and put that in sort of a guide or maybe -- "best practices" isn't really the word for it, but it's a set of guidelines that registries could follow to make sure that they've -- have the contingency plans in place to ensure operations. And also, it's going to help guide ICANN in the event of a failure of a gTLD registry.

On March 13th, staff prepared and provided to the ICANN board an update on this project, and we asked some specific questions to the board. We asked: What's ICANN's duty to registrants in the event of a failure of a gTLD registry? What would trigger ICANN involvement in a potential registry failure? Should ICANN take over operation of a registry? And should a registry be required to designate a backup registry operator that would step in and maintain the registry, in the event of long-term failure?

The quick answer to one of the questions -- and this came from Vint -- is that ICANN would not be stepping in to take over the operation of a ccTLD registry that had some sort of failure. And specifically, this project is not for --

>>CHRIS DISSPAIN: Well done. Good answer.

[Laughter]

>>PATRICK JONES: Yeah. Specifically, this project is not for ccTLDs, but we're trying to learn, and at this point, I think I'm going to open it up to questions and also suggestions that you may have as we go forward.

>>CHRIS DISSPAIN: Okay. I think -- I think there are certainly a number of ccTLDs, perhaps not all but certainly a number of ccTLDs that would have their own registry failover mechanisms. I know we do. I don't actually understand them, but I know that we have them. And I'm sure that we'd be happy to give you some input. Are there any -- any comments on this, or questions? That we can help Patrick with? Presumably, most of us -- some of us do have registry failover mechanisms? Lesley does, of course.

>>PATRICK JONES: And I know some of you have been helpful. You know, I met with many of you in Sao Paulo, and will be looking to follow up with you as we publish some of these documents.

>>CHRIS DISSPAIN: Do you think that there's a -- your situation, of course, is that your -- one, you've got lots of registries, in the sense that -- under contractual control, you've got lots of registries, as opposed to the ccTLDs having basically one. And secondly, you're generally in a contractual relationship with them, whereas not -- in our case, in some cases, we're in a contractual relationship, in other cases we are it. So there are presumably specific issues that arise for your -- your particular position. Could you just maybe outline a -- what you would -- what you have considered to be a possible scenario and what you -- how you think you might deal with it?

>>PATRICK JONES: Well, right now, the operational plan says that we're supposed to study registry failover and look specifically at what ICANN might do in the event of a technical, business, or financial failure of a registry.

So we've gone through and sort of identified a whole wide range of failure scenarios, and many of these come from applications that have been submitted in the past by gTLD registries and also from cc's, and these applications included examples of potential failure scenarios. For example, in the dot net rebid round and also in the dot org reassignment, there were applications for dot net and for dot org that came from the ccTLD space. And many of these provided really good examples of potential failures, things that we should think about, you know. So we've tried to separate those that are technical failure scenarios from the business failure issue, but they're both important, especially as ICANN considers opening up new gTLDs. And, again, many of you may be considered -- considering applications for IDNs or gTLDs, and these will be just failover failure issues, contingency planning will be important as part of the application process.

>>CHRIS DISSPAIN: Any questions? Or comments? Or input? It would seem not. Okay. Well --

>>PATRICK JONES: Well, and I know the time that was set aside was for a 30-minute block but I definitely didn't expect to --

>>CHRIS DISSPAIN: No, that's okay.

>>PATRICK JONES: -- spend the full time so --

>>CHRIS DISSPAIN: Not a problem at all. We always like to steal time, because we've got plenty of things to do. Okay?

>>PATRICK JONES: Right. Maybe before I go, I'd just throw out my e-mail address, and if people have suggestions or things that they want to send me or if they want to talk off-line, my e-mail address is patrick.jones@icann.org. P-a-t-r-i-c-k dot Jones.

>>CHRIS DISSPAIN: That's Jones with a J, Bernie.

[Laughter]

>>CHRIS DISSPAIN: Thank you, Patrick.

>>PATRICK JONES: Thank you very much.

>>CHRIS DISSPAIN: The next item on the agenda is -- the next item -- sorry?

>> [inaudible].

>>CHRIS DISSPAIN: Yeah. It's microphone failover. The next item on the agenda is a presentation from Kieren, who fortunately is here but probably busy writing his presentation as we speak.

>>KIEREN McCARTHY: I am.

>>CHRIS DISSPAIN: But that's okay. Come on and join us.

So most of you -- many of you will know Kieren McCarthy in his previous incarnations, but he's decided to get a proper job.

[Laughter]

>>CHRIS DISSPAIN: And he'll -- he's here to tell us all about his role as general manager of public participation. Something which I think is a fantastic development in the ICANN arena. The blog is -- the blog is great, and the public participation Web site is fantastic, but I don't want to steal your thunder, so...

>>KIEREN McCARTHY: I have a PowerPoint.

>>CHRIS DISSPAIN: You have a plug right there.

>>KIEREN McCARTHY: Wonderful. Well, I'm pleased to actually be here. It's a bit weird for me to be highlighting why ICANN is great, which I don't think I will -- although ICANN is great to be honest with you, but rather than telling everyone why it's dreadful --

[Laughter]

>> Microphone?

>>CHRIS DISSPAIN: Yeah, he'll sit down in a second.

>>KIEREN McCARTHY: Okay. Hello, yes. So I am Kieren McCarthy, the new general manager, public participation. I thought -- I hate long, involved presentations so I thought I would do a very simple one. Who am I? What is the job? Why is it needed? What will I do? How can you help?

I am an U.K. journalist and I stress U.K. and I stress journalist. I know very well the history of the ccNSO and ICANN and if there were sides to be on, I would be on your side with regard to the history of it.

I think that's more or less over which is part of the reason I'm with ICANN now. And I hope to be one of the people that you hoped would appear at some point and start helping everyone work together rather than trying to take control of each other. I'm that person, or part of the solution.

I am a journalist which means I like to put information out there, as much information as accurate as possible, as fast as possible. And I like to gather information, and I like to tell as many people in the world about it, bearing in mind confidentiality, et cetera, et cetera. I am an adult as well.

I am an ICANN watcher and critic. I have criticized -- I was going through the stories and I have written a lot of stories about ICANN over the years, and I reckon about 70% of them were critical and about 30% of them were -- no, that's not true. About 10% of them were in support and the remainder was just sort of pointing out what was going on.

But I honestly think -- I know the culture has changed within ICANN and a lot of you know as well which is why you have signed accountability frameworks which is why a lot more of you signed up for the ccNSO.

And I think it is worth stressing. They got me on board because they basically said to me, you have been moaning about this for years, will you come and try to sort it out? So I thought I would give it a whirl.

I am an Internet lover, and I think that's the main important point, I think the Internet is amazing and I love what it does and anything -- I find anyone tries to assert some sort of control, it ends up being worse for the Internet and I care about the Internet more than I do any particular battles or power plays, et cetera. So everything that I try and do will be to improve the Internet, the concept of this wonderful sharing network rather than I would rather have this or I would rather do that.

What is the job? Well, it was proposed in 2002. I think it was Stewart Lynn proposed it and it was basically recognition that things weren't going quite right and the processes weren't working quite right. So he suggested we needed a general manager of public participation to try and smooth the process, find out what people were actually saying and get it to the board a bit better, open it up a bit more.

It is in the bylaws. I won't go into what it says in the bylaws. It is in the usual ICANN bylaw speak. My summary of it is I get more input and I get better input and then I make it count. And the last point is really the hard part of my job because you know ICANN's processes and sometimes you get excellent input but it doesn't filter through sometimes. And that's what I hope -- that's going to be the hard part. I hope you will help me with that.

Why is the job needed? Very poor filtering of information. One of my bugbears is the e-mailing list. You never know when you click on the huge long lists of e-mails whether it is going to be incredibly insightful comment or whether it will be a flame or another pointless battle between four people. It is very hard and you get swamped. It really do the get -- it is very hard to pull out the good information.

And think part of the problem is the e-mailing list. I am trying to look at technologies which will flag up insightful communities which hopefully the community will do because I don't have time to do it and we need to filter this information. This is good information. This is bad information and save everyone having to read the bad information.

Excellent ideas lost. I have lost track of the number of people -- not the usual suspects, you know. The intelligent people have been following the Internet and feel very passionately about it. And they said, finally, ICANN has got to this position. I told them two years ago this should be the way. I have checked out some of these claims and most of them surprisingly are true. As you dig up the e-mails where they outline this is the way to do it, believe me, and it never got through.

And so I want to make sure that when those excellent ideas pop up, that they get through there, or at least they are really tackled rather than lost amid all the policy processes, amid all the discussions. Try and make sure those excellent ideas are still up there, even after you have talked about it for 15 hours.

The ccNSO, I know, especially has been frustrated with how ICANN works and we know the history behind that.

And those frustrations haven't helped ICANN's processes at all. I don't think it has helped anyone to be frustrated. I hope to lift the frustration. I hope you will tell me what you are currently frustrated with, and I will find a way out of it. Whether that is talking to the staff, whether that's pushing ideas out there and seeing what happens, whatever that's improving discussions, whatever it is. I will try and find a way of lifting what annoys you as my job of general manager, public participation.

There is not enough interaction. I mean, the constituencies serve a very useful role, very useful role. I think the fact we have a lot of joint meetings like the GAC/ccNSO meeting. The GAC/GNSO, this is people talking to each other more. There is not enough interaction between ICANN staff and the constituencies, and this is again a historical thing. They are gradually changing. I occasionally scare the hell out of them when I start saying, let's do this, let's do that and I start grabbing information and telling everyone about it. It worries the hell out of them, but they are getting over it slowly and finding the usefulness.

And I now know this, but you need to find the usefulness of doing the same as well. Stop worrying, well, if I say this, this will happen. Try and find a way of getting over that so we work with each other more, so we interact more.

I don't like the insiders thing. I knew when I crossed the threshold into insiders, because I suddenly started understanding what everyone was saying in the public forum.

[ Laughter ]

That's when I realized I had become an insider, oh, yeah, I know what he means. No normal human being would have understood what was being discussed. And I don't think it is terribly useful, this insiders business. I think it should be possible for someone, if they are willing to put in the time, to understand where you're up to with the vast majority of these things.

Now, I know there is the technical issues. One of the arguments I keep having is I keep saying, well, you may not -- people may not be the best technically but you have to get them as far as you can, and then get them talking to a technical person and they will pick up the rest.

Because of the insiders' approach, I think it is very, very difficult to get there. There is very few links between the not knowing anything and knowing everything, and it is a very difficult process to get from one to the other. I reckon it takes about two years and three meetings and a lot of heartache.

I want to basically make the links.

What will I do? This is the important bit. Get and share information. What information do you want to know? I will get it and I will share it with you and I will share it with as many people as possible and share it in a format that as many people understand. I think that's vital.

Talk to people. I am a chatty person. I talk to anyone. And listen vitally to what people actually have to say rather than just talk at you like I am doing now. I don't particularly like talking at people. Talk to me, say this is what's going on, this is what I am concerned about and, great, I will pull it all in.

The participation site which is this is where I have to do a bit of salesmanship while you have all got your computers open at an ICANN meeting. If you go to public.ICANN.org, there is a participation site there which I would love to think you are all aware of but I know half of you aren't, which is on its way. It is pretty good. It is not great. It is pretty good. I am improving it, which is our participation Web site for the meetings. It is useful while you are here as well. It is particularly useful if you are not going to be able to come to a future ICANN meeting.

The idea is that you will be able to get as much as information, hopefully interact as much as is possible online currently with what ICANN is doing. So I noticed a few of you actually typed that address in, so I will say it again, public.ICANN.org. You can register and you have your own blog. You can put in comments which I am getting the moderators to start looking at in meetings. It takes a bit of getting use to because it is a different system. You can list chatrooms, I know everyone uses jabber and IMs and the chatroom is Web-based and it is not terrific but I am improving it so we can interact more. So you can get in there and tap something, see what people are saying and then hopefully it will lead to someone else asking a question. Hopefully that will lead through people asking intelligent questions and so on and so forth. So please do try the participation Web site. Give it a whirl, see how you do.

Newsletters. I don't know whether ccNSO thinks a ccNSO newsletter would be useful. If you think it is useful, I will do one. If you would rather have a wider one or a more narrow one, like an European ccNSO newsletter, I will do one, you know? The difficulty with it is gathering the information which will come to a point in the moment, you can have a newsletter but it is pointless if you don't have information to put in it. That's one of the issues.

Fact sheets, I don't know whether you saw, I did a fact sheet on the RegisterFly thing yesterday which I dished out and that was a hell of a struggle to get done in that short period of time, especially since there are lawsuits flying around. But that was -- I thought that was -- well, I hope that was useful. I did one on the DNS attacks in February which I managed to get out in March, which people have said was useful.

And I hope to do more of them. DNSsec, IPv6, any ccNSO issues that you really think need a fact sheet where people are completely misunderstanding how it works, it he will me and I will do a fact sheet. I am happy to. This is my job.

New ideas, I have lots of new ideas. I will get around to one of the main ones for the ccNSO in a second. What can you do? How can you help? More adult conversation and I know with XXX coming up that may not be the best language to use.

[ Laughter ]

I have no time at all for this, frankly, rather boring arguments that still go on in ICANN. I want adult conversation. We're all professionals here. This is the Internet. The time is over to go over the argument you had in the bath five years ago. I had no time for it, and it doesn't help the public. It doesn't help the Internet. It doesn't help ICANN. So we need more conversation. It needs to be adult, professional conversation so if anyone speaks to me along those lines, I am delighted. I like gossip sometimes, admittedly, but I don't -- I'm not interested in the battles and the fights and whatever.

Greater information sharing. This is where I hope the ccNSO will trust me slightly and I hope to give the trust back in that the gTLD figures -- this is an example. The new gTLD -- the gTLD figures the monthly the historical data. May 2001 there were 15 million dot coms, et cetera, et cetera. ICANN has this monthly data. It is part of the agreement that has to be handed over.

It was originally, if I remember correctly, put up on the ICANN Web site. At some point someone decided that this data was now confidential which to my mind is insane. This is historical, useful, important data that should simply be put out there. And no one has yet given me argument why we can't. There is a three-month confidential element written to the contracts. That's fine.

I am planning to -- I have got to push it through various people. I am planning to put this information up publicly on an ICANN Web site, anyone can use it and do whatever the hell they want with it because it is useful information.

What I would really like the ccNSO to do is find a way of you doing the same, so that -- I don't mind whatever way you want to do it. If you want to draw up an agreement so that we agree we share information or you draw up an agreement that I say where the information came from, I really don't care. I think it would be incredibly useful historically for the ccNSOs to provide this is our historical data. This is how many dot eu and Nominet and a couple others -- I think Australia does as well. For the rest of you, let's find a way of compiling all this information in one place and then you can use all of our information, if you want.

Let's just share this information. This is useful. If you have -- I know there is some issues with some ccTLDs that you may not have the systems or the setup to do it. Well, the ccNSO, you have got people here who specialize in it. Have a conversation saying I can't get ahold of this information, and I am sure someone will say, I have got this system. It will help up. I would really like to share that. Those sorts of things.

One of my plans, one of my new ideas is on the ICANN site is to have a map of the world -- clickable map of the world and you click on individual countries and it brings up vital stats for those countries. This is the history. This is who runs the ccTLD. This is the ICANN regional liaison that covers the area. This is the state of the Internet in that country, just a really useful resource.

More interaction, higher quality information, I think that speaks for itself. And any ideas that you have -- literally, any ideas you have you think would be really nice if ICANN did this, come and talk to me and I will see what I can do, seriously.

And questions, queries? That's my e-mail address. Make sure that's right. Yes, that's my e-mail address.

>>CHRIS DISSPAIN: Thank you, Kieren. I have a couple of points before we take questions.

Just on the stats thing, it is probably not necessary -- it is probably too complicated to try to formalize it through the ccNSO. We would be very happy to send out a note to the various lists with some sort of contact for you and say CCs who are prepared or already published. For us it is easy, we can give you a link and you look it up. For other ones, if you are prepared to provide some statistics, that will be fantastic.

Lesley and I were talking about this early on. Kieren is the result of ICANN doing something that we have been -- wanted ICANN to do for quite some time. Lesley and I were saying now that it has actually happened, we have to put more resources in, in order having got you. Now we have to try to deal with you. The challenge for us is actually going to be -- you should remember we all have day jobs. That's the key.

Whereas with the gTLDs, their interaction with ICANN, they are contractual and part of their life. Ours is less so. Does anyone have any questions or comments? Emily, can we have the microphone down here?

>>EMILY TAYLOR: Thanks a lot, Kieren. It is really good to have a presentation from you as an ICANN staffer and hear your very exciting ideas. I really wish you luck and great success in your role.

Something that struck me when you were talking was a comment from the review of the GNSO by the London School of Economics which says join a constituency has unacceptably high information costs for anyone who is not already a deep insider in ICANN. I think for me, that really rang true. And anything that you can do to demystify, explain in really simple terms what's going on because once -- as you said, once you understand what people are talking about, it is too late, you're lost. You're not actually the target audience for your role anymore because you are already an insider.

To make this process more valuable, we do need to give better access to people who are probably too intimidated or just don't have the years of their life to devote to getting up to speed so they can participate meaningfully.

>>KIEREN McCARTHY: I would say with that, one of the other big problems is that when people do go to the trouble, when they do turn up -- there is always new people, every ICANN meeting and then about 1% of them return because there is the lining up in the queue and having to talk into the microphone and then there is everyone with all the insider, it is difficult.

This is part of the reason I want the participation Web site to work. I want to get to a point where someone has a really good idea, type it in and then it will be picked up. Quality of information, not quantity or precision. I want the ideas and thoughts.

>>CHRIS DISSPAIN: I think it is interesting both you and I -- Kieren and I were at the Sunday morning session for new ICANN people or newbies. I will guarantee you there were more -- there has got to be more than seven or eight new people but there were only seven or eight people that came to that meeting.

And it's -- if you can actually -- The other thing is we do that every time the first day, there is a meeting for new people. That's perfectly fine and there should be. It might be useful if that meeting -- the information from each of those meetings is captured so if I am coming to an ICANN meeting for the first time there is a place I can go that says introduction to ICANN and it has got notes Paul Levins said at the last meeting and so on and so forth.

>>KIEREN McCARTHY: That's a good idea.

>>CHRIS DISSPAIN: Bernie, you had a comment? While the microphone is getting to Bernie, Kieren, one of the other things on the board of the APTLD Asia-Pacific top-level domain, we ran our first non-technical training session at our APTLD meeting in Bali about two or three weeks ago and we videoed it. We had a professional video cameraman and lighting.

The intention being not necessarily that we want to sell it on Amazon, although we might, but specifically, one, we wanted to capture it but secondly for those that simply can't make it, there is an opportunity for them to be able to watch it.

I don't know whether that sort of thing fits with anything that goes on at ICANN meetings, but it might. It might be worth thinking about.

>>KIEREN McCARTHY: If you want some ideas, I am full of ideas at the moment. I am just trying to get the practicality. For example, all the staff is filmed, all the web casts is filmed and I am not happy with the archiving at the moment. They have started archiving. They do use Real Player and that's because of the capital investment in that and it is pretty good as well. Everyone tells me to use Open Source stuff and I have looked and it is pretty rotten at the moment.

As soon as it is good enough, I will push people on to it. I want, for example, them archived into an open format as well as Real Player. One of the things that really annoys me -- and I will sort it out, is that I really love the scribes and we put the transcripts up. It is wonderful. But I have never bothered to sit down and read them when I have missed a meeting because it is a long, long, long page of text.

>>CHRIS DISSPAIN: Exactly.

>>KIEREN McCARTHY: I need to find some tools that strip out the context so you can find out what happened, who said this.

>>CHRIS DISSPAIN: You may have noticed this generally speaking only one of them is working. The other one is just sitting there.

[ Laughter ]

Maybe the other one could just do some little doodles and things and put those on the side of the page and liven it up.

>>KIEREN McCARTHY: Some pictures with colors?

>>CHRIS DISSPAIN: Colors, everything, it would be great.

>>KIEREN McCARTHY: It is a terrible shame because it is a fabulous resource but it is lost because of the pure human nature. You do not sit down and read a huge chunk of text.

>>CHRIS DISSPAIN: Absolutely. Bernie, did you have a question or comment?

>>BERNIE TURCOTTE: A, stop picking on the scribes. I would like to thank Kieren for taking a chance on this because I think you are one of the people who can make a difference. So we are looking forward to that and I encourage you and if we can help you, let us know.

The second thing I was -- I appreciate your presentation being short and to the point and that's great. And I appreciate some your objectives.

I am wondering, if you can, share with us, given that you have transitted to the dark side -- no, just joking.

[ Laughter ]

But only recently. No, maybe just from your point of view, slightly outside of what you're doing, what do you see as the biggest challenges facing ICANN right now?

>>KIEREN McCARTHY: That's a loaded question.

>>CHRIS DISSPAIN: You mean apart from dealing with you.

>>KIEREN McCARTHY: Biggest challenges? In real practical senses, I think the GNSO is the biggest challenge. I am in an insider world. I am telling you about the GNSO which is insider, that's the biggest challenge, I think, at the moment. The biggest challenge on Friday is what on earth the board decides on XXX. The biggest challenge next week will be me trying to figure out how to archive all the stuff from this meeting and make it useful.

The biggest challenge next month will be to start coming good on some of the ideas I have come up with and some people said that's a good idea, and now I have to go and do it.

The biggest challenge this year will be to come through with this transparency thing. The biggest challenge over two years is to make the input actually work. I am talking about filtering this information, getting the best information. It is actually incredibly hard and I have done a few experiments and it eats up so much time that it won't happen. So I have got to find ways to do it, and I have to find technological ways of doing it because it is just too much content.

>>BERNIE TURCOTTE: Just as a follow-up, sounds great. You said how to make transparency happen. Does that mean we have left aside the accountability part of it?

>>KIEREN McCARTHY: Yes. No, I'm joking. Accountability, well, I think -- I am interested in your feedback. I think ICANN is definitely getting there. I can tell you now from being on the inside it is the old cockup over conspiracy thing. It really is. I have yet to find a single conspiracy, and I have been looking.

>>CHRIS DISSPAIN: They faded away when you arrived.

[ Laughter ]

They are hiding.

>>KIEREN McCARTHY: I am part of the conspiracy and I am lying to you. You have got to be careful.

>>CHRIS DISSPAIN: Exactly, exactly.

You have probably read the agenda, we are having a session on your favorite subject tomorrow morning, Bernie, which, in fact, you are chairing because I will be somewhere else because you are going to chair that.

[ Laughter ]

Anybody else? Any comments or questions or things to ask Kieren to do? Thank you very much, Kieren. It was great. Thanks.

Can I get Kim Davies, please, and Olivier for the IANA update.

So our next item is IANA. Who is going first? Olivier?

>>OLIVIER GUILLARD: Does this work? This is the slot that everybody is looking for. I will be short. So in short about the IANA working group, according to the membership protocol that was adopted in Sao Paulo, a new list of IANA working group members has been posted to the council, which I hope will be adopted. So we would welcome in the group (saying names).

Is Eberhard Lisse here? Nobody knows him.

[ Laughter ]

Okay. Still in the group, Keith Drazek from dot US, Frederico Neves from Brazil, Lesley Cowley from U.K. and myself.

So since Sao Paulo, we have pursued our support to IANA, especially with regard to the new public consultation process they have launched and we are expecting from the outcome of the consultation -- there were three consultation. One was before Sao Paulo about technical checks before changing the root zone. Another one about the glue records in the root, and another one about retiring ccTLDs that were not in the ISO list.

Ten of us met yesterday. We had an interesting meeting which turned into a conversation with IANA. As you know, IANA is a member of the group formally. And we had some question about schedule of the different ongoing projects that IANA has such as automation of the IANA process, for example.

We noticed and we, let's say, acknowledged that nobody screamed recently against the IANA work.

However, yesterday, couple of questions still were in the air and we had the opportunity to discuss with IANA about them, questions such as are the data in the IANA WHOIS database accurate, for example. What impact for IANA and the DNS stability to (inaudible) root server, IPv6 quarter in the root zone. You know that's the root server IPv6 address auto announced and what would happen if it is done.

Other questions such as what does mean sponsoring organization in the IANA database? Are there any plan to send the root zone and couple of questions like that have raised and it was a conversation and we had good input from IANA about them.

So what's next for the group? The two main priorities now is to -- first one is to migrate the IANA working group Web site to the new ICANN Web site since the ccNSO has a slot in it.

And the second one is to update the list of concerns about IANA. If you go to the current IANA working group Web site, you will find on it a list of concerns that were set up initially in Luxembourg and updated afterwards, so the -- the URL is IANAWG.ccNSO.org and there is a document with a list of concerns that were raised and that we will now update, and hopefully before Puerto Rico. So if you have any question with regard to IANA, it's the moment to ask them. Contact me or anybody in the group and we will take into account those concerns to update the list. Thank you so I leave the floor to Kim.

>>KIM DAVIES: Thanks very much, Olivier.

>>OLIVIER GUILLARD: You're welcome.

>>KIM DAVIES: Thank you. Can you hear me in the back? Yes?

>> What?

>>KIM DAVIES: Yeah. Good. What.

[Laughter]

>>KIM DAVIES: So it was interesting listening to Kieren's presentation just before me because I seem to recall the first time I was on ICANN's staff sitting up here and pretty much saying the same thing, so now I'm fully part of the Evil Empire. You can evaluate me on how I'm doing.

I'm just -- as usual -- going to try and summarize some of the key work that should be of interest to you that's been going on within IANA, and I'm certainly open to any questions you might have at the end.

The first thing I wanted to mention is that with the ccNSO IANA working group that Olivier chairs, we discussed actually almost I think a year ago an escalation procedure for IANA. The aim of the escalation procedure was to create a clear set of instructions that if you feel that IANA is not performing its task correctly, you can escalate your concerns up through the organization. It's basically guidance on what steps we recommend you take if -- if you're not satisfied with your interaction with IANA. We've accomplished those on the Web site and as well as getting consensus within the ccNSO IANA working group, we've also agreed the same escalation procedures with the IETF. So this is an escalation procedure that's covering a number of the areas that IANA operates. And it's available at that Web site.

Next I'll just show you some graphs. These are the same graphs that Paul Twomey showed you during the initial welcoming session on -- when was that? That was on Monday. As you can see, the trend, I think, is relatively good. The amount of root zone management tickets that get turned around in less than 7 days is the green component there, and you can see that fairly steadily for the last year, the majority fall into that category. And it's fairly rare that we get into the red category, which means that a ticket has been opened for more than 30 days. And if you compare it right back to March '05, I think it's a dramatic difference.

I don't know why every time I do slides, they kind of flip around and stuff, but...

The next graph shows the number of sort of outstanding tickets on average at any given time. As you can see, the trend was to have a large number of tickets outstanding at any one time and that trend has come right down. We're averaging about 20 outstanding requests at any given time at the moment.

The number of -- the maximum number of tickets outstanding has been trending down as well. As you can see, in the beginning -- well, we can see on the left the number of days. Some tickets were outstanding for several years. Now we're down well below the 100-day mark, almost trending down to zero on that scale.

So an update about the root zone management work flow automation. I won't go into detail what that is, but the 10 second version for those that are new is that we are modifying some software that was developed within the ccTLD community, with the aim to automating much of the work flow that happens within the root zone management function within IANA.

Since the last meeting, we've hired a new software developer, Simon Raveh. He is our new development manager. He was actually a contractor to us before, and we've actually brought him on as staff, and basically his role is to coordinate all the different development projects we have going on within IANA. It would be fair to say that this particular project is definitely Priority No. 1, and with him on staff and working on this every day, we have a much better tracking and control of the project, and I think we're moving quite rapidly towards its development and it's the conclusion of that development.

He's working and coordinating now with NASK. NASK, the Polish registry, originally developed the software that we're basing our software on. NASK is working with us now on tailoring that software to the exact requirements of the root zone registry, and we're working very productively with them.

The first functional milestone in our project plan is for -- for the next month -- in fact, just the next few weeks -- where we expect to have a functioning version developed that does everything except name server change requests. So I should make -- with a caveat, these are routine changes. Redelegations and so forth, which are fairly complex and involve a lot of human interaction, aren't part of the scope of this software. But for routine changes, we expect to have non-name server changes supported soon, and as Paul Twomey said earlier, our aim is to have even those supported, I think, by the end of May.

The reason, in part, that name servers fall into a different category is that there's more policy associated with those. In particular, we've launched two different policy reviews with -- in relation to what technical checks we do, and also what our glue policy should do. And the outcome of those actually will feed into this. We need to work out what the solution is to those two problems, and once we've documented what exactly those technical checks are and what the glue policy should be, then obviously software can be written to accommodate that policy.

We've been working on identifying what the testing procedures should be. In particular, as I've mentioned before, the U.S. government has made it clear that they expect rigorous testing for security, and obviously we would like that too. We're working out the best way to do that. And we'll be discussing that with the community at the appropriate time.

In addition to -- I worked with NASK on developing this work flow system. One of the interactions we have in the course of a routine root zone change is that we need to speak with VeriSign in their role as the operator of the -- I guess the A root zone. All the root servers copy their data from Verisign's primary name server, and we have to communicate the contents of the root zone to VeriSign. That's a fairly intricate three-party discussion at the moment where we send messages between ourselves, DOC and VeriSign and what we hope to do is move to a system soon that involves EPP. Basically, we hope that this will just improve that process somewhat and make it a bit more reliable, predictable, and quicker.

The next topic I want to talk about is signing the DNS root zone. Within IANA we've been developing the tools and the experience and the processes to sign zones in general. We've started with dot ARPA at the request of the Internet Architecture Board and we're working on this actively at the moment. Our goal is to sign dot ARPA as well as some of the subzones under dot ARPA that we also manage and I think that the experiences that we get from that will help us at the time when we're required to sign the root.

Our aim is to have the second generation of the root zone management automation software except the DS or the DNSsec signed, delegations -- delegation records. We haven't put that in the first generation simply because the aim of the first generation was to replicate current functionality. We wanted to make sure this root zone management software was deployed as soon as possible. But once that's deployed, once you're all using it and happy with it, we'll then go to adding new features and this will be one of them.

We're determining the process with the U.S. government on how we would sign the root zone. That's an ongoing discussion. Perhaps related is we've also been asked whether IANA can operate a DLV registry. For those that aren't aware, DLV is kind of a bridging technology for DNSsec, which allows a lot of the DNSsec information that would normally be stored in the root to be stored in a -- in a separate zone and resolve as a tort to look at that information if the root isn't signed. We've been asked if we could operate such a registry, and the IETF currently has an Internet draft which specifies DLV and in its IANA instructions would ask IANA to create a DLV registry. This doesn't mean that this will actually happen. It's still a draft. It hasn't been approved. But there's just been initial inquiries as to whether we could.

One of the challenging things is that it's fairly resource-intensive. It could mean that effectively, IANA needs to create a replicated root server infrastructure. I mean if DLV really takes off, there will be many thousands, if not millions, of inquiries to these -- to the servers that IANA operates. So it's a fairly large undertaking and that's part of the discussion that we're having right now is to -- to whether IANA is even the appropriate place to have this, or what our obligations would be to the IETF and so forth.

Quad A records for root servers. This means it would unable basically IPv6 DNS queries right from the top down. The Security and Stability Advisory Committee will issue guidance to IANA tomorrow. We've obviously seen some drafts and we've been discussing that previous -- prior to its release. And we're currently working out how to implement that, and we're in discussions with root server operators and so forth about the appropriate way to do that.

It was mentioned in the public forum something called "The Book of IANA" so I thought I'd just quickly mention it. We've created a document internally that basically is a fairly comprehensive list of all the services IANA provides, what our targets are for those services, the description of those targets, and also our plans to achieve those. Our plan is to publish those, so I expect that will be on-line shortly. When we publish that on-line, I'll certainly let the mailing lists know.

The 24/7 support line, just a brief status update. Still modest usage, in that we've had zero calls but --

[Laughter]

>>CHRIS DISSPAIN: Modest?

[Laughter]

>>KIM DAVIES: And that's what we anticipated. I mean this is for fairly rare circumstances. We continue to test it, to make sure it works. We get marketing calls on it, but that's with about it. So for now, it's still there. We're working on our communications strategy, so that -- to make sure that ccTLDs are reminded of what the number is, so that new ccTLD operators are informed in a timely way of what they can -- that this service exists and that they can use it.

An interesting question was posed as to what's the relationship between the denial of service attacks that hit the root and the 24/7 support number. The direct answer to that is: Nothing, because IANA isn't involved in running root servers, but it raised the -- the specter that if any ccTLD found themselves under denial of service attack, they might find that they may need to quite quickly alter the delegations in the root, and I think that would be one such circumstance that this service would play a valuable role.

So if at 3:00 a.m. in the morning you found that all your name servers were under heavy attack and you needed to make some changes, then you could certainly call us.

The procedural reviews that IANA is undertaking in relation to root zone management, the technical check policy is under final staff review. To be honest, I'd hoped to have that document done in time for this week, but regrettably, it wasn't so. But I think very soon, that that will become public.

The SSAC has just recently published its comments on the glue policy. We'll be taking their comments, as well as the comments garnered from the public, and conducting a staff review on that. Those, too, are our priority. As I mentioned, they feed into our automation work, so it's important that we identify exactly what our technical check policy is, and exactly what our glue policy is.

The third topic which was launched at this very meeting in Sao Paulo was the sunsetting of country code domains. We've concluded the public comment period on our Web site, but ICANN staff are continuing to perform consultations. Right now particularly with those parties that would be affected by any particular implementation of the current policy or any possible change of the policy.

That will continue.

Other work areas of IANA, we're looking at the IANA database, sort of mid to late last year, and wondering exactly how many of the postal addresses we have were actually accurate. We know anecdotally that some didn't work but we weren't quite sure how accurate they were. So we decided to send you all Christmas cards. We sent every administrative and technical contact in our database a Christmas card, and whilst we have -- obviously wanted to spread good cheer, our main aim was to see which ones came back. And I regret to say that I actually have a fairly large stack on my desk, and I think it's at least 50 have returned. Now, there's probably no more than 400 or 500 contacts in the IANA database, so that's a fairly high error rate.

We're going to go through the process of contacting all those ccTLDs that were affected, and try and update their data. We noticed some fascinating things, like the U.S. postal Al service didn't even recognize some legitimate countries as countries, so perhaps we also need to educate them as well.

But we'll see. That's one project that we want to work on. Just generally increasing our data accuracy within the IANA database. And that was one issue that we raised yesterday within the ccNSO IANA working group.

The IANA Web site, some of you will remember that we showed some prototypes, a few meetings ago. We've basically prioritized our work on some of the more sort of policy development, functional development, that you've all requested, and whilst to us improving our Web site is important, it took sort of a second priority to those other items, and now the -- now that we feel that they're in hand and under control, and particularly now that we have our software development manager, we'll definitely refocus on getting that deployed. So I expect a lot more work on that in the coming few months.

We're working on anti-spam measures on our Web site as well. We've received support from the IETF to basically obscure all the e-mail addresses in our IETF registries in our Web site. As part of that, we'll also be trying to obscure your e-mail addresses on our Web site in relation to the root WHOIS. It will basically be fairly simple obscuring, simply to foil the standard spam bots that are out there. It's obviously a request that a number of you have had.

At the same time, the e-mail addresses will still be listed.

Authentication procedures review. Again, as Paul Twomey mentioned earlier, we need to substantially review how we authenticate requests, particularly in light of increased automation. Obviously, the more things get automated, the greater the risk if something slips through undesirably, so we want to review those procedures.

And finally, I wanted to mention just -- just an observation that IANA has a much heavier caseload of redelegations now than even just a year ago. I think right now, we have 10 outstanding redelegations, and just in the last 48 hours, I've spoken to at least four ccTLDs that want to re-delegate as well.

Basically, a lot of these redelegations are more a case of updating IANA's data to accurately reflect the reality in that country, but I think this is the result of better outreach that ICANN has been doing in the last year. We now have a network of regional liaisons. They're dealing with the ccTLD managers directly. The ccTLD managers in the countries that don't necessarily come to ICANN meetings are better understanding how IANA works, what the procedures are, and they're becoming more willing to come to us to update their details.

So I think this is a good thing. But just a heads-up, I suppose, that redelegations are forming a greater part of the day-to-day work of the IANA staff.

And that was -- that was my summary. So...

Fire away.

[Laughter]

>>CHRIS DISSPAIN: Do we have any -- anyone in the room with questions? I can see a hand at the back there. Keep it up, please. Keep your hand up.

>>SLOBODAN MARKOVIC: Hello --

>>CHRIS DISSPAIN: Could you stand -- Slobodan, could you stand up, please?

>>SLOBODAN MARKOVIC: Hello. I'm Slobodan Markovic from Serbia. I'm on the ccNSO council, but I've been also elected recently to the board of the new Serbian registry, and I have a couple of information regarding the process of delegation of dot RS and dot ME, which were -- which are the new domains delegated to Serbia and to Montenegro, which should replace currently used dot YU.

I've been informed that this morning, Serbian registry submitted a redelegation request for dot YU and delegation requests for dot RS, and at the end of December, Montenegrin registries submitted a request for delegation for dot ME.

Also, before the end of this week, we will sign the -- the two registries will sign an agreement on transition -- on the transition process which will basically just be a mutual recognition of the two registries and clarification of responsibilities related to handling of dot YU domains while it's -- while it continues to exist. However, I also would like to hear from IANA on one particular issue, and I've been in communication with -- with the guys in Montenegro who basically are more -- progressing more faster than Serbia in the sense that they already sorted out a good deal of administrative issues with their government and they set up their name servers, so I heard that IANA was trying basically to force them to pronounce themselves on the issue of the final solution for dot YU. And I don't like that. Because I think that Serbia and Montenegro is completely independent countries, need to be -- the process of delegation of the dot ME and dot RS needs to be separated from the process of possibly retirement of dot YU, or decommission of dot YU. Yes, Chris?

>>CHRIS DISSPAIN: No, no. That's fine. I'm...

>>SLOBODAN MARKOVIC: So I'd like just to quote one sentence from -- from a recent communication with the IANA staff, and the communication said that, "The results are requirement that you specific the transition and the commissioning process for dot YU before dot ME delegation can move forward." So I'd like to hear from IANA if that is, indeed, the requirement. Especially given the -- the final policy on ccTLD sunsetting has not been finalized yet.

>>CHRIS DISSPAIN: So can I just make sure that I understand? I think what you're saying is that you think you're being told that dot ME cannot be delegated until arrangements have been made to sunset dot YU. Is that what you think?

>>SLOBODAN MARKOVIC: Yes. And I -- I also expect that it will be the case with dot RS as well.

>>CHRIS DISSPAIN: Okay.

>>SLOBODAN MARKOVIC: I mean we are -- I have a feeling that we are being gently pushed toward that, toward pronouncing ourselves in regard to that issue.

>>CHRIS DISSPAIN: Okay. Kim?

>>KIM DAVIES: I'm just going to say that we don't talk about active redelegations in public meetings, and I'm very happy to talk with requesters about any concerns they have. Certainly the policy today is that codes that have been retired from the ISO 3316 standard need to be retired, and certainly we've spoken with the operators of YU about that. And the operators of YU have expressed interest in migrating the YU zone to the new operators of RS and ME. But I'm not in a position to be able to comment on the specifics of any particular redelegation request.

>>CHRIS DISSPAIN: Well, can I then ask you a hypothetical?

>>KIM DAVIES: Sure.

>>CHRIS DISSPAIN: Is IANA suggesting -- would IANA suggest that there is any connection between the grant of a new ccTLD and the retirement of a ccTLD?

>>KIM DAVIES: There can be. You just look at the delegation of the dot TL domain. There was a --

>>CHRIS DISSPAIN: Yeah. That's a direct replacement, though, of the same -- of a country. It's not -- it wasn't a new country, as such. It was a -- or new territory, rather. It was a direct replacement at their request because of language.

>>KIM DAVIES: Uh-huh.

>>CHRIS DISSPAIN: So -- so I would -- I suppose what I'm asking you is -- or my -- the concern that I would be expressing is that I'm not aware of any policy anywhere that says that when a new country arrives on the ISO list, it cannot get its TLD delegated until such time as the nation from which it has been carved has deleted or is -- has agreed to delete its ccTLD. And if that is what is happening, then I'd like to know the basis upon which that's happening.

>>KIM DAVIES: There is no requirement that a ccTLD be deleted before another one is delegated.

>>CHRIS DISSPAIN: No, I didn't say that. I said that -- I said that there appear -- it appeared that there may be a requirement that arrangements have been made for the retirement of that ccTLD before the new one is delegated. That's not the same thing as it actually being deleted because we all accept that whatever the policy is, a deletion is a -- is a process that could take five years, and I don't think so anyone's suggesting that you would be suggesting that you can't have your new one for five years.

>>KIM DAVIES: Right, right.

>>CHRIS DISSPAIN: What I think we're talking about is a circumstance where a delegation is -- is dependent upon agreement being reached as to the retirement of the -- an existing ccTLD. And that's what I'm trying to find out.

>>KIM DAVIES: So I think that -- I'm trying to think of what I can say without explicitly talking about this case.

>>CHRIS DISSPAIN: We're talking in the hypothetical here. I wouldn't -- yeah.

>>KIM DAVIES: So if such an incident happened where one country broke up into multiple new ccTLDs, we would ask the applicants if they have a plan of transition from the old ccTLD. Obviously, there's -- there's registrants in the existing ccTLD that might like to be in the ccTLD of their new country, and we would ask the applicant what plans they have in relation to that, if any, and that would form part of their request.

>>CHRIS DISSPAIN: I will get you in a second. And what would be the basis of asking the applicants? Who says the applicant has any control, say, knowledge about the existing ccTLD? I mean the -- it's presumably, in my hypothetical case, a -- it's now a nonexistent government. Because the country doesn't exist -- or the territory doesn't exist anymore, so why would you make it -- gotcha, Hilde. Why would you make it the responsibility of the new ccTLD manager for a new ccTLD that has been placed on the ISO -- the code for which has been placed on the ISO list --

>>KIM DAVIES: Uh-huh.

>>CHRIS DISSPAIN: -- to deal with the retirement of an existing ccTLD? For example.

>>KIM DAVIES: That's not a requirement.

>>CHRIS DISSPAIN: No, but you just said that you would ask them, the new ones, if they had a plan for the retirement of the old one.

>>KIM DAVIES: Right.

>>CHRIS DISSPAIN: So that assumes that they have actually any capacity to plan for the retirement --

>>KIM DAVIES: Right. I mean, the answer might be that we have no relation to the current operator.

>>CHRIS DISSPAIN: Okay.

>>KIM DAVIES: It's not incumbent upon them to take control of retiring the previous one.

>>CHRIS DISSPAIN: Okay.

>>KIM DAVIES: But in certain circumstances, we know that it's the same personality involved.

>>CHRIS DISSPAIN: Sure. I knowledge that. Okay. Let's take this question and --

>>ELAINE PRUIS: Good morning. Good afternoon. I'm Elaine Pruis from the Council of Country Code Administrators and one of our members is the Timor-Leste.TL, and Chris mentioned that they used to be dot TP and they are switching over to dot TL, so I just wanted to give an update about that. There is some misinformation in [inaudible] about the number of domain holders affected. There's actually only 700 active dot TP domains. All dot TP domains have been mapped over to dot TL, and this is with the cooperation of connect Ireland, who is the operator of dot TP.

So if you were a dot TP domain holder, you have the exact same domain in the dot TL namespace, and we are urging those people to migrate their Web content.

>>CHRIS DISSPAIN: Thank you. Hilde, you had a question, and then I've got you in a second, Roelof.

>>HILDE THUNEM: Hello. Hilde Thunem, from the Norwegian registry. I could give you Norway to use as a hypothetical example.

>>CHRIS DISSPAIN: Thank you very much. Let's do that.

>>HILDE THUNEM: So if Norway decided to split into northern Norway and southern Norway, and we decided we hated each other, then dot NO, as it was, would be a country code that had a local Internet community encompassing the whole of what used to be Norway. I see no reason why that code should be linked -- or that community will have to decide, even if they hate each other, what they're going to do with that country code. But I see no reason to link that to the community in southern Norway that wanted whatever the new country code would be, or in northern Norway that wanted their new country code, because that would be two separate communities. Yes, together they also encompass and be -- become a third community that has something to do with dot NO.

>>CHRIS DISSPAIN: Yeah.

>>HILDE THUNEM: And the retirement. But that should be a totally separate process.

>>CHRIS DISSPAIN: Thank you, Hilde. Yes, we've got -- if you could keep -- the gentleman there could keep -- not you, Bernie. I've got you. The gentleman there could keep his hand up. There's a question here. While the microphone is coming down, it seems to me that also we have a -- one of the challenges of this is that you're making a value judgment that this new ccTLD is connected to an old ccTLD whereas dot AX, I think it is, for example, is just a new one that's being -- that's been arrived and doesn't involve the retirement of anything else. So the moment you start -- you're leaping beyond just having something in the ISO list to say that this something in the ISO list is now connected to something else in the ISO list, but we'll get --

>>KIM DAVIES: Can I just clarify that. It is not that there is necessarily any connection. It is just that if there is a transition plan, we would like to know what it is.

>>CHRIS DISSPAIN: Can I just make -- one second. Can I make this so I am clear. What you are saying -- I know that we are talking hypotheticals here but it is not the understanding that Slobodan has. What you are saying is you simply have a request. Is there a transition plan? And whether there is or isn't a transition plan does not -- is not connected in the final analysis to the grant of the new ccTLD or is it?

>> (Speaker is off microphone).

>>CHRIS DISSPAIN: So there is no policy?

>>DAVID CONRAD: Part of the reason for the sunsetting discussion -- the commentary --

>>CHRIS DISSPAIN: Dave, stop, stop, we need to get you on the microphone otherwise the scribes can't scribe what you are saying. Would you mind walking down here.

>> It is about the say.

>>CHRIS DISSPAIN: You carry on while he is coming. Carry on.

>>YURI DEMCHENKO: I am representing dot su domain. This is actually what started the project to solve the problems between the actual dot su community and IANA and ICANN.

We actually sun set discussion produced enough information to produce a good policy but not talking just in general to the record.

So we need to really solve this case by case but still, I think, we actually expected that IANA will produce some recommendation or some result or review of this discussion before this meeting. So let's hope it will happen next time.

>>CHRIS DISSPAIN: Thank you.

>>YURI DEMCHENKO: This is my message, to develop -- using this discussion to develop real policies and procedures.

>> David Conrad: To be clear, IANA isn't producing policies. IANA implements policies that isn't defined by other organizations.

>>CHRIS DISSPAIN: I absolutely agree.

>> David Conrad: One of the reasons we did the sunsetting consultation was to attempt to obtain information from the community to determine how we should deal with a departure from the ISO 3166-1 list that has historically been used to define what ccTLDs are.

>>CHRIS DISSPAIN: Okay. Can you appreciate that there is a difference between asking me what do I think about the retirement of a ccTLD and saying to me granting a new ccTLD can be dependent on retirement of an old ccTLD, now what do you think? The two things are actually completely different questions because the first one is simply should we have a process for retirement of ccTLDs, the answer of which is yes.

The second one is partly that question and partly should there be a link between the grant of a new ccTLD and the retirement of an old ccTLD, the emphatic to answer of which in my personal opinion is no, no, under no circumstances.

The moment that happens, you disengage the simple straight-forward mechanism that if you are on the ISO list, you are entitled to a ccTLD.

>> David Conrad: You don't believe the board should have ruled that TP cannot be replaced until TL -- or reverse that.

>>KIM DAVIES: The precedent is they have been tied together in these cases.

>> David Conrad: The point I am making here each case has been dealt with separately.

>>CHRIS DISSPAIN: My question is not do you have a policy, is there a policy? Board decision is not policy.

>> David Conrad: At this point in time there is no identified, at least as far as I'm aware, no identifiable policy in this area.

>>KIM DAVIES: I think it is important to clarify that IANA is basically writing a report for the board.

>>CHRIS DISSPAIN: Understand.

>>KIM DAVIES: The board will vote on a redelegation. Our inquires in the case of a redelegation, we will ask what transition planning, if any, do you have from the previous TLD because we will put it before the board. I think if we hadn't asked that question, the board would come back and ask us to ask that question.

>>CHRIS DISSPAIN: I agree. Bernie, did you still want to say something?

>>BERNIE TURCOTTE: I will let you finish.

>>CHRIS DISSPAIN: I was just going to finish with one very simple statement. I know we are having a hypothetical conversation and I know you can't talk about specifics. But I learned a very long time ago that communication is the response you get. And if the response you are getting to your communication is that the other party understands you to be saying that they can't have what they want until they do something in respect to something they used to have -- and that is not the case -- then you need to recommunicate.

Because right now the message that we are being told is that they think you've said you can't have this unless you close down that. If that's not true, then you need to make sure they understand that's not true. Okay?

>> David Conrad: Understood.

>>CHRIS DISSPAIN: If it is true, then go talk about it. Bernie wants to say something.

>>BERNIE TURCOTTE: Just to sum it up, I think most people have said those things. I think you guys are getting squeezed into the middle of this thing, we are starting to play with things where given the nature of this organization, when it makes these kinds of decisions, if they have significant impacts, that you need a policy.

Probably what we need to send back to the ICANN board is if you are going to play in this area, you should probably have a policy about this area.

>>CHRIS DISSPAIN: I agree. And then that will make Kim and Dave's lives much easier, I would imagine.

Anything else before we wrap this up and move on to the next item which is basically lunch? Roelof, you had something? I apologize, I had your name written down. This gentleman here.

>>ROELOF MEIJER: Maybe just to get back to Kim's main presentation and the evaluation he asked for. I think the results prove that you are doing well, thank you.

>>KIM DAVIES: Thank you.

>>CHRIS DISSPAIN: Absolutely.

Anyone else? Okay. Kim, I just want to say every meeting that goes by this just gets better and better. Not the presentation -- your presentation has always been better, but the results always get better and better. I thank you because it seems to have just kind -- it seems to be happening. Olivier, a lot of that is due to the working group.

So thank you very much and thank you, Kim. Thank you, David, for coming up.

Okay. Thanks, guys. I have got -- Roman, are you there? Do you want to come up?

We have lunch organized in about five minutes time. And lunch will be in the breakfast room. Makes perfect sense to me.

Down stairs where you have breakfast.

>> Across from the bar.

>>CHRIS DISSPAIN: Across from the bar. Gabby has tickets. You need a ticket to get in. I have no idea what you have to say to Gabby to get a ticket. As almost always, Afilias is sponsoring our lunch. Roland has faithly promised me this time he has a different presentation to the last one.

[ Laughter ]

I said, great, that will be really good. So I will hand you over to Roland.

>>ROLAND LaPLANTE: I have had a number of questions from people in the audience about why do I keep coming? The answers might be I like to buy lunch, and, in fact, I do.

I need more frequent flyer miles. Don't have any other meetings to go to or he really believes ccs are a good growth opportunity for Afilias. Really the answer is D.

We are now supporting 14 domains. We have about 11 million registrations going through our various systems. And I believe that our growth in the future will come from our current business, the current ccs we operate in addition to the sTLDs and TLDs, new TLDs in the next round which we hope to participate in and other ccTLDs which we think we can help.

Why should you listen? The reason is we think we can help you to grow. I took a look at some market statistics. Statistics in the ccTLD world are pretty hard to come by, but the ones that I have suggest that this isn't just CCs but the overall market growth is accelerating. We have had fairly good business success over the last several years because of the overall market growth is accelerating.

In '03 the market grew about 17%. '04, 23%. '05, 29%, '06, 31%. And the growth continues to expand. Total TLD registrations now exceed 125 million worldwide including ccTLDs, sTLDs and so forth. The growth rate in the industry is very strong.

And the growth is expected to continue. This global economic growth fueling is expanding Internet penetration, increasing broadband availability and, of course, new uses for the Internet and for domains in generally. The whole PPC phenomenon has fueled a huge amount of growth over the last 18 months, 24 months or so, and, of course, blogs and so forth.

ccTLD registrations have also grown rapidly. From the statistics I have, it looks like total ccTLD registrations are about 43 million and this looks like the trend here. You can see there was a big zone file cleanup in the U.K. back in '04. EU launched in '06. But in general the growth trend has been pretty steady and total is about 43 million.

But what was interesting to me when I looked at this is the market shares of the segments. The segment of ccTLDs looks to me like it has dropped from 39% back in '03 down to 33% today. Here are the major components. The dot com at the top with the purple line, dot com's share has grown to -- from about 45% to over 55% in the last four years. Com is a very powerful force in the market that we all know about. But what was a surprise to me is how much the market share has increased. It has become even more dominant by a significant amount in the last four years.

When you look at net, org, info and biz, the next group of gTLDs, as a market share, even though those have all grown pretty significantly, info is at 4 million, org is at 5.5 million, biz is at a million and change. Of course, net has been pretty strong. But the market share in that segment has been pretty flat, along at about 15%. That also surprised me.

But what concerns me most is that ccTLDs seem to be losing their currency in the market for some reason, at least that's what the market share information here would suggest.

Now, these ccTLD figures include the EU launch and include CN and include some of the other significant successes, dot IN has grown pretty significantly in the last several years.

What are the levers and strategies? One is to have a robust home market like China and Germany and India. Another is to have extendible positioning like TV and WS which get reused for other purposes than just as country codes.

And then there are a bunch of other levers to look at. Pricing, making sure pricing is competitive. Policies that encourage use but not abuse. Technology that's current, reliable and affordable. Distribution, being able to tap the global distribution system which is extremely important. Of course, marketing, promotion and PR, both domestically and through the registrar system.

So that's where Afilias comes in. We're managing, as I said -- or supporting 14 domains. We don't manage these domains. We only manage really info. We are supporting the other domains you see on this with the technology that we continue to keep current, we have IPv6 working in virtually all of these zones now. We are doing some work in DNSsec to make sure we are current there. We have done a tremendous amount of work in the last 12 months improving the strength of our DNS system. There was some talk about DDOS attacks and so forth. We have done quite a bit of work in the past to improve that and you are going to see some significant improvements in the next 12 months in terms of our capabilities here.

Another important element here is the number of registrars, number of the world's big registrars that carry ccTLDs that we also carry. That number has come up to about 90% and have kind of starred the top registrars here.

These are the guys who are doing 90% of the registrations worldwide or more. And we try to have a pretty good relationship with these people. We work very closely with them on virtually all of our domains.

So I would ask you to consider Afilias if you are thinking about upgrading your backend. As I have said in the past in this meeting, we don't want to run your domain, we just want to help you run it. We would like to stand in the back, behind the curtain, turn the cranks, make sure the DNS works, give you a world-class EPP system. Hopefully we can do it in a more economical way than you are doing today. Let us be your partner.

Next time I want to talk about the secondary market.

>>CHRIS DISSPAIN: Following from what you said, we are going to invite you back. We will make you stand behind the curtain and crank the handle.

[ Laughter ]

>>ROLAND LaPLANTE: Thank you very much.

>>CHRIS DISSPAIN: The secondary market stuff is on our individual agendas in various countries for various different reasons.

Ladies and gentlemen, given that this man has bought us lunch, I think the least we can do is show our appreciation.

[ applause ]

Now, Gabby will stand at the door. You do need a ticket to get into lunch. Thank you very much, Roland. We are back at 2:00 with our IDN, looking at second-level issues, crossover issues and presentation on IDN in Greece. See you all then. (Lunch break)

>>CHRIS DISSPAIN: Good afternoon, everybody. Could you please take your seats?

Okay. Please take your seats, everybody. We're going to start our first session after lunch. This is on IDNs, other matters other than dot idn. Ming-Cheng Liang from Taiwan is going to chair this session and I'll be back in a little while. Thank you.

[Laughter]

>>MING-CHENG LIANG: Good afternoon, everyone. I think this afternoon we will begin our IDN sessions. Before we begin our IDN session, let me make a brief report on what our current status is.

After -- I think after Sao Paulo's meetings, that we have formed this IDN working group, and actually we have put our charter for the group, and essentially in this chart we will set into three different subgroup to deal with issues, and one is second level domain issues, one will be top-level domain-related issues, and then GNSO crossover issues.

And today, I think because our time is very limited, and we have a presenter from Greece to talk about IDN in Greece, so what we are going to proceed today is that we will first ask Vaggelis -- yeah, Vaggelis to present on IDN in Greece, and then we will talk about IDN second level domain issues and maybe some recommendations from Jonathan and then crossover with gTLD from Minjung and I think that's how we're going to proceed today. Is there any questions? If not, then maybe we ask Vaggelis to present his IDN.

>>VAGGELIS SEGREDAKIS: Is this open? Okay. Hello, my name is Vaggelis Segredakis. I am the administrator of the registry of dot GR domains in Greece. I have come to present you a subject that is quite complicated for Greek IDN domain names and we had to create a policy based on our experience on the Punycode resources and stuff like that to make good with it.

Well, we have the fact that we started registering domain names, IDN domain names, on the 4th of July, 2005. We have registered approximately 8,500 IDN domains to date. We allow all Greek characters, both current and ancient characters. And we allow only single script registrations.

We register variants and homograph names under a special procedure, and I'm going to explain later on what this is.

In Greek language we have a tonic accent sign that is called tonos. It is used in most of the Greek words. You use it for pronunciation reasons. The punctuation of the ancient Greek words is even more complicated than the current ones, where we not only have tonos, but [inaudible] and other punctuation stuff.

The possibility to put the Tonos on a different letter of a word creates a different domain name, a different word, and a different domain names of course in the Punycode protocol.

So these are two Greek words -- sorry about the Greek. The first one is [Greek word]. It means -- anyway, the meaning is irrelevant. And the next one is [Greek word]. These two words are completely different in the xn-- translation.

Oh, the thing about these two words and every other word, when you go to capital letters, you lose the TONOS, so the two of them, although they are different in meaning, they are different in what you see there in small caps, they are the same in the capital letters.

So the similarity of some Greek characters with Latin characters create an even more delicate problems, which is called homographs, the phishing problem. Let me show you some examples of homograph domain names -- names.

You see this one, first in Latin and then in Greek. It's the same one when you get into capitals. It goes all along this list.

So we really had a problem with phishing. You could have even more problems if we allowed mixed scripts, so we just forbid it. Homograph domain names can mislead the user to wrong addresses with phishing problems, as we all can understand as we all faced. So you see this one is exactly the same, although one is in Greek, the other one is in Latin characters. And with no mixed script.

Was it necessary to regulate? It was necessary, unfortunately, because if this issue was not regulated, the user would end up with visually similar but different domain names. That would actually create phishing troubles. The possible misuse of these domain names had already created issues and problems when we started to register domain names to other registries, and we had to do something based to their own experience.

Both ICANN and CENTR had responded to this issue, and they proposed to the registries to act against it. And because of the close similarity of Latin characters to the Greek characters, the problem would soon become substantial.

So what did we do?

We had to select each and every character in the domain names, and check it against the same character of the Latin characters, because if we had the visual similarity, then we would probably have a phishing problem.

Each character of a word is a homograph character. Then we check to see if there's Latin-based domain names that's registered to the registry database, so we create from the Greek characters visually similar Latin-based domain names. We check it against the registrations through our database and if the domain is registered, then we have a different procedure.

Let's see an example. Let's take this one, which is in Greek. But I guess you already imagined what this word is. Without the TONOS, it becomes this one. And this one. If you change the letters. Because the "N" letter in front of the word is in capitals, the same with the Latin "N."

So we go on and reject the domain name. But if we take another one that is in Greek as well, we take it without the TONOS, we transfer it to Latin characters, we register it. We don't have it in the registration database.

That was quite complicated, and we had to create a translation table that I'm going to show you later on.

What is the activation of a homograph domain name? The homograph domain names can only be activated to the registrant who is using the initial domain name. So we did not exclude the domain names, but we only allow certain registrants to register these domain names. If they have the domain name that corresponds to them in Latin characters. The homograph domain names are used for each registrant if his choice of domain name is eligible for creating homographs. E.g., the name Maria.GR does not have any homographs because of the letter R in the middle. The Latin character R cannot translated in any Greek character so you cannot have a homograph on that domain name. So if you have this [Greek word] anything domain name, because of the letter "P" in the middle, you can have the same domain name in Greek letters. So we exclude this domain from registration and we only allow the registrant of the first domain name to activate it.

For the domain names that preexisted this rule, if they had homograph domain names, we allowed them to register them. Whenever they wished.

If two domain names had the same homograph names, then we allowed none of the registrant to register these domains. Each homograph activation is charged and the bundle of domain names created acts as a single registration, so you can delete the whole bundle, you can renew the whole bundle, you can do anything that you could do with a normal domain name and the domain -- the bundle expires on the same day. Regardless of the day that you decided to activate your homographs.

The character substitution. Some of them are quite obvious. The alpha goes to A, the beta goes to B, the epsilon goes to E. Some of them look strange because they are lower caps, but when you get them to capital letters, they look the same.

We had two special groups of characters who brought us more problems because in variant forms, they looked like each other, and it depended very much on the character set that you could use and the fonts that you would use and stuff like that.

So we have all these characters and they can substitute one another.

Okay. The first line, five characters. The second one, three characters. They all can substitute one for each other in some cases.

We substitute each letter of a domain name with each other and reserve more domain names because of this special group, so you have this one -- I'm not going to explain it, or try even to explain it, but --

[Laughter]

>>VAGGELIS SEGREDAKIS: -- it's like that and it becomes worse on the next slide.

[Laughter]

>>VAGGELIS SEGREDAKIS: I'll just -- okay. So it goes a lot of domain names. We knew about that. Some of these domains were actually useful to the registrant. Some others of them were not useless or would never be registered by anyone. Anyway, we reserved these domain names. When you decide to register even one of them, we reserve the rest of them, and you are the only one eligible to register -- to activate these homograph domain names.

This is our character substitution table. You can see the characters, although...

Now, that was not the only problem. We had the Punycode problem as well, because the Greek language cannot be correctly represented unless you had each domain name corresponding both to the domain name in capital letters and then the domain name in small letters.

Because of the tonos, if we use the word like [Greek word], which means test, as a domain name, we expect that like in every other DNS form, you can have the same domain in capital letters and in small letters and the substitution of these is equal to each other. Not exactly. Because the word [Greek word] becomes like [Greek word] without the tonos, and the Punycode had not anticipated that, and they have [Greek word] with the tonos becoming [Greek word] in capital letters with the tonos, but that's not a word in Greek.

So we have to give each and every registrant both these domains, if we want the DNS to be exactly as it would be in Latin characters.

So let's see it in XN translation. Like [Greek word], the domain with the TONOS is the XN dot, and the [Greek word] without the TONOS is the other one. They don't match.

The Punycode translation is not a very efficient way to translate the Greek language to domain names, since for each word the user has to register two domain names to achieve this representation. So every and each of the registrants that would actually want to register a Greek word had to register two domain names. This fact was recognized by us, and we implemented our IDN system around it. So for each domain name, with the TONOS, the user gets its variant without the TONOS for free. The variant without TONOS is considered the main domain, because they actually become a bundle right away.

So the domain without the TONOS is the domain a user has to set up for his domain name to work as a DNS record.

We had to do something about it, so we used the DNAME. The DNAME is the command in the DNS that actually puts two domain names -- makes them work like they were a substitute for each other. So both these domain names are inserted in the zone file as DNAMEs, so that the user has nothing more to do for setting them up but to ask his ISP to set up the domain name without the TONOS.

So he sets up the domain name without the TONOS. We set up both of them in the zone file with a DNAME.

That could be a normal domain name, the first two lines, in the zone file, and the third line is the line that is required for any Greek domain name to be registered and fully operational.

Was it a solution? Not exactly.

Because the DNAME is not a total solution. You can actually substitute the domain name with another domain name using the DNAME unless you want to send an e-mail to the first domain name. To the DNAME domain name.

So you can have like [Greek word] and like [Greek word] with the tonos in the zone file and if you tried to access them by a Web browser, www.[Greek word].gr, they work perfectly. If you decide to send an e-mail to the domain that is DNAME'd directly to that domain, not info@[Greek word] -- with the tonos -- .gr, you fail. And that is because the DNAME works only for the branches of the tree that are below the first limb, so at the equal level, where the DNAME was first initiated, nothing works within e-mail client.

To solve this DNAME problem, we decided to provide the choice to the registrants to use their variants or homographs as normal domain names. If they decided that the DNAME solution is not working for them.

So we actually put each and every domain name with a DNAME. But if you wish, you can have your name with NS records, no problem, but then you have to go to your ISP and set up everything in double zone files, in double mail addresses and stuff like that.

Every other variant of the domain name is inserted in the zone file, either as a DNAME or as a fully qualified domain name. That's what I told earlier.

In case a Greek IDN is a homograph of Latin domain name, instead of a domain name by itself, all the homographs and variants are DNAME'd to the first one, to the Latin domain name, if it was registered first or if you registered your Latin domain name as a variant of a Greek domain name, then the Greek domain name is the main domain name and every other domain name is DNAME'd to that.

So the variants. Why should you only register like [Greek word].gr and get the domain name without the tonos and why should you not try [Greek word]. [Greek word] is another word but it can actually be used as a domain name. Both these words in capitals are the same. That was a third problem.

[Laughter]

>>VAGGELIS SEGREDAKIS: And they corresponded to the same word without tonos to the same domain name in xn--.

So we allow these registrations with the same procedure we use for the homographs but they can only be registered as well by the same registrant.

The initial domain, the homographs, the variants become an object we call in our database "the bundle." They can be either DNAME'd or inserted in the zone file with NS records, but the same NS records for all these domain names.

So we allow you to use NS records but we only keep one NS record set for all the bundle.

IDN.IDN. So why did you choose to present our policy today and not back in 2005 when we first thought about it?

The first answer is that we believe our system was -- or is one of the most complicated one in IDN registrations and we had to let the time pass to prove that it was okay and it was good for our registrations. We first initiated -- we first introduced the DNAME for every domain name, and then in the course we had to allow some registrants to use NS records as well, because the first problem with a DNAME record, nobody had ever mentioned about it.

The other thing is that we would like very much to express our interest in IDN.IDN entries in the root zone file. We are one more example that shows that local policing registration is the best way to move forward, especially when so many local parameters come into play in each IDN registration. I think that my presentation proves that. Nobody could have thought about all these implications on registering an IDN domain name in Greece.

Since our character set is not a Latin character, we are very confident that the multilingual Internet should start at the very top, and all characters sets should be allowed in the root zone.

We would welcome and we have asked to participate in any test phase of IDN.IDN domain names in the root, and let our users decide what domain name they wish to have us dot IDN, because as you know, because of no ISO, we have to choose or we have to help ICANN choose or we have to do something to take a common position on these things. We already have proposed to ICANN to use the following domain names in the test phase: There are five of them, as you see. One with two letters, one with five letters -- two with five letters, and two with seven letters. I don't know if of any use to a normal user. They could be, they could be not. If you use the second and third or the fourth and fifth, they should be DNAME'd even in the root zone. But I guess it is an opportunity for us all to check if we want another two-letter domain name beside IDN.IDN or if our local community or the users or the governments or what -- whoever decides wish to use something different.

Since no ISO 3166 could be adopted this time for the form of the dot IDN domains, we believe that user experience along with consultation with the local Internet community could be a solution for the first adoption of the IDNs in the root zone.

That was all. I'm sorry if it was quite complicated.

[Laughter]

>>VAGGELIS SEGREDAKIS: I can take any question and try to be as clear as I can.

>>MING-CHENG LIANG: Thank you. I think you should be on our IDN working group. We should invite you in. It's complicated enough to give us some troubles. Any questions? Yes.

>>EMILY TAYLOR: Thank you very much, Vaggelis. My brain hurts really badly, so goodness knows how it must have been for you. You described a whole load of checking, and different ways of getting around various problems. Are those checks all done manually, by actual people looking at things, or --

>>VAGGELIS SEGREDAKIS: No, nothing is manual. All is automated.

>>EMILY TAYLOR: It's all automated. Thank you.

>>MING CHENG-LIANG: That makes life easier, right?

>>EMILY TAYLOR: Yeah.

>>MING-CHENG LIANG: Any questions?

>>WILLIAM TAN: Thank you for your presentation, Vaggelis. I think it's brilliant. And, yeah, I just wanted to check with you if you guys do an EPP based registration or --

>>VAGGELIS SEGREDAKIS: Yes, it is an EPP based registration all the way.

>>WILLIAM TAN: How do you represent activation associating a variant to an existing domain name.

>>VAGGELIS SEGREDAKIS: I don't remember the exact one, but there is a command in the EPP that -- I think it's an extension, our extension that allows you to do that over an EPP server.

>>WILLIAM TAN: Okay. So you have to verify that someone who comes in and says "I am registering a variant of the original domain," he has to prove to you that he owns the original domain, right?

>>VAGGELIS SEGREDAKIS: It is quite easy because if you activate the variant or the homograph, it -- it is activated only using the same registrant ID, so you cannot change the ID data.

>>WILLIAM TAN: Right. Thank you.

>>VAGGELIS SEGREDAKIS: Okay.

>>MING-CHENG LIANG: And, yeah. I think state your name before you speak. I'm sorry, I didn't --

>>WOLFGANG KLEINWAECHTER: My name is Wolfgang Kleinwachter. I'm from the University of Aarhus, and I have a question to IDN.IDN. It's more a policy question. You know, formerly, the dot IDN would be a new TLD, a new root zone file, so -- and my question is also to ICANN. Do they have a policy? Will this be a new delegation, or is this part of the delegation for dot GR in -- in Roman letters or could it include also the opportunity to create another national registry, and has it to be the same letters as the characters, like GR? I heard from Russian colleagues that they have dot RU in Latin letters and they plan to have a dot RF for Russian Federation in Cyrillic letters, which would [inaudible] dot RU, but it means the question is, is this now a start -- do we start a process of multiplying national registries or will this be under -- in the hand of the existing, because at the moment, you know, the ccTLD is a monopoly in the country, so would this mean that you have then suddenly competition on the ccT level in the country between dot GR and dot IDN? Thank you.

>>VAGGELIS SEGREDAKIS: I really don't know. I think policy is something that ICANN actually is looking into, but it could be anything. I don't know.

>>MING-CHENG LIANG: Sorry. I think the part -- it is actually up to us to get input to this after our discussion and get input to the ICANN to maybe see what we should do. Sorry, yeah. You are first, okay.

>>HILDE THUNEM: I'm Hilde Thunem from the Norwegian registry. I think the dot IDN questions are very, very interesting but I think this is also what the joint GAC/ccNSO working group has been trying to work on. And we will hopefully as the ccTLD community give input, and what they are trying to do at the moment is identify what is the questions, not what are the answers. Some of us might have strong opinions on whether there should be competition or not. At the moment, what they are doing they are listing a question, should there be an old registry or should there be another registry. That's the question. What the answer is as well. We will have to come up with a process for actually answering the questions. I am sure we will not be the only community in ICANN or outside of ICANN interested in giving input into that.

But to come back to the presentation from Vaggelis, I thought it was, well, very interesting and it made me very happy that we have only a few characters that we have introduced in IDNs.

[ Laughter ]

Because this sort of like looking at, thinking, yeah, homographs, we managed to avoid them, thank God.

You were talking about that you had a procedure where you checked when somebody wanted to register an IDN that there was no sort of homograph in the Latin character set and if there was, they weren't allowed to register. If it wasn't, they could.

If they can, like the cyclops (phonetic) or whatever example, will it then block the Latin registration?

>>VAGGELIS SEGREDAKIS: Yes, of course, it is the same both ways.

>>HILDE THUNEM: Thank you.

>>MING-CHENG LIANG: I think the last question -- maybe we can go to Hiro. Maybe after the next presentation we will have more questions if we have time to do that.

>>HIRO HOTTA: My name is Hiro Hotta from JP. My question is relating to IDN ccTLD. How many homograph or variant names does your country naming Greek characters have?

>>VAGGELIS SEGREDAKIS: You mean the language or do you mean because of the registered domain name?

>>HIRO HOTTA: If you want to have some string as a ccTLD IDN string, there may be some variants or homograph names so I would like --

>>MING-CHENG LIANG: I think I can refresh the question a little bit. If there is only one IDN, you can choose for your country. Will there be enough, or will you need something else?

>>HIRO HOTTA: If you have many homographs as a Greek country name, you have to put all the variant --

>>VAGGELIS SEGREDAKIS: If you go back to, let's say, two letters --

>>HIRO HOTTA: Not two letters.

>>VAGGELIS SEGREDAKIS: It is quite easy. If you have to choose one of the bigger ones like alas (phonetic) or alava (phonetic) ,then I think it would not be appropriate if you just dismissed the other one because the language would not be exactly represented in root. I don't feel different from Latin speaking guy next to me, and they can use both Latin caps letters or small form letters to visit the Web site. So it should be the same for everyone.

>>HIRO HOTTA: So you had --

>>MING-CHENG LIANG: How many will be enough?

>>VAGGELIS SEGREDAKIS: I think two will be enough because the tonos -- the word with the tonos is requested because of the small letters and the word without the tonos is also a requirement because of the writing in caps.

>>HIRO HOTTA: And do you think that both of them should be in the root zone?

>>VAGGELIS SEGREDAKIS: Sure. What's the other way to DNAME them?

>>HIRO HOTTA: Thanks.

>>MING-CHENG LIANG: Thanks. I think our time is a little bit short, and let's go to the next presentation. I think we will have an IDN group report from Jonathan first and then we have Minjung to talk about the crossover issues. After that, if we have more time, we can have more discussion over this interest in Greece issues and also the other issue. Thank you.

Jonathan?

>>JONATHAN SHEA: Good afternoon. I'm representing the IDN second level subgroup to present to you our findings. I just want to thank William Tan from Neustar and Mohammed El Bashir from SD for contributing most of the information.

The goals of our subgroup are very simple. Firstly, we just want to get together the experience from existing second-level IDN domain operators and hopefully we can use this experience for consideration in formulating the IDN -- the top-level IDN policies.

Secondly, we also identified whether there are potential interaction between the second and the top level. And if there are such issues, then what are the possible solutions.

So the first issue we identify is that -- is in relation to the language table. There are already second-level IDN in operation and they are using existing language tables. Some of them are registered with IANA, some not.

So the natural question is when there's a new top level IDN being introduced, is it likely that they may choose to use a slightly different table or totally different table altogether? Of course, we encourage a new IDN TLD to reuse -- whenever possible, to reuse existing language tables with proven community support.

Also, there are many second-level IDN introduced with categories which are equivalent to dot com, dot net, dot org, et cetera. The question is then should there be a sharing of this second level tax or labels to avoid having two radically different sets of labels at the second level being introduced by the different registries.

And we think the natural answer is that, no, we should limit it to the respective local communities to -- I mean, the registry to decide on this second-level categories and introduce what level they think it should be the most suitable for meeting the needs of the local community.

And this is also one of the issues when a registry already has second-level IDN labels register and if they want to introduce another one, should we consider some kind of aliasing thing between the two name space.

Since we are talking about the second level, we believe this should be a local concern and the local community should decide whether the new name space actually is the same as the existing one or whether they should create a new one under the new IDN second-level label.

And it is also likely with the increasing popularity of the ccTLD registry introducing their second-level for -- open up the second level for public registrations. It is actually a common problem with most of these registries whereby restricted second-level IDN label already introduced and in use.

If we open up the second-level space, it is quite likely that people will rush in and register second-level IDN which may initially look like -- well, is -- sounds like some of the it -- one or two of the already in use second-level labels. So if that is the case, should there be measures to prevent that from happening?

Again -- therefore, registries are really highly recommended to consider these measures before they open up their second level name space. They should anticipate that it is likely that people will register IDN -- second-level IDN which may be homographs of the already in use restricted second-level labels.

But I believe, again, this is up to the local registry to consider. It may be different for different countries or regions.

And also we considered the usability as an issue in relation to introduction of IDNs. This is in particular considering if you have an ASCII top level and you introduce your second-level IDN under this ASCII top level, the first obvious thing is that whenever people type in this domain name, they have to first type in the non-ASCII characters and then followed by the ASCII top-level character. It actually slows down the typing a bit because most of the time they have to switch the input method on the keyboard.

And this is especially more problematic when you consider the right-to-left languages because the ASCII top level is always left to right and it is always on the right-hand side of the last -- of the dot. But it is -- this is actually very natural for countries using right-to-left languages and, therefore, this is actually more compelling for them to deploy the IDN at the top level so that the whole string can be right to left, can be more natural for the users.

The last point is about differences in practices in existing implementation of IDN second level by different registries. A question like whether they start a Unicode string in their database or they have both versions, the Puny d the Unicode and also the WHOIS. Some registries may allow non-ASCII information displayed on the WHOIS information, some do not.

We believe, therefore, there is actually an ongoing need for a sharing of information and experience like this and, if necessary, consider some kind of recommendation or guideline for sanitizing the practices in these different aspects.

On passing our subgroup also noted that IETF is in the process of updating some of the IDN (inaudible) and some of the other related standards. It is important there should be a linkage between the ccNSO and IETF to ensure that the ccTLD community is well-informed of the latest updates in the Punycode standards.

The last part we want to make is echoing the issue number 6 we raised two slides before. Despite there are already four different language communities like CENTR for European and Arabic domain names and the also CVNC, Chinese language community, we believe maybe a more global level coordination is needed. It would be best if we can have some kind of a sharing mechanism like a working group. One option is to make this working group ongoing so we can continue to share the information and experiences in operating both IDN at the second level and at the top level in the future.

Thank you.

>>MING-CHENG LIANG: I don't think we have time for questions at the present time. I would suggest, Jonathan, maybe you need to talk more with Vaggelis in order to incorporate some of the points into the second-level domain or something like that.

>>JONATHAN SHEA: Sorry?

>>MING-CHENG LIANG: Talk more with Vaggelis. I think if you have questions, we will leave later to do that.

Next we have Minjung to talk about crossover issues.

>>MINJUNG PARK: Good afternoon, everyone. My name is Minjung Park, and I am from ccNSO IDN subgroup, and I will be dealing with crossover issues.

The goal of the subgroup 3 is to identify crossover issues arising from the introduction of IDNs at the top level including new gTLDs.

Our working group came up with two main points regarding the crossover issues. The first one is on the application criteria of IDN TLDs in the new gTLD process. Let's look at the new gTLD process.

In the preliminary evaluation stage, the application for the new gTLDs including IDNs will be approved if application meets objective, technical and business criteria; and if technical stability is assured; and if string is not a reserved name, if string is not confusingly similar to existing or proposed string; if there's no string contention, and, lastly, if there is no formal objection raised.

Should these solution criteria be applied to ASCII and IDN TLDs in the new gTLD rounds, or are those enough for IDNs as well?

In our discussion among our working group members, we reached a consensus that we need an additional criteria for IDN TLDs in consideration of IDN TLDs' distinct nature which would be the language community.

So then what should be the additional set of application criteria for IDN TLDs in the new gTLD rounds? Should the applicant be required to demonstrate broad-based support from the local language community? This issue has already been dealt in the GNSO community and the GNSO IDN working group's final report, we can find agreement that there should be a process for consultation including relevant language community when considering IDN gTLD strings.

So, yes, if there is a need to demonstrate support from the language community, then how do we determine the local language community issue arises? And this is a very complex and difficult one to answer and we will be needing further discussions on that.

And we can think of that in some cases it could be relatively easy to define a corresponding local language community, and one example would be Korea where the population is mostly from south Korea, the one country. But there are other cases as well where multiple languages are used in multiple countries. So in those cases, we might be in need of another measure to demonstrate the support from the local language community which will be the consultation process with this ccNSO and possibly with the GAC.

To have a consultation process, we have to come up with how to incorporate the consultation process within the new gTLD process. And that's where we need the input from the CC community.

And the other issue is on the reserved geographical and geopolitical names. The geographical and geo political names as defined in the GNSO working group, all geographic and geopolitical names in the ISO-3166-1 list, names of territories, distinct geographic and geopolitical names as ICANN may direct from time to time. Again, in the GNSO IDN working group final report, they have reached to an agreement that within the process for new gTLD consideration, the process for determining whether a string has a geopolitical impact is a challenge and that GAC consultation may be necessary but may not provide comprehensive responses. Should the ccNSO be included within the consultation process and I think that is a definite yes.

The problem would be to find a suitable consultation process to find a way to cooperate and jointly work with the GAC and relevant language communities as well.

And we also have an issue of whether there should be a consultation process prior to the application or during their application or maybe both.

This is the end of my presentation and I would be -- it would be very appreciated if you could provide some more input and maybe more issues regarding the gTLD process. Thank you.

>>MING-CHENG LIANG: Thank you. I think we don't have time for questions.

>>CHRIS DISSPAIN: Can I make a suggestion that what we do is in the case of both of the working group papers we publish the papers, much the same as we are going to do with the other IDN paper. We publish the paper as soon as we can on the ICANN Web site, send it around to all of the lists and ask for comment, input and any additional issues that need to be dealt with.

And then the working groups can take that comment and the goal, I think, would be to produce eventually an issues paper on each of the two working groups.

>>MING-CHENG LIANG: That will definitely be the case.

>> No, this is not important. No, this is a very procedural matter. I see that many of the presentations that we've had so far in the ccNSO meeting have not been published and I would like those presentations to be published.

>>CHRIS DISSPAIN: We will make sure it gets published.

>>MING-CHENG LIANG: I think we have another session of IDN tomorrow. So if we have more questions, we can discuss it tomorrow. I will hand it back to Chris.

>>CHRIS DISSPAIN: Thank you, Ming-Cheng. Thank you very much. Thanks everybody for the hard work because there is a lot of work to be done.

We are going to move on and do regions now. So those of you that were at this morning's meeting with the GAC will know that our regional king is David Archbold.

>>DAVID ARCHBOLD: Thank you for that glowing introduction, Chris.

Ladies and gentlemen, good afternoon. Some of you may have noticed that I had severe flashback problems this morning to previous incarnation in Korea that I had as a civil servant. I found myself wearing a jacket and tie to GAC. I am glad to report I am feeling much better now.

[ Laughter ]

I don't propose to go through the presentation again. You saw one version at Sao Paulo. Those of you who were at GAC this morning, saw another. The paper has been circulated. I thought I would give credits for the ccNSO regions working group. That's the names up there.

I will, first of all, express my thanks for their contributions which were contained in the paper that went round and also absolved them from any responsibility for the proposed amendments that I'm going to talk about today, which have resulted from the discussions that we've had over the last couple of days here in Lisbon.

So I would like to swap now over to the actual document itself. And I will blow that up a bit. What I would like to do is just mention one amendment that I did which may not be of great significance to you but it's there in paragraph 7 there.

I -- or we said that the current ICANN review only covers the allocation of countries to the regions and not the actual names of the regions themselves. I have actually looked at the bylaws again. I don't think that's correct so I have just deleted a paragraph.

I actually put Australia about to Australia/Pacific there, Chris.

>>CHRIS DISSPAIN: Make sure it stays in a different color and remains underlined.

[ Laughter ]

>>DAVID ARCHBOLD: And I just thought I would then go through to the actual recommendations at the end and perhaps we could have some discussion both about the recommendations themselves and the changes that I made. Can you see that? Is that in the center of the screen? Can you see it all or is it too big? Is that better? Now I lost my place.

Okay. The changes that I've proposed are in blue and underlined like Australia. Paragraph 43, if we can just sort of do it paragraph by paragraph. Concern about the ccNSO's regional structure has been raised and discussed at the last two ccNSO meetings at least. No opposition to adopting a more flexible approach has been voiced. It is, therefore, recommended that at a minimum the interim solution detailed in paragraph 26a -- that's the one concerning giving choice to the overseas territories -- be implemented and I have said forthwith. Always optimistic.

Then some additional wording. Given the ICANN region's review has not been completed, this should be done by specifies procedures in accordance with clause 4 of section 4 of the bylaws, rather than seeking to amend the bylaws. No changes in the rules for election to ccNSO Council would be required.

Let me just explain that a little bit.

There is an ongoing regions review, we think. And that may well result in all sorts of changes to the regions, so let's not try and do anything in the short term to change bylaws. It's just not worth it. If we can get something done using the existing measures.

So before I go into the other -- the next paragraph, would anybody like to make any comments, ask any questions, or do you all agree with Paragraph 43 as-is?

>>CHRIS DISSPAIN: Can I just make a point? Just for procedure, so that everybody's clear -- some people haven't been to these meetings before -- what will happen with this report is it will go to the council formally for approval, and hopefully that will be -- if there's general consensus in the room, that will be tomorrow. And then the report would -- then the report would -- and it is only a report -- would then go out to the -- to the members' list for final clarification to make sure everybody's okay that the council has adopted it, and then the report would go to ICANN to form at least the start of a ccNSO submissions to their regional review.

That's the process. There was a question here.

>>EMILY TAYLOR: I just wanted to ask about work -- the work -- the suggested workaround with the bylaws, and I'm not familiar with -- with the relevant sections but perhaps you could just explain how the workaround will work and --

[Laughter]

>>CHRIS DISSPAIN: How does a workaround work.

>>DAVID ARCHBOLD: I don't give answers. I only ask questions.

[Laughter]

>>DAVID ARCHBOLD: It would be using, I think, Section 4 and Paragraph 4, which is now up on the screen. For the purposes of this article, managers of ccTLDs within a geographical region that are members of the ccNSO are referring to ccNSO members within that geographic region, regardless of the physical location of the ccTLD manager. And the important bit: In cases where the geographic region of a ccNSO manager is unclear, the ccTLD member should self-select according to procedures adopted by the ccNSO council.

So I'm suggesting that it is --

>>CHRIS DISSPAIN: What you're suggesting is that we include in our definition of, "Unclear" circumstances where -- well, no -- because they're pretty well defined, but circumstances where a territory is physically located in a geographic region, but is, in fact, a member of a different region. Currently a member of a different region.

>>DAVID ARCHBOLD: Yeah, yeah. And then there's the opportunity there to lay down such procedures as the council wants to lay down to either restrict it or open it up or whatever.

>>CHRIS DISSPAIN: Yeah. The stress -- the point that I would stress about this is if we do this, is that we would -- we would expect that a ccTLD manager in that circumstance -- and there are not actually that many of them -- would have liaised with their -- their government in respect to any change.

Because the current situation is that the -- is that the reason why they are mandated to be -- well, they're not mandated. The reason why they are in our list in a different -- in a different region is because the GAC advice to the -- to ICANN was that territories should be in the region of their -- whatever the right thing -- word is. "Mother country."

And the reason why the ccNSO bylaw is drafted as it is is precisely because this -- we knew this issue was on the table, and we couldn't draft it in a way that simply said, "We're going to ignore it," but we could draft it in a way that we felt gave us some leeway. So what Dave is actually doing is taking -- is taking refuge in the way we drafted the bylaws in the first place. I'm not sure that it's actually -- I know there's a question from somebody. I'll get to it in a second. I'm not sure that it is actually an issue, really, of any major -- of any major concern. I suspect that in the event that we send this paper out and we -- and we publish, if it is going to cause a problem, we'll know about it, and as I said at this stage it is a paper, so we'll go from -- we'll go from there.

Debbie, did you have a -- oh, sorry. Hilde. Sorry. Hilde, did you have a question?

>>HILDE THUNEM: I think it seems to me that this could be an okay minor fix. As the GAC indicated in their meeting, they have very clearly highlighted the subsidiary principle, which actually supports the possibility of choosing a region.

>>CHRIS DISSPAIN: Exactly.

>>HILDE THUNEM: But this is a political minefield where we should proceed with extreme caution, I think.

>>CHRIS DISSPAIN: I agree. Hilde I would the other thing, to sort of keep in mind, is that if people start self-selecting away -- or into regions, we might drop under the level of four members per region.

>>CHRIS DISSPAIN: That -- yes, I acknowledge that could have been an issue but, in fact, it isn't because that level is only required in the transition article prior to the formal -- the formal setting up of the ccNSO. The requirement of having a minimum of four members per region is only in the transition article, and ceases to be a requirement as soon as the ccNSO is formally constituted, which it was two years ago.

So that in itself is not an issue. Okay? Roelof, did you have a question?

>>ROELOF MEIJER: Yes. Well, it's not a question. It's more of a remark. I find this a very difficult issue, and also this recommendation, but I seem to be the only one, so maybe I shouldn't say too much about it. Especially since dot NL is not affected in any way.

>>CHRIS DISSPAIN: Yes.

>>ROELOF MEIJER: But the idea of a country, whoever that may be then, choosing the region in which it is for me something almost impossible to grasp. And I think it would be better to stick to an internationally accepted standard or something, because you risk getting the discussion every now and then again.

>>CHRIS DISSPAIN: Yes.

>>ROELOF MEIJER: And maybe the next ccTLD manager might want to move back to his old region for some obscure reason. So I'm not very much in favor of it, but, I mean, it's not really a strong issue for me.

>>CHRIS DISSPAIN: I understand your point, and the point that I would make is that we're not actually saying that a ccTLD manager can choose their region. What we're saying is that there are some -- there are some territories that are regionally challenged that fit into the -- that fit into the original ICANN definition that's -- that said that there are -- there will -- there may be occasions where it is unclear which region a ccTLD is in, and that in those circumstances, the ccTLD can -- can choose their region.

That is actually in the original ICANN documentation, I believe. I'll check it, but I'm -- I'm fairly sure I'm right. But in any event so it's not a case of dot NL being able to say, "Look, we've decided we'd like to be in the African region."

>>ROELOF MEIJER: Oh, that's a pity.

>>CHRIS DISSPAIN: Yeah, I knew you would --

>>ROELOF MEIJER: But this is just my point. The fact that I can then follow an international standard has caused this confusion.

>>CHRIS DISSPAIN: I agree.

>>ROELOF MEIJER: And now making changes to something which is not adhering to a standard into another direction, not towards the standard but away from it might -- to my opinion only complicates matters. It would be better to try to convince ICANN to adhere to the international standard.

>>CHRIS DISSPAIN: I agree. I accept that. Can I suggest to you that the way of dealing with that is to -- in order for us to implement this recommendation, we would need -- even though it may only be a procedural change pursuant to the bylaw, we would still need to draft an internal ccNSO rule, and there is already a document that contains internal ccNSO rules, including the rule that, you know, council decisions go back out to members for -- for checking, et cetera, and that -- and that if we cannot reach a satisfactory consensus, that what we have drafted is workable, then it simply isn't going to go -- it simply isn't going to happen.

So all -- what this is doing is actually saying, "Let's accept that it's an issue that we can solve ourselves. Now let's go and see if we can draft the necessary rule to allow for it to occur."

And it's at that point that it may be that your -- all of the issues that you've raised will make it difficult, impossible to create something that is satisfactory.

I think what -- what I've got -- I've got the hand in the back there. I think what Dave is saying is that -- well, I can't speak for you. You can speak for yourself. But I think what Dave is saying is that this is the one thing that we can actually do within the ccNSO ourselves, and we should probably give it a try. Is that -- is that fair?

>>DAVID ARCHBOLD: Yeah, I think that's a fair comment. What I'm also trying to say is that because we believe there is a full ICANN review going on, it should be almost done on a -- I won't say a "temporary basis" but I mean further down, you will see that there is mention of the ccNSO noting to ICANN that if they put in a new regional structure, clearly ccNSO is committed to implementing that structure. So this is almost a temporary issue until such time as a full review is completed and this recommendation is implemented.

>>CHRIS DISSPAIN: Yes. There was a question at the back?

>>BERNARD TURCOTTE: Yeah, this is Bernie.

>>CHRIS DISSPAIN: Oh, hi, Bernie.

>>BERNARD TURCOTTE: Hi, Chris. First of all, I'd like to thank Dave. I think it is a great report and it was a great presentation this morning. Second, I'd like to say that Roelof, you're not alone.

[Laughter]

>>BERNARD TURCOTTE: I have a problem with any system for this kind of thing due to bitter personal experience that is not based on outright, plain, unarguable standards, period, end of the story.

I mean, the fact that someone is in a region in here or not, I think makes very little difference 98% of the time. If we want to try it for a while and everyone can sort agree to it to see if it actually makes a difference the way things play, then great!

But I am worried for us embarking on that. I'm not saying the work is bad. I'm not saying the intentions are bad. It worries me.

>>CHRIS DISSPAIN: Okay. Hilde? Wait. Just wait a sec.

>>HILDE THUNEM: I'm actually in the [inaudible] corner as well, even more when it comes to sort of the next recommendations that used to be in the paper of creating new regions. And after asking my fellow members here, I realize that we have just had a council election and I think that means it's about a year till the next time?

>>CHRIS DISSPAIN: Yeah, yeah.

>>HILDE THUNEM: Which means that there's no need to do this at this point in time because the only thing -- as far as I know -- we use these regions for in the ccNSO formally is for electing council members.

>>CHRIS DISSPAIN: Sure.

>>HILDE THUNEM: And then perhaps trying to, instead, push ICANN to have a look at using an accepted international standard. That would solve problems for some people, and at least that we could hopefully say that this is something most of us accept. None of us will agree on everything anyway. That would be more productive than making a change at the moment for trying something out which might --

>>CHRIS DISSPAIN: Okay.

>>HILDE THUNEM: -- sort of break things up, and we have no real reason to use -- do it.

If it's talking about sort of membership in regional organizations, that's something else and that's not dependent on ICANN's regions at all.

>>CHRIS DISSPAIN: Yes. And that's not what we're talking about, so that's -- that's clear. Okay. That's fine. The purpose of this discussion is to get -- is to get the feedback from the room, so --

>>DAVID ARCHBOLD: Yeah. I think that that's fair enough. I mean, there is another way that you could look at it as far as some of the overseas territories are concerned. Which is a more legal perspective. And I didn't particularly want to go into that, but it is that the justification, if you like, for putting them -- the territories with mother countries was allegedly based on citizenship.

Now, in fact, they've got that wrong as far as certainly all the British-dependent and overseas territories are concerned, because they are not citizens of the U.K. So you could take the line, certainly as far as the British ones are concerned, that the allocation is legally incorrect.

>>CHRIS DISSPAIN: Yeah. Okay. Let's move on to the next one. I mean, we're -- as I say, the purpose is to go through the report and then we'll -- the council will discuss it. But I take -- I do understand what people are saying. I think it is -- it is -- there is an argument for saying that I think Hilde's point is a very good one, that you've got a review going on, and the elections have happened, so -- but let's move on, Dave, and we'll --

>>DAVID ARCHBOLD: Yeah. Sure.

The next one is a change slightly to what was there before. It is recommended that ccNSO permit or encourage -- choose your word -- the formation of just semiofficial subregional or, for that matter, interregional groups, where there is a local need. Such groups would not at this stage have council representation but their status should be reviewed at some time in the future, particularly if the outcome of the ICANN regions review does not solve their concerns.

>>CHRIS DISSPAIN: Now, this is a -- this is effectively -- this is effectively a bootstrapping clause. This is basically saying if you are -- if you're a group of territories or countries that think they should have their own region or should be -- have their own separate recognition as a region, fine. Then what we will do is support you and encourage you to set up a -- an unofficial subregional organization and show that you actually are suited to regional -- regional status. And then -- but use that as part of the ICANN review. Bernie?

>>BERNARD TURCOTTE: [Speaker is off microphone]

>>CHRIS DISSPAIN: Can't hear you, Bernie.

>>BERNARD TURCOTTE: Pardon me.

>>CHRIS DISSPAIN: There you go. Got you now.

>>BERNARD TURCOTTE: Okay. I think I'm fundamentally against this because I think to be consistent, if I believed that the only thing we should be touching in this area is going towards a formal standard -- whichever one it is, but formal standard of the U.N. seems to be the reasonable one -- then it's giving people, I think, false hope if that is what we're going to be aiming for. I -- you know, I don't like giving people illusions of things. I think there's a really good reason, again, why these things are set in stone by other people, and I don't feel at all qualified to entertain or consider this. I find this even more worrisome when Dave, quite correctly, points out that some of this stuff that we're doing right now is not even correct because it's based on some weird stuff.

[Laughter]

>>BERNARD TURCOTTE: And that the ICANN stuff doesn't even follow any standard definition of these things. It just continues to worry me, continues to worry me that we are creating expectations within this group, which we may not be able to deliver on.

>>CHRIS DISSPAIN: Okay. Thank you, Bernie. Lesley had a question at the front here and then Charles. While the microphone is coming down here, you presumably, however, Bernie wouldn't be averse to us, in the -- in the ICANN regional review suggesting that we should have a structure that allowed for subgroups.

>>BERNARD TURCOTTE: It depends how you would word it.

>>CHRIS DISSPAIN: Yeah, of course. Lesley?

>>LESLEY COWLEY: Yeah. I was just going to take this conversation to a different level, as opposed to editing on screen, which is always a bit of a dangerous thing, I think. One of my comments coming up on the operating plan and the implementation of the strategy is about how ICANN can encourage greater ccTLD participation generally, okay? And in particular, in the ccNSO, because I still think we have a long way to go in terms of ccNSO participation. And I think that is a sort of separate body of work, and this, to me, sort of seems a subsection of that, that that might be one of the ways in which one could increase participation. I'm not sure we can come out with those recommendations until we've done that research and have a much better developed understanding as to what the barriers are currently.

>>CHRIS DISSPAIN: Yep. Charles.

>>CHARLES SHA'BAN: Yes. Thank you, Chris. I'm against Bernie this time, so...

[Laughter]

>>CHARLES SHA'BAN: So I'm in favor with this recommendation because I think this even can set an initiative. The ccNSO will make. And I think the full ICANN can take it in the future. Because this will help the local communities, especially in the developing countries, whether a lot cannot sometimes send the ccTLD managers to attend their meetings, and as I said, in the future, maybe ICANN will take this initiative and do it in the different ICANN regions.

So other sectors who can't submit their views, their -- et cetera, so they can follow up the ICANN processes and submit their feedback.

>>CHRIS DISSPAIN: Okay.

>>CHARLES SHA'BAN: And be more active in general. Thank you.

>>CHRIS DISSPAIN: Okay. I -- I wonder whether we might not be better -- given that -- given that it's fairly clear that at this stage, the two clauses that we have so far covered could not be described as having reached a level of consensus, would we be better, I wonder, to take this document out, to deal with specifically the clauses that effectively amount to recommendations, and to -- after this meeting, to draft a document based on the clauses that effectively amounts to recommendations, with options. In other words, if you go back to the point that -- the clause that we were just talking about, Option 1 would be to just do it. Option 2 would be to not do it but to -- but to recommend that the ICANN regional review allowed it to happen and so on. That would then give the -- we would then send that out to everybody and everyone would then have an opportunity to specifically comment on each particular clause. And each particular alternative.

So just to take one example again, Dave, because I guess I'm not clear, if you go back to the point about choice for certain ccTLDs, the report -- the report would say it's clear that there is a -- that there is a desire amongst a number of ccTLDs to have this choice. The alternatives are: (a) you don't care about that so you just leave it, you don't worry; (b) we use this bylaw method to make it happen; or (c), we push really hard through the ICANN regions review process to have a mechanism put in place that allows it to happen.

Is that -- does that make sense?

>>DAVID ARCHBOLD: Yeah, that's fine.

>>CHRIS DISSPAIN: Is that -- Hilde?

>>HILDE THUNEM: I think -- well, I think at least you pointed out, yes, we're not in complete consensus and we might need to go back and try to revisit this issue --

>>CHRIS DISSPAIN: Yes.

>>HILDE THUNEM: -- is good. I think also when it's talking about sort of encouraging subgroups, et cetera, I don't really think we need to have the sort of ccNSO recommendation for this. I mean it's up to each regional organization to have whatever membership they feel useful. It's up to -- if some of us want to do IDNs -- and I know there -- especially in Asia, there's been people arranging IDN events. They don't need to have ccNSO recommendation to sort of gather a group of people with the same interests to talk together and set up workshops. So I don't -- and anyone can come into a ccNSO meeting, whether you're a member or not. So you don't need to be officially recognized as having the right of being here, so I think we don't really need to recommend the setting up, backup if it's there and if there's local need or people set up a special working group, we would like to have them here.

>>CHRIS DISSPAIN: Okay. Anybody else? Bernie?

>>BERNARD TURCOTTE: I'm just wondering -- maybe I missed it -- have we had formal comments from the GAC on this?

>>CHRIS DISSPAIN: Nope.

>>BERNARD TURCOTTE: Okay. Well, I -- given the nature of this personally, if I'm trying to make an informed decision and trying to bring this forward, I think I would need at least to understand where the GAC is sitting, relative to these kinds of terms. Secondly, I completely understand and support Hilde's point of view.

Third, I have absolutely no problem with our report from the ccTLD stating all the issues that Dave -- that there are a lot of people in the cc's have issues and we're trying to address them. I understand that and I think it's our job to bring that up. So I really don't have an issue. It's just I am concerned where some of this will lead us or it may create expectations. So for me, at least, it would be interesting before I'm asked to vote on any form of this if I would understand where the GAC is sitting, relative to such proposals. Thank you.

>>CHRIS DISSPAIN: Okay.

>>MICHUKI MWANGI: Michuki Mwangi from Kenya and afTLD. I think I would relatively be against the proposal because -- and also in support of what Hilde mentioned, is that one, there lacks a clear structure as to what defines ways [inaudible] subgroup and it will probably -- without a clear structure [inaudible] or rather what constitutes a subgroup or a subregion, then all sorts of groups will end up being formed which probably will not be an ideal situation.

And secondly, I would want to look at this from the perspective that those issues would probably be dealt with at a regional level, much more effectively, as opposed to at the ccNSO level, and there are those issues where wherever they're binding enough and draw the sufficient support from other regions will probably be escalated to the level of the ccNSO and dealt with at that point. So I believe at that point then there will be probably the need for working groups, for instance, at the ccNSO level to deal with such issues, as opposed to creating subregions at this level. Thank you.

>>CHRIS DISSPAIN: Okay. What do you want to do?

>>DAVID ARCHBOLD: Don't really have a problem. I think it might be useful, actually, to continue down with the other --

>>CHRIS DISSPAIN: Let's go --

>>DAVID ARCHBOLD: -- paragraphs. I mean Bernie mentioned something about consultation and, in fact, that is covered in 45. That we -- the group should be tasked with obtaining the feedback that we've already tried to get, and that refers back up to -- I've lost my paragraph numbers now. Sorry.

>>CHRIS DISSPAIN: 38 and 41.

>>DAVID ARCHBOLD: 38 and 41. That's talking about the Arab states. ASO and ICANN staff.

>>CHRIS DISSPAIN: Yeah.

>>DAVID ARCHBOLD: And GAC and ALAC. So I absolutely agree with you, Bernie. I do think we need to do some more outreach to these other groups and get their feedback.

The next paragraph actually now talks about submissions to ICANN, which I think covers most of the points that we've talked about. The one that I've deleted here is to do with the -- the scope of the regions review, which as I said earlier, I think my first interpretation was incorrect. I don't think that's required, but then a recommendation that the regions working group be tasked with preparation of a submission from the ccNSO to the ICANN board which details as input to the regions review the concerns and potential solutions contained in the paper, with particular emphasis based upon the need for flexibility.

I've can added a couple of points that came from GAC this morning, which was the concepts of national sovereignty and the application of common sense when allocating countries to regions should be incorporated into the submission.

The papers should -- discusses from the ccNSO perspective the objectives that should be sought when designing an ICANN regional structure where there's more than one such objective, detailing the priorities that should be assigned to them. That was Peter Dengate Thrush's request. If the ccNSO view is that there should be continue to be more than one regional structure [inaudible] and that was another one that came from this morning's meeting and finally commits to appropriately amending the ccNSO's regional structure, should this be necessary, following the acceptance of the findings of the regions review.

>>CHRIS DISSPAIN: Okay. So on that basis, then, is everybody comfortable if we -- if we have -- if we ask the working group to incorporate the amendments that are here and send the paper out to everybody and go through a comment process. Now, we can do that and we can do that either just on the CC list or we can actually publish the paper on the ICANN Web site with -- with the comment mechanism in place that allows comments from every -- from anywhere. To come. Which may actually be the sensible way of doing it, given the points made about input from the GAC and so on.

>> Could we do both, Chris.

>>CHRIS DISSPAIN: Yes. Sorry. The second involves the first automatically, yes. So I'm happy to do both, yes. And then that way, basically what we'd be doing is we would be refining this document and taking the feedback and objections to various paragraphs formally and then we can -- we can -- we can work from there. Yes, Roelof.

>>ROELOF MEIJER: Yeah. Gee, sorry, I really don't like discussing procedures, but what would then be the status of the document because --

>>CHRIS DISSPAIN: It's just --

>>ROELOF MEIJER: I would just assume if I was a known ccNSO member, if there was a paper published by a ccNSO working group that it had the approval of the ccNSO membership.

>>CHRIS DISSPAIN: No. It's -- it would be published -- it would be published as a draft. It would be published as a draft paper for comment.

>>ROELOF MEIJER: And then not being a CCO, if I not were a ccNSO member, I would wait with my comments until there was something that was approved by the ccNSO.

>>CHRIS DISSPAIN: I -- exactly. And that's why I asked the question as to whether we should do that or we shouldn't do that.

>>ROELOF MEIJER: Yeah.

>>CHRIS DISSPAIN: It may be that the most sensible for us to do is to simply send the paper through to our lists and ask everyone for -- everyone within our lists for comment and input. And if that's what everybody is comfortable with, that's fine -- that's fine with me. And then what we would do is we would then prepare a draft paper which -- I'm sorry, prepare a draft paper which we would resolve to publish for formal comment. Is that -- that would be the mechanism.

>>ROELOF MEIJER: I think that would be better, because otherwise you risk asking the very large community to comment on the paper that has the support of a very small community.

>>CHRIS DISSPAIN: I agree. Okay. Good. Excellent. So if everyone's happy with that, then what we'll do is we'll get the working group to knock that into -- into shape, basically, but by adding alternatives and, you know, one way to do this would be this, you do it now, you do it later, you do it never, and we'll get that out to everybody as quickly as we can. So that we can -- we can move forwards. Every -- is everyone okay with that? I'll take silence as a yes.

Okay. Good. Thank you.

>>DAVID ARCHBOLD: Thank you.

>>CHRIS DISSPAIN: We're going to have a break now. At 4:00 we reconvene, and we have our two items on the agenda. One is on the -- actually we have two items, one of which is not on the agenda. We have our updates from ccTLD regional organizations and ICANN global partnerships, which is on the agenda. But just before we start that, at 4:00 for five minutes, the wonderful people from Puerto Rico have asked for five minutes so that they can just talk to us briefly about the sort of T-shirts and shorts you're going to need to wear --

[Laughter]

>>CHRIS DISSPAIN: -- in Puerto Rico and how you can manage to get your luggage there without having it lost.

[Laughter]

>>CHRIS DISSPAIN: So we'll be back at 4:00. Thanks.

[Break]

>>CHRIS DISSPAIN: Okay. We will be starting in a couple of minutes' time when we have all got our hearing back.

We will be starting now. You have all taken your seats. Jolly good. Excellent.

As I said before we went to the break, we will start off with a very brief presentation on Puerto Rico and then we are going to move into our regional organization reports. So Pablo?

>>PABLO RODRIGUEZ: Thank you very much, everyone. We are honored to be here and we are honored to welcome you to Puerto Rico. I apologize for my voice. I'm having a cold, virus, that I just recently got. So I apologize for the voice.

There is -- as you know, Puerto Rico will be the next host of the North American ICANN meeting and we are here, among other things, to welcome you and to encourage you to come to Puerto Rico and participate in our meeting.

At this time, I would like you to take a quick look at our Web site which is found at www.ICANNsanjuan.pr. It is important to highlight that preregistrations are now open so please feel free to now open and register, preregister there. I will begin my presentation on Puerto Rico, and there are a few pointers that I would like to touch. The first one is to show you, as I mentioned just a minute ago, that preregistration is open and that you can go to ICANN.sanjuan.PR and click on preregistration. Although it looks -- it has the look and feel of our Web site, it is the ICANN Web site. So feel free to register there.

For those of you that have not made reservations yet, we will be publishing a special rate reservation code and you will use that and get the special rate for the hotels in Puerto Rico.

For those of you -- I have spoken to a few of you that have already made reservations, please feel free to send them to us via the ICANN San Juan, give us your reservation number and we will contact the hotel and make sure that you get the special rate.

With that in mind, I will move on now to Ms. Marimar Lidin from the Puerto Rico Tourism Corporation and she will give you all the details about Puerto Rico and everything else that you would like to know. Thank you very much.

>>MARIMAR LIDIN: Thank you, Pablo.

I must say I am very grateful for this opportunity on behalf of the Puerto Rico Tourism Company. I must say I haven't been surrounded by people of so many nationalities since I was in the U.N. club probably at age 18 in high school.

We are delighted to know that ICANN has chosen San Juan for the next meeting and the date, as you know, is wonderful because it is the start of the summer. It is from the 24th through the 29th of June. And as you know, Puerto Rico is very accessibly located. All of you can pass by our stand where we have been giving out information as to which are the best gateways to go into San Juan, whether you come from Europe, Asia, Africa or America. We are accessibly located through the main gateways and from this part of the world especially from Madrid with daily direct flights into San Juan and with connections from all the main European capitals as well.

We would like to go on and show you a little bit about where Puerto Rico is and how we are. The extension of Puerto Rico is approximately 9,000 square kilometers. That's more or less three times the size of the island of Majorca. It is not a very small island, but it is not very big. It is perfect to be able to discover in seven, eight, ten days and the capital of San Juan at the north where you will be meeting is the natural place to start. It is where it all started. Puerto Rico was founded in early 16th century by Spain. We have a very Latin ambience and culture.

Because of our relationship with the U.S., that's combined with a very high infrastructure. As we mentioned, there is something for everyone. It is perfect to come with the kids in June, with the family, with friends. We have the culture, the beaches, all of the things that you naturally identify within the Caribbean but, again, with a very unique combination of Caribbean feel, Spanish culture but with an American or a more North American standard of infrastructure and services.

Very important to know that the visas are not required for all EU passports. But these must be electronic in accordance with the new Homeland Security measures. And we speak both Spanish and English, are our official languages. Right now if you are coming into Puerto Rico with Euros in your pocket, well, that's a very good exchange rate and very interesting for you to plan.

As Pablo mentioned in the Web site, there is a very nice combination of hotels next -- or very near the venue hotel which is Caribe Hilton. Shortly we will be adding more moderate-priced hotels to this offer because we are aware that once the meeting is over, if some of you will be staying with us and paying it out of your own pocket and you want to bring your family, there has to be more options.

And, of course, because you will be meeting in San Juan in the capital city, we do suggest that you stay a few days and discover the other parts of Puerto Rico which are very mountainous and there is also a south coast which is based by Caribbean sea where we are going to be meeting. You are going to be meeting in the north coast which is the Atlantic.

And we do have a variety of lodgings that we will see shortly for you to combine and probably hire a car and drive around the island.

Top 13 must-see sites from Spanish forts to the only -- or the largest radio telescope in the world which is in Areciba without missing a very, very interesting thing that is rare to see in the world which are bioluminescent bays. We have five of these bioluminescent bays. We will see them shortly. You will discover why when you go to Puerto Rico you must see this natural spectacle.

Family, nature/adventure, SCUBA diving, golf, nice for a family get-together.

Our capital San Juan in the north. Voila. When some of you have taken a cruise in the Caribbean, if you have been to Puerto Rico, you probably entered through this beautiful bay and that's the El Morra Fort welcoming all of our visitors. The building below the city walls is where our tourism offices are headquartered. It was a former colonial jail called (inaudible). That's where my bosses are now.

[ Laughter ]

>> (inaudible).

>>MARIMAR LIDIN: That's where we also headquarter a very nice museum, which also is a place to visit and a place to pick up information. It is sort of the promenade -- where the promenade starts, all around the wall you will see that in the night when the lights come down, all of the fort lights up and it is a very, very romantic walk all the way up to the point of El Morra. Like in Lisboa, we have cobblestone streets. The stones were used by the Spanish ships in the colonization of Puerto Rico. They are beautifully colored like inside of a mussel shell and they glow in the night as well.

All of the San Juan old city will be five minutes away from your hotel venue because the Caribe Hotel is located at the entrance of the islet of old San Juan and this would be the other edge, cruise ships, the nightlife. It is a wonderful place to visit.

The shopping, a lot of people ask us what there is to buy. Typical in Puerto Rico, the masks. More recently people really go after the factory shopping because they are very good, well priced.

Other attractions, Condalo area also near the Caribe Hilton. North coast, golf, 23 championship golf courses in Puerto Rico, there you go, all over the island.

Rio Camry Cave Park is formed by the third largest underwater river in the world. It is perfectly prepared for families to visit. Voila. Here is the Arecibo Observatory we mentioned. A lot of you probably know it was featured in films such as "Contact" and "Golden Eye." It is located in the north coast of Puerto Rico because of the Karst Country there, it was an ideal place to place this and it's run by Cornell University and you can visit with the family.

Eastern Puerto Rico with our municipality islands.

Our rain forest, this is the only tropical rain forest within the U.S. Forest Service and it is less than an hour away from San Juan. Has a visitor center and all sorts of trails to go up and visit.

Beaches also. This is ten minutes away from San Juan. This is also in the northeast part of Puerto Rico, old Spanish lighthouses and in Fajardo, great for catamarans. A lot of you have asked us to hold special events in Puerto Rico and, of course, the catamarans are very popular. The (inaudible) islands are the only true virgin islands left in the Caribbean and they belong to Puerto Rico where tourism has not arrived massively at all. They are still very pristine.

(inaudible) is one of the biobays. The rest are in the mainland island. As you see, the water glows in the night when you move your body and you can just splash in the water and you will see how dinoflagellates which are tiny organisms which live in the bays. When they are disturbed, they just glow and it is amazing. It is spectacular.

Central and south Puerto Rico, from the San Juan to the south of Puerto Rico, the second city which is Ponce (phonetic) in the south, there is only a one hour and a half drive because of the good roads and toll highways we have on the island. Actually, it is the only island in all of the Caribbean that has toll highways. You can imagine it is very easy to move around.

Indian ceremonial parks, old coffee plantations and porta del Sol is the West Coast of Puerto Rico formed by 16 municipalities. It is where we have whale watching, one of the best beaches and SCUBA diving and it is very popular among surfers in addition to diving because it is where we have the Hawaiian style waves. We just had a very important international surfing championship there in Rincon, in the west of Puerto Rico.

Kayaking, this is really, really popular in Puerto Rico because we have a lot of mangroves. The mangroves are trees that form islands that in the night that's where we have most of our biobays and this kind of mangrove coast. But during the day, it is excellent for kayaking, snorkeling and just relaxing.

Spelunking very popular as well because of the Karst Country we have because of the limestone foundation giving a lot of caves.

Mesones are the typical restaurants that the Puerto Rico typical company supervises to provide typical food at very popular family prices and they are throughout the island. When you drive around the island, you will see it indicated in the road signs with that emblem, with that logo.

Also, in addition to our Paradores program, which are small country inns, it is a great way to be able to afford a full vacation in Puerto Rico and go beyond San Juan and discover all of Puerto Rico. Sunsets in the west.

And our host hotel, Caribe Hilton which you can also access through the ICANN Web site. The main gateways would be from Madrid with Iberia, Miami, those are the main gateways. Our Web site that you have already been visiting, thank you, and also our link to go to puertorico.com.

Just to mention, Puerto Rico in its objective to be able to attract investments to Puerto Rico, if you're there and your respective businesses might be interested, our page www.pridco.com can give you a very good why w Puerto Rico as a bridge between the Latin America, Europe and U.S. market is very interesting to invest, especially because of very, very good incentives. We're done. Any questions? Do you have any questions or do you need more brochures?

>>CHRIS DISSPAIN: Can we go now?

>>MARIMAR LIDIN: Let's pack up and go.

>>CHRIS DISSPAIN: Couple questions.

>> Not a question. What is the requirement --

(Speaker off microphone.)

>>DOTTY SPARKS de BLANC: It is a new change by the United States and that's why it is important

>>PABLO RODRIGUEZ: Visa information, it will give you specifically information Africa, Europe, Asia.

>>DOTTY SPARKS de BLANC: It is a new change for the United States.

>>MARIMAR LIDIN: It took effect a year ago. It was in October, any visit to any U.S. destination, electronic passports are compulsory.

>>PABLO RODRIGUEZ: It is important to highlight that in the first item where it says documentation, you may click there and you will provide that information. It will come to us as an e-mail and we will prepare the letter.

>> It means -- it is actually an American Visa we are getting and not a Puerto Rico Visa?

>>MARIMAR LIDIN: Yes, Puerto Rico is a U.S. territory. And any requirement -- and any requirement you need to enter the U.S. applies to Puerto Rico fully. Okay?

>>CHRIS DISSPAIN: Thank you very, very much indeed. Joel has a question.

>> (Speaker off microphone).

>>CHRIS DISSPAIN: You can't come. You are not allowed to come.

>>MARIMAR LIDIN: Where are you from?

>>JOEL DISINI: Philippines?

>>CHRIS DISSPAIN: Can we take this out?

>>MARIMAR LIDIN: Do you regularly require Visas to enter the U.S.?

>>JOEL DISANI: Yes, definitely. Do I need something special to get into Puerto Rico?

>>MARIMAR LIDIN: If you already have a visa, that's all you need. And you probably already have an electronic passport.

>> I don't have an electronic passport.

>> That's something that is required.

>>CHRIS DISSPAIN: No, it's not. No, an electronic passport is not required if you want to -- at least it is my understanding is that if you want to not have a visa, you need to have -- you can be European with an electronic passport.

>>MARIMAR LIDIN: You are very right.

>>CHRIS DISSPAIN: You are not required to have an electronic passport.

>>MARIMAR LIDIN: You are very right. If you are not a visa holder, you do have to have an electronic passport. Thank you for that.

>>CHRIS DISSPAIN: Thank you very much indeed. Thank you, everybody.

[ applause ]

Okay. We are going to move on. And we are going to go to reports now from our -- from the -- updates, rather, from the regional organizations. Michuki, would you like to start? We will start with the AfTLD. While Michuki is getting ready, I want to pat Bernie and myself on the back for supporting the Puerto Rico meeting. We should buy each other a drink later, Bernie, to celebrate that. And it is only 12 weeks away. It is only 12 weeks away.

Michuki, have you disappeared again? He has. Ah, there he is.

>>MICHUKI MWANGI: Good afternoon. My name is Michuki Mwangi. I am currently the president of AfTLD and I would like to take a moment just to give you a brief update on AfTLD, where we are coming from and where we have been in the last few years.

Now, the background on AfTLD is that it was registered in 2002 in Mauritius. Mauritius is one of the few countries in Africa that has very favorable company registrations policies and the initial members were dot mu, which is Ghana, and ke which is Kenya. The three served as the executive committee of AfTLD and basically initially what happened is that all the African countries co-opted as members of AfTLD. By then the main objective of AfTLD was to act as a focal point for all the African CC operators.

Now, in the backdrop of that, you'll realize that -- which has come up today in the various meetings, there are 54 African states and of this, there were inherent legacy issues that came around with delegation of the African ccTLD operators -- registries where a majority of them were delegated to people who were either active in those countries then but were not nationalities of those particular countries.

As time has moved on, it has brought up various concerns with particular countries. There was also an absence of knowledge sharing platform where people could actually exchange information with regards to DNS and ccTLDs.

Again, some of the other challenges that facing Africa is lack of scalable (inaudible) Internet infrastructure. Again, it is the background of not having the sufficient technical skills to operate the registries.

Something else that came up over time was also that there was a lack of general awareness about the importance of DNS domain names. Considering that the ccTLDs were latecomers, most of us from the African region are always faced with this myth that the ccTLDs are local while the dot com and the gTLDs are actually global. It is a myth we consistently have to try and create awareness that they actually are both the same and one is more patriarchic as another.

As a result, most of the ccTLDs within the region are significantly small and when I say small, I am looking at values of where most registries have less than 10,000 domain names, probably less than 5,000 domain names for that matter.

In that respect, for a certain period of time, AfTLD could not participate within activities within its region but as continued has come up as a result of activities within Africa, the ICANN meetings within Africa, the IGF, they have created sufficient momentum for interest to be generated especially around ccTLDs. So we were able to hold an IGN last year during the meetings in Marrakech. We were proud to say we were able to bring to the meeting 30 African ccTLDs. At this point we were able to elect new members to the ExCom. We have eight new members to the Excom.

As a result of that, it has triggered renewed impetus into the organization. At this point, I would like to say we've seen improved participation of AfTLD, especially the African ccTLD operators at ICANN meetings, the IGF African meetings, AfriNIC, the meetings that are organized in Africa, three or four times in a year.

Currently, we are undergoing -- we are trying to focus on a few activity issues to try and revamp the organization. And one of the things we focused on is to review the amendment of the Constitution and amend it so it is suitable to our members and we are also looking at fund-raising. As I mentioned earlier, most of the ccTLD operators are small, actually probably over 9 0% are below 10,000. It is difficult to get them as contributing members to support their impressions of AfTLD. So we are looking at a place to start where we can make the organization more sustainable through activities.

We are also looking at focusing on communications, creating communication and INS with our members. In that, we are looking at participation in strategic events. We are looking at engaging our members more often and reaching them directly.

One of the interesting things to note about Africa is the varied ways in which ccTLDs operate. We have from ccTLDs that are operated by Universities, individuals, some by the national telecos and others by non-profit organization, multistakeholder partnerships. Because of this varied environment, we feel we need to engage each one in their own respects so that we can actually be able to, you know, mobilize them to join the AfTLD.

We also are revising our mailing list and updating the Web site which has been down -- inactive for quite a while. But in the last six months, has been highly updated.

We are also looking at opportunities to see how we can improve on our capacity building within the region. Issues of IPv6, registry management tools, DNSsec, all those issues which are currently on the forefront at the ccTLD global arena and we want our members to have a feel of exactly what it entails.

Also, issues of -- regarding ccTLD establishment and best practices for those who actually undergoing delegation or have just undergone redelegation.

Most importantly in May we are looking to host capacity building workshop in chiro with support of the Egyptian government to meet the cost of hosting the event.

In addition to that, we are looking at having -- entering into agreements or memorandum of understandings with strategy organizations. For instance, in Africa, we have AfriNIC and AfNOG which is the equivalent of NANOG for those who come from the North American region. And it is a capacity technical training group. So we will use that as a platform where we can get members trained on Internet structure and services.

We're also looking at having our next AGM on the 30th of April in Abuja, Nigeria, and we're also inviting actually members of the ccNSO who will be -- a large group of the African community will be in ABUJA for that particular week of events, so if you happen to be in the neighborhood or interested to come, you are more than welcome.

Lastly, we're also looking at hiring a full-time administrator. One of the things we realized is that trying to get activities moving on within a particular -- within such a large organization covering such, you know, a region was seemingly strenuous for the members, because they're volunteering their time. Some of us represent more than just one organization in our respective countries or from the areas we come -- the regions we come from, so we felt that it was important for us to have a full-time administrator who will be in a position to articulate and also oversee the day-to-day operations of afTLD and avoid going under, as had happened in the past.

So in conclusion, what we are looking at is looking for areas of collaboration with other regional TLD associations and, for instance, we've been involved in the past with membership, observership and we'd like to continue with that. We'll also look at how we can share statistical information. We've seen quite a number of that being done at CENTR, and so we're looking at similar areas where we can collaborate with these associations.

And we'll also welcome support and views from the other CC communities at-large. I believe this is pretty much a very new field for us, and for those who have been in it for a while who are looking at input on how to make it better and avoid all the learning curve that most of you have had to go through.

And our last request is actually to the ccNSO, and the ccNSO council. It is to actually give due consideration to the afTLD Ex Com position with regards to the ICANN regions that we've already submitted.

>>CHRIS DISSPAIN: Have you?

>>MICHUKI MWANGI: Yes.

>>CHRIS DISSPAIN: So you've written to us to ask us to appoint someone from afTLD as a liaison to the council? Is that what you're talking about?

>>MICHUKI MWANGI: No. This is in regard to the ICANN regions ongoing discussion, so we've already given a position --

>>CHRIS DISSPAIN: Oh, I understand. I'm sorry. Yes, yes, yes, understood.

>>MICHUKI MWANGI: All right.

>>CHRIS DISSPAIN: Understood. Okay.

>>MICHUKI MWANGI: And then that's the end of my presentation.

>>CHRIS DISSPAIN: Any questions?

>>MICHUKI MWANGI: And I'm open to questions.

>>CHRIS DISSPAIN: Thank you, MICHUKI. Thank you very much. Don, would you like to come and Asia-Pacific?

Do you need to see it.

>>DON HOLLANDER: That would be helpful. Thanks very much, Chris and thanks to everybody here for the opportunity to give an update on APTLD, very quickly. Just a little bit about Asia-Pacific.

It covers all the ccTLDs in the Pacific, all those in Asia, all those in the Middle East and the bits in between. APTLD's cultural diversity is huge. The language diversity is huge. And the geography is huge. Taking a bit over a day to go from one end to the other.

That's our board. Some of those faces should be --

[Laughter]

>>DON HOLLANDER: -- a bit familiar.

>>CHRIS DISSPAIN: That's seriously scary.

[Laughter]

>>DON HOLLANDER: Shariya has just been elected our chair based our Malaysia. This is what we'll be doing this year. We'll have four meetings. One we had in Bali last month in conjunction with APRICOT. We'll have another meeting in Dubai in the beginning of June, a meeting in Honiara which is in the Solomon Islands, look for the Pacific and look for a little bit of dust on the map and that could very well be Honiara. And in association with the ICANN meeting at the end of the year, wherever that may be.

We're also running three training programs. One is a nontechnical training day, so this is really for admin sort of people, for new board members, new management, staff. We ran that in Bali. As Chris said earlier today, we videotaped that, and that will be on our Web site hopefully by the end of this week. If not then, early next month. And we're going to run the same program in Dubai just after our meeting at the beginning of June. So if anybody has board members who would like to -- you'd like to get them on the straight and narrow for ccTLD issues, you're welcome to send them to Dubai.

We also have an introductory technical training session in Bangkok in May, and an advanced program in October of this year also in Bangkok.

So if you've got new engineers or new technical people, please feel free to bring them along in May or send them along in May to Bangkok. It's a lovely place. It's not overly expensive. And then for the more advanced people, come in October this year.

We'll do two research projects. Here's a list of some of the topics that have come up. Elasticity of demand for domains, so we have a number of members who are interested in dropping their price. Some of them a little bit nervous as to what that's going to do to their revenue; others quite convinced that dropping their price will increase their revenue and their profit, so we thought we'd do some studies on that.

We had a paper presented at our meeting in Bali on resiliency and redundancy, how much is enough, a guideline for operators, and we'll turn that into a paper, a pamphlet.

The question: Is there a correlation between the size of a ccTLD, number of domains, and its degree of openness. Looking at customer satisfaction surveys, building on the work that CENTR is doing or any other things that our members are looking to do.

Our values, core values, we're very open, sharing, caring organization. All our meetings are open to anybody who wants to come. And we have them in various places from one end of the -- of the region to the other. So our principal focuses at our meetings are what's happening locally, so we ask our hosts to give us an update on what's happening not just in their ccTLD, but also in terms of ICT in the country that we're visiting. Many of the countries in the Asia-Pacific area are developing and addressing some real challenges.

We try to have a commercial administrative focus. Not quite as blatantly as how can we make some more money, but pretty close. We have a technical issue. We talk about global policies. And we're consistently talking about IDNs. So the meeting we're having in Dubai at the beginning of June has nearly a full day devoted to IDNs. We're going to take the questions that the ccNSO is coming up with and try to work through some answers, try to get some positions from an Asia-Pacific perspective, and Asia -- the Asia-Pacific area certainly has quite a diversity of character sets left to right, right to left, up and down, sideways, inside out, whatever.

So our next meeting in Dubai, June 2nd and 3rd; the nontechnical training the 4th and 5th. As I said, focusing on IDNs, looking at new opportunities for ccTLDs, looking at the role that ccTLDs have in their local and regional ICT development. So very much what we just heard, that -- that AFR TLD is doing. We'll looking at ccTLD promotion, does it work, what have people tried, what's been successful, what hasn't been successful. We'll look at getting IPv6 in the zone and new trends in registrants, domain tasters, drop and catch and all these other new words, so please consider coming and joining us. And for more information, have a look at our Web site or send me an e-mail. So happy to answer any questions.

>>CHRIS DISSPAIN: Thank you, Don. Anyone have any questions for Don about the APTLD?

Okay. Well done. Peter? There you go. so now CENTR's turn.

>>PETER VAN ROSTE: Good afternoon, everyone. Thanks so much, Chris, for providing us with this time slot. I think it's quite significant that the -- the regional organizations are -- we're observers and are now becoming more active, but still observing, of course. So I really appreciate that. Within CENTR, it's also seen as a very positive thing, that there is much more cooperation with ccNSO and during the ICANN meetings in general.

So I'll take you through CENTR in a -- what I hope to be a short-and-sweet presentation. The history of CENTR, I'm going to skip. You can read all about that on the Web site. What is probably quite relevant to know is we -- we underwent a significant organizational change last year. We are now a Belgian company, and we also moved our office in Brussels, which by the way, reminds me that anyone who is in Brussels can always give us a ring. We would be more than happy to host you there.

So organizationally, we have three new members in the last four months. It's dot EU, dot IM, which is the isle of MANN and dot cat, Catalonia, and a really significant addition, I think, because it's -- it illustrates quite well the diversity of the CENTR membership. Small to large and larger and largest, but also with dot cat we get an interesting perspective to our business.

In total, we have now 52 members. They're spread more or less across the globe, that is basically for historical reasons. We do encourage enormously their participation in their local regional organizations. And that brings me to the point that was already mentioned by the previous speakers. That is, that the interaction between those regional organizations is taking off as well.

A news flash on a brand new initiative which was steered by Don is we now have our own mailing list on which we can exchange best practices on how we can treat you even better as VIP customers.

The last general assembly in Prague also saw the election of a new chairman, so Andrzej Bartosiewicz from NASK is now the center chairman following up on Paul King and we have two new board members, Sabine Dolderer and Alberto Perez Gomez. The CENTR secretariat is now three people. There is Wim Degezelle. Some of you -- or I would hope quite a few of you know very well from his daily news flashes. There is Annalise, who is running our Brussels office, and there is myself.

For -- instead of sending out a postcard for the new year, we provided our members with a world map on which we very -- in a very subtle way indicated the CENTR membership. So if any of you would like to have a copy of that map, I think Wim brought some of them with him. Wim, can you maybe just stand up so that people can at least identify? There's Wim. So if you need copies of this map, feel free to contact him.

>>CHRIS DISSPAIN: I got mine in Australian colored in a different color --

[Speaker is off microphone] so those are all CENTR members, right, the red?

>>PETER VAN ROSTE: Right.

>>CHRIS DISSPAIN: Cool!

>>PETER VAN ROSTE: So now to the core of our activities, actually. What are the issues and the projects that we're currently working on. Again, for detailed information on any of these, feel free to contact me or Wim during this meeting or afterwards. The issue we discussed in our Prague general assembly -- well, there were two. One was alternative dispute resolution, and the other one was critical infrastructure. Some of you may know the -- The European Commission has currently a legislative process that is looking at critical infrastructure, but in a very broad sense, and we have been discussing the impact on our industry. The second issue is a natural one, I think, IDN.IDN. CENTR members have expressed their interest to be included in the initial phases, in the initial lists. CENTR is accommodating that and CENTR is an observer into their bilateral discussions with ICANN. We had a very interesting project that the customer satisfaction survey, which was also mentioned by don, it turned out that a dozen of our members were running surveys with their customers, so generally they're registrars, sometimes, and customers. To find out how happy those customers were with the service that they were given.

CENTR started a project in which we drafted one survey, so one list of questions, that can be used by all the members, so that now they can compare their results with their neighbors or somebody they think they are comparable with. And figure out what the quick fixes are. Anybody interested in that list -- in that list of questions for their own use can, of course, get them from me or from Wim.

Two surveys that are currently occupying people's minds are protecting personal names and best practice sharing on that, and disaster recovery plan which actually fits in quite nice with the critical infrastructure debate. An issue that will be on the agenda for the next weeks, I guess, since the recent news on that, is DNSsec, of course.

So much more at our Web site, which will be updated and reviewed in the months to come. Our next meeting is an admin workshop and a general assembly in Helsinki. The theme there will be marketing and new services. As always, anybody who is interested, just drop us a line and we'll make sure you get a proper invitation. And you have my contact details, so if there is anything else we can help you with, just let us know. Thanks so much.

>>CHRIS DISSPAIN: Thank you very much, Peter. Anybody got any questions? Any questions for Peter? Thank you.

And finally, on this particular regional report, it's Margarita. I saved the best till MARGARITA.

>>MARGARITA VALDES CORTES: Okay. Hello, everybody. I will present here many ideas and things that are happening currently with LACTLD community, and the question of the day is who are we and where are we going?

In the beginning, LACTLD as a community started by the shared will of the ccTLD managers that wanted to share experiences and be connected to work together and coordinate efforts to similar interests.

This is a very historical document because it's an e-mail that Oscar Robles sent to our colleagues in 1997 giving the first step to configure the community of LACTLD.

LACTLD starts a formalization process. The first step was an MOU. With a LACTLD meeting in Montevideo in September 2001 we signed an MOU as the first step in the formalization process of the organization.

The second step was bylaws approvals. In March -- at the end of March of 2004, in Montevideo, Uruguay, in the LACTLD meeting, the text of the bylaws were approved and signed. In that meeting, we included 13 ccTLDs and two observers.

The next step was the legalization procedure and international not-for-profit NGO in Uruguay. In March 28th, 2006, the legalization process was complete.

At the LACTLD meeting in May 2006 in Guatemala city its first board was elected as a formal organization.

The board of LACTLD is formed by myself -- I'm the president. That's the reason I am the top of the list.

[Laughter]

>>MARGARITA VALDES CORTES: It's just because of that.

[Laughter]

>>MARGARITA VALDES CORTES: And after me, there is Demi Getschko, from dot BR, Eduardo Santoyo from PE, Francisco Arias from MX and Rafael Ibarra from SV. Yes, Patricio is saying hello. Currently, we are 21. We have 21 members.

The objectives of LACTLD is to be a not-for-profit organization with aims to group together the ccTLD managers in Latin American and Caribbean region with the following goals: To coordinate joint policies as well as strategies to develop the domain names at the regional level; to represent member interests in the proper forums; to promote the development of the ccTLDs in the region; to foster cooperation and sharing of experience among their members regarding ccTLD issues; to establish collaboration links with similar organizations in the world; and to work towards the goals that the members decide.

How to participate in LACTLD? We have two kind of participations. The membership. Any ccTLD from Latin America and Caribbean can be member of LACTLD if they present an application to the board and as long as it adheres to its principles.

The other way is observers. Other organizations that the assembly agrees to accept can participate as observers by previous request. They can participate in the assembly and have only voice. To be a member, it is required: (a) be a ccTLD entity from Latin America and Caribbean with legal personality according to the respective country law; (b), request participation by formal letter to the board. This is a letter have to be signed by the legal representative of the entity that manage the ccTLD.

Each member have to be represented by a person designated for this effects or for default, it is understanding that will be represented by the person who is listed like admin contact in the IANA database or equivalent.

Who is this community? What kind of organizations are inside of LACTLD?

65% of the ccTLDs in the region are a department or a division inside another organization -- bigger -- for nonprofit kind of organizations and care its financial sustainability.

Between 1987 and 2000, IANA and ICANN delegated the country codes in the region and the majority of them started functions between 1990 and 1992.

All LACTLD members have been participating in ICANN and most of them are part of the ccNSO currently. Inside the ccNSO, later than and Caribbean region have three representatives in the council and have -- and the Vice Chair is from the region, too, which is Poblete Patricio. LACTLD in the international context. LACTLD participates in ICANN directly or by the ccNSO as a recognized regional organization.

This is a community who have more participants in the ccNSO. We are 15 ccTLDs.

With regard to ICANN, the accountability frameworks currently are 19. And from the region in the case of LACTLD, we are -- we have six AFs, which is the 31.6% of.

Where are we going? We are evaluating the implementation of IDN in the region. We have just one ccTLD that is running IDN currently.

We -- we improved the participation in other forums like OEA-CITEL, which is the organization inside the ASO, which is in charge of telecommunications matters in the region. So sometimes this is a governmental part of participation and LACTLD in my case, I have to -- the opportunity to participate there because the Chilean government invite me to participate there, and at the same time I -- I am wearing two hats NIC Chile and LACTLD hat.

Our participation in IGF, Internet governance forum, I personally participate in the PrepCom meetings and IGF forum by the group of the ccTLDs, and we participate in ICANN and the ccNSO, and we are now working on the strategic plan from Sao Paulo. We started in Sao Paulo. We expect to finish in the next meeting. We have a dinner assembly in Isla Margarita Venezuela in May this year. Everybody is invited if you want to go.

[Laughter]

>>MARGARITA VALDES CORTES: We are improving our collaboration in secondary DNS services between members, and promoting the installation of mirrors of the root servers F in the region. We have three and we are -- soon we will have two more. This is a joint -- joint venture with IC -- the ESS and ISC. And project is based LACNIC, which is called [Spanish word] and that's the opportunity that the ccTLDs in the region have mirrors of root F.

We promote the research and financial support for specific projects to improve registries in the region, trying to improve relationship with the relevant authorities in each country with the ccTLD, and reinforce the relationship and participation in other brother organizations like APTLD AfriNIC and so on. And that's it. Thank you, gracias, obrigada

>>CHRIS DISSPAIN: Thank you, Margarita. Anybody have any questions? How is Patricio.

>>MARGARITA VALDES CORTES: She's fine.

>>CHRIS DISSPAIN: Shall we just check?

>>MARGARITA VALDES CORTES: Yes, yes, yes.

>>CHRIS DISSPAIN: Okay. Thank you very much, Margarita.

>>MARGARITA VALDES CORTES: Thank you.

>>CHRIS DISSPAIN: Okay. So now we're going to move on to ICANN global partnerships report and that's -- and Giovanni is doing that, I believe. It's just you -- oh, it's a team. You're representing the team. In the room, yeah.

>>GIOVANNI SEPPIA: I hope so. Okay. Thank you, Chris, for the invitation to speak about the regional liaison team, a sort of update after one year since the last presentation in Wellington. It's a sort of first anniversary. The European Union has just celebrated the 50th anniversary. We're now celebrating the first anniversary. It's a long way to go, but let's see.

>>CHRIS DISSPAIN: We've got more done.

>>GIOVANNI SEPPIA: We got more done. Somebody says so. But the team has grown. We are now 7 members. Don't get scared. This is the last picture of the team. There are both regional liaisons here, and Teresa, who is vice president and global partnership general manager, Mandy Carver, who is the deputy manager with Teresa, and the rest of the team.

So we are now seven regional liaisons covering from Africa to Uzbekistan. We all have different background expertise in different areas, so there's Anne-Rachel for Africa, Save Vocea for Australasia, Pacific Islands. Canada and Caribbean are covering by Jacob Malthouse. I'm covering Europe and there is Pablo Hinojosa for Latin America, Baher Esmat for Middle East, and then there is this quite long list of countries [Saying Names], which are covered by Veni Markovski who is the last one that joined our team.

We have -- I don't know if Chris is counting the countries or whatever --

[Laughter]

>>GIOVANNI SEPPIA: -- we have developed recently our second year of work business plan. Our business plans are -- or at least try to be consistent with the ICANN strategic and operating plan, and as we did last year, we are planning to do a midterm review due the end of June this year to make our business plan consistent with the latest developments and with the needs that might have emerged from the region.

What we have done so far is mainly to strengthen communications with the different stakeholders at the regional level. Stakeholders including government, ccTLDs, gTLDs, registrars and users, so international organizations.

And we have done so by supporting the organization or participating in local events. I'm going to speak about what I did for the European region and then my colleagues who are in the audience are going to do the same for their region.

My region regarding events last year was quite busy for the Internet Governance and we helped to organize a sort of capacity-building event in Latvia at the beginning of October. And still in the theme of organizing an event, we did organize the first ccTLD workshop event for the Balkan ccTLD and we done that in cooperation with ISO. We also involved CENTR. We are following up with the ccTLDs to make them more involved, at least in the international scenario of Internet.

We have received feedback from various stakeholders communities and tried to convey them to ICANN at different levels. We also acted as original contact for ICANN and that we have done only with end users also with different authorities, local regional authorities which were looking for information regarding ICANN or regarding, for instance, registry model like registry, registrar, registrant model. Personally, I received some requests from some police authorities which were sent to me from the ICANN main address to help them with some issues regarding registrars, gTLD registrars mainly.

Also, we have supported multilingual consultations on different topics. Last year multilingual consultations on the ICANN strategic and operating plan were conducted in Marrakech meeting and Wellington meeting and Sao Paulo meeting in Spanish, French and Arabic. And those consultations have led to some inputs that have been incorporated in the latest version of the ICANN strategic and operating plans.

Our work has been try to be close to the community. The advantage is to be close to them because mainly we are in the same time zone. We speak the same language, or at least we think we speak the same language, sometimes it is quite difficult even if we are in the region but we try to do our best to meet the local community needs.

And now I would like to invite my colleagues. I can see Save and Baher who can speak about what they have done in their specific regions. I don't see Ann-Rachel and Demi who are the other two regional liaisons present at this meeting. But so far Save and Baher, please.

>>SAVE VOCEA: My name is Save Vocea. I'm a new ICANN -- I am new to the global partnership, new employee to ICANN since October last year. I am originally from Pacific Islands so it was an opportunity to kind of promote ICANN activities back to the Pacific colonies. As you can see, in ICANN events, it is mostly like no Pacific colony participation.

The region I am covering is Australia and New Zealand and the 25 other Pacific colony ccTLDs. So for the moment, it's been presenting about ICANN activities and why Pacific colonies are participating in ICANN and contribute to some of the policy discussions that's probably going to impact them at the ccTLD level as well.

>>BAHER ESMAT: Thank you. My name is Baher. I am the liaison with the Middle East. I have been with ICANN for almost 20 years now, 13 months. So, again, it is my anniversary with ICANN. So basically as Giovanni said, we are trying to work close to our communities. We more or less speak the same language, understand the culture. The issues are various -- we are talking to governments. We are talking to ccTLDs, to private sector, to user groups, trying to explain the ICANN process and this is not an easy job in some parts of this world.

So basically what I have been focusing on during the past year is to try to get the community of the Middle East to participate more in the ICANN process with organized workshops last year. One was an agenda workshop about ICANN and its function, and we also had another ccTLD workshop that were mainly focusing on ccTLD business.

So that's basically what we are doing in ICANN. And we will be happy to answer any questions if you have any. Thank you.

>>CHRIS DISSPAIN: Thanks. Thank you, Giovanni. Just from my perspective, I'm the one who gets -- originally gets the membership applications when they come through the system. And I have noticed there has been a significant increase since some of you have been out there doing some work.

While we don't necessarily approve them all, because nine times out of ten, we have the most obscure application form, no one can understand, sometimes we have to go back and get it redone. Nonetheless, we are seeing some results purely from a membership point of view. Thank you very much, indeed.

Any questions for the gentlemen? Okay. Don, sorry.

>>DON HOLLANDER: Coverage for the rest of Asia? Time frame?

>>GIOVANNI SEPPIA: There are two more regional liaisons that are planned to join our team possibly by the end of the year. One was already in place but for budget restrictions, it will not take place before the end of June. We will have two new additions by the end of the year. One, I know that more or less they have already selected a person. The other one is on its way.

>>CHRIS DISSPAIN: That's going to cover what particular -- how does that work?

>>GIOVANNI SEPPIA: I understand one is for the Malaysia area and there is also another one covering India. And then we have to cover another part of Asia because the plan is to add three more. But by the end of this year, there will be two more.

>>CHRIS DISSPAIN: Okay. Thank you. Peter, you had a question?

>>PETER van ROSTE: Chris, I basically want to echo the comments that you made. I think they are doing incredibly good work and I particularly want to highlight the meeting that Giovanni organized for the Balkan region which was a perfect event. I think it has dramatically increased the exchange of information between registries from that region.

I heard there is another one coming up in Moscow, and we are looking forward to that and are willing to support it as much as we can. Thanks.

>>CHRIS DISSPAIN: Thank you. Don't be too nice. Thanks.

Thanks, guys.

Okay. We are going to wrap up for the day. I just have one more item which I would like to show you all. You know that we have been struggling for a while to sort of the Web site out and I posted to the list the other day that we were working on it.

It is not complete yet, but -- there you go. This is the draft of it. It has some -- it is set out in a much more easy way to follow. It will have information on members, councillors -- members, there is already a list. Councillors, we've not prepared to tell you who we are yet so that's not up there.

Minutes, and so on. We are slowly putting all the pages up onto this new ccNSO Web pages and probably within a few weeks -- a couple weeks, it will be completed.

At that point, we will be saying, please, will you go play and please tell us what's missing and what would be useful. I mean, just having a look here, while it is fantastic that there is a list of members, I can't do anything with the list. I can't regionalize -- it will happen. In order for me to find out we have now reached 57 members, I had to count how many were physically on this page.

That's great that's happening and Gabby, I know, would really appreciate once it is out there our feedback so we can make it more useful.

Tomorrow morning we start at 9:15 with a session on accountability and transparency. And then we have ccTLD updates from various ccTLDs. And then at 11:00, we move into our IDN session 2 which is basically going to be the talking between in our community about dot IDN without worrying too much about what the GAC thinks.

And I'm hopeful at that session which is set to take a while will actually mean that we can start openly discussing what we really feel about the questions that are being raised in the draft issues paper.

Unless there is any other business, I will call the meeting to a close and we will reconvene in this room at 9:15 tomorrow morning. Thank you, everybody, for your attention.