ICANN | Transcript - ccNSO Members Meeting, 27 March 2007, ICANN Meeting, Lisbon Portugal

ICANN Meetings in Lisbon Portugal

Transcript - ccNSO Members Meeting

27 March 2007

Note: Although transcript output is largely accurate, in some cases it is incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.

>>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

Internet Corporation for Assigned Names and Numbers