ccNSO. June 24, 2008. Paris, France. >>CHRIS DISSPAIN: We're going to start in a couple of minutes. Sorry, folks, for the delay. Good morning, everybody. Good morning, everybody. >>MULTIPLE VOICES: Good morning! >>CHRIS DISSPAIN: Thank you very much. [Laughter] >>CHRIS DISSPAIN: Sorry about the room. It's going to be a really tight squeeze. Especially tomorrow, I suspect. But I'm afraid we just have to live with it. It is, believe it or not, the third largest room. [Speaker is off microphone] >>CHRIS DISSPAIN: Yeah, but -- yeah. Go on then. [Speaker is off microphone] >>CHRIS DISSPAIN: Yes, that's right. It's the third largest room and of course the main room is the main room and those pesky GAC people get the second largest room, so... But I think the conclusion is rapidly being reached by practically everybody involved in organizing these meetings that the days of hotels, of having them in hotels are over, it's got to be a convention center and it's got to be a proper convention center, because otherwise we're just going to run out of space. So the first item on the agenda this morning is awareness of ICANN issues, which is something that the -- something that the council, after their planning session in Delhi, decided was a sensible thing to have on the agenda. However, having said that, we've all been rather busy running around doing IDNs so absolutely no preparation whatsoever has been done for a session on ICANN issues. Is there any other issue apart from IDNs, as far as anyone else knows? A couple of things happened -- I don't know how many of you were actually in the gTLD workshop yesterday, the afternoon session, but a couple of things came up in that which I thought were -- which I thought were quite interesting and are obviously issues running hot in the gTLD world. The brand owners and the trademark lawyers that were there were basically saying, "Please don't register any more gTLDs, because all that happens is we have to register our names in them as defensive registrations." And even the -- even the -- I think quite innovative thought of saying, "Well, why doesn't eBay register dot eBay and then spend a year and a half or two years' of its marketing dollars educating people that if it's not dot eBay, it's not eBay?" And that was apparently not a sensible idea, so that's running. And I also think that the GNSO -- I went to the GNSO Council meeting the other day, and sorted out two points with them. At least I think I did. One of which was that they're very, very, very, very, very concerned that an IDN ccTLD might -- for example, might end up in the root before an IDN gTLD. Because then we'd be first to market, and that's apparently not a good thing either. Did anyone go to the JPA? Discussion of the JPA yesterday? Did you go, Roelof? And Hartmut? What did you think? Did you -- how did you -- would you -- hello? >>ROELOF MEIJER: Well, I'm sure I wasn't the only one, but it was not much of a discussion. Sorry? >>CHRIS DISSPAIN: [Speaker is off microphone] >>ROELOF MEIJER: It was not much of a discussion yet, I don't think. I don't know if a lot of people have seen the documents. I have to confess that I haven't seen all of them yet. There was -- there were a couple of themes, and one was capture and doing something about the board of ICANN in case they go berserk, is maybe the best term. >>CHRIS DISSPAIN: [Speaker is off microphone] >>ROELOF MEIJER: No, no. No, I wasn't implying that. So but I mean it was more of a presentation, and a few of the -- the most known speakers reacting and there wasn't really a discussion like we had in the session that you were chairing. So I do hope that that will still come, because otherwise I think a lot of things will just pass. >>CHRIS DISSPAIN: Okay. >>ROELOF MEIJER: They -- well, I -- at least I was surprised that they made such an extensive session out of it, for the first time. >>CHRIS DISSPAIN: Thank you, Roelof. Thanks, Roelof. Anybody else who wanted to add anything? Just -- I know we all know who we all are but just for the sake of the scribes, it would be nice if you could say your name. >>MATHIEU WEILL: My name is Mathieu Weill. I'm AFNIC's chief executive, manager of dot fr. Yeah, the JPA session was basically a presentation of the three documents of the President's Strategy Committee that have been on line for less than a week now, so nobody apparently had really gone through them very deeply and it was just an exchange of -- preliminary exchange of views, and there's a public consultation going on on these documents until end of July, I think. But they're also announcing a second round of public consultations in October, so you would have a second chance. And basically the issues are capture, accountability, how to challenge a decision by the board, and even fire the board if a number of constituencies do not agree. Some issues about -- and the current position is, the headquarters of ICANN will remain in the U.S. forever, and there might be new places where ICANN would establish legal offices as well. So this is the type of things we've been hearing about since Delhi. There's nothing very, very new in the documents, but it's summing up a number of initiatives that have been around for a few months and I'd encourage everyone to have a look at it. >>CHRIS DISSPAIN: Thanks, Mathieu. That's great. Did anyone -- anyone go to the IPV -- no, sorry, to the SSAC, open SSAC meeting? Security and stability advisory meeting? No one. Didn't I say you in there, André? I did see you in there, didn't I. Aha! [Laughter] >>CHRIS DISSPAIN: Did anything happen? No? >>ONDREJ FILIP: No. >>CHRIS DISSPAIN: Okay. Don't worry. As long as you say that, there's nothing to say. Okay. Well, I guess now is there anybody -- is there any particular ICANN issue, anything that anyone else wants to actually mention before we move on to the start of the formal agenda? Anything that's come up in the last couple of days that anybody wants to mention at all? No. Okay. Cool. Dotty does. Hold on, Dotty. Hold on. >>DOTTY PARKS de BLANC: I just wondered how people -- this is Dotty Sparks de Blanc. I just wondered how people feel about two meetings a year instead of three. >>CHRIS DISSPAIN: Exceptionally good question. Anybody -- anybody want to say what they think about two meetings instead of three? Everyone's still asleep this morning, right? >>PETER VAN ROSTE: This is Peter Van Roste from CENTR. We think this is a very good idea. We've been discussing it internally within CENTR as well. In that case, we would need to reduce our number of meetings, too. And I think the conference call, Chris, that you now monthly set up and it's at the moment only aimed at the council members but could definitely be broadened in scope would probably be the main tool to compensate and even make it much more efficient, the way that we work. So I'm definitely in favor. >>CHRIS DISSPAIN: So let me get this right. You're saying that -- what's this doing here? You're doing that if we were to have a monthly conference call, obviously ccTLD conference call, that was open to -- I mean, they're open to anyone anyway, but was open to anyone to attend, then we -- you think we could manage with only two meetings? What do other people think. When we discussed this last time, there was a general feeling that two meetings a year was a very good requested idea, but perhaps not just yet, because we felt that -- we felt that what might happen with two meetings a year was that nothing would happen in between the two meetings. But if -- if Peter's idea of having a monthly call is -- I mean, I don't know whether that would work. It might do. It works for the council simply because we have -- >>PETER VAN ROSTE: [Speaker is off microphone] >>CHRIS DISSPAIN: Yeah. But I mean I think if you were just having a call and people turn up, I wonder if people would actually turn up. Yes, Dotty. >>DOTTY PARKS de BLANC: I think that the calls were very effective because they were very agenda-specific with printed information in advance of the discussion. I don't think we should just have a general chitchat once a month without a focus because -- >>CHRIS DISSPAIN: Sure. Understood. >>DOTTY PARKS de BLANC: -- that is a waste of money, too. >>CHRIS DISSPAIN: Yeah. Annebeth. >>ANNEBETH LANG: Good morning, everybody. Annebeth Lang here, dot NO. I have some experience from the conference calls from the GAC, and actually I agree with what Dotty says, because in these meetings, just a few people attended, and just a few people contributed because it's even more difficult when you're a non-English speaker to be active in a conference call than to be active in a meeting face-to-face. >>CHRIS DISSPAIN: Yeah. >>ANNEBETH LANG: So at least we have to take that into consideration. >>CHRIS DISSPAIN: Thanks, Annebeth. Calvin, you had... >>CALVIN BROWNE: Calvin Browne. Yes, we do run the risk of alienating people who find it more difficult to partake. If there's more meetings, they're more likely to come to one of those meetings and partake, whereas if there's less meetings, we're more likely to alienate them. >>CHRIS DISSPAIN: Sorry, Calvin. Anyone else? >>DANNY AERTS: My name is Danny Aerts from dot SE. I think it's a very good idea. I think we should have to -- we have to learn how to meet and talk with the chatter without this flying circus all around the world. Everybody is talking about the climate but nobody is willing to do something to change their habits. >>HILDE THUNEM: Hilde Thunem from the Norwegian registry. This actually touches on some of what came out of the participation survey when we asked people how to better participate in the ccNSO, and there were comments saying that, "Well, can't you at least highlight who -- what is going to be the main meeting so we can prioritize to go there because we can't go to every meeting." If there's fewer meetings, it might be easier to actually get people to come to those meetings. >>CHRIS DISSPAIN: Yeah. >>HILDE THUNEM: But we do have a main challenge in how to keep working in between meetings, because I think anyone who has been the chair or a participant in a working group in the ccNSO knows that when you leave this place, people -- they don't die, although it seems like it, but they go back to their daily work and it's very, very hard to keep the focus and actually get people to do something to move the process forward. >>CHRIS DISSPAIN: Sure. I the -- that's a good point, and I also -- and so was your point. The challenge for us is going to be that we've structured ourselves in a way that a lot of things that we -- a lot of things that we do are done in a members' conversation in members' meetings, and then there will be working groups set up to do specific things and then report back to everybody, and obviously working groups can easily meet on the telephone and the council can meet on the telephone, but this is really hard to do any other way but this. And the only question I have is whether -- is whether -- if that was only twice a year, that would be okay, and the other question, of course, is if it was only twice a year, would it need to be for a longer time twice a year. I mean, it probably wouldn't but it's just, it's just... Any other comments on just that before we move on. Olivier? >>OLIVIER GUILLARD: Yeah. Olivier Guillard, dot fr. First, I want to endorse and echo what Hilde just said with regard to participation in working group and having people participating because they have their day-to-day work and so it's very difficult to ask them to commit to participate efficiently in process, and that's normal. We had a lunch yesterday with the ALAC, and there were also discussions with regard to the participation through teleconference call or through writing, and there were different views on the right process for people participating adequately in the processes, and this is also something which is to be considered. Some people have said that having regular conference call was helping the process to work together. Others said that considering the time difference between people, it's something difficult for some of them to participate appropriately in the teleconference calls, and said that right processes for having people aware in time of issues and working by writing was a better solution. >>CHRIS DISSPAIN: Okay. Thanks, Olivier. Keith? Keith Drazek. >>KEITH DRAZEK: Right here. Thank you. So Keith Drazek with dot us. My comment is, I think that the concept of two meetings a year versus three meetings a year is worthy of consideration. If, for no other reason, that ICANN's travel budget for the proposed 2009 year is over $8 million, which is for travel and meetings, and it's not just for the ICANN meetings but that's an increase of more than $2 million over the previous year. So -- >>CHRIS DISSPAIN: It's the price of oil, Keith. >>KEITH DRAZEK: Sorry. >>CHRIS DISSPAIN: It's the price of oil. >>KEITH DRAZEK: Exactly. So -- no. So I guess my point is that there needs to be a balance between the reasonable cost of -- the cost of ICANN's meetings and the need for doing two or three a year. >>CHRIS DISSPAIN: Okay. >>KEITH DRAZEK: So in terms of ICANN's costs, I think it's worthy of reviewing whether two is better than three, and possibly maybe two is better in one year and three the next. It -- I think there's, you know, the possibility. >>CHRIS DISSPAIN: Then we'd have to argue about whether it was even years and odd years and... [Laughter] >>CHRIS DISSPAIN: Get all confused. >>KEITH DRAZEK: Good point. I'll take that off the table. [Laughter] >>CHRIS DISSPAIN: Okay. I think just -- just one other point. Paul Levins said that he would come and talk to this particular document if we had time, and I don't think we do, but if we make some time up, then I'll get him to come. But the only other point I would make is: Okay, so let's say we move to two meetings. No problem. Regional meetings? Do people -- I know there's been a regional meeting in Dubai, there's been a regional meeting in Taiwan. Regional meetings? Good idea? If they can be organized? Don? >>DON HOLLANDER: Thanks. Chris. Don Hollander from APTLD. Two issues around regional meetings. The regional organizations already have meetings. >>CHRIS DISSPAIN: Yeah. >>DON HOLLANDER: So if you're a ccTLD active in the community, currently you have three ICANN meetings. CENTR, I think, has three general assemblies, APTLD has three general assemblies. APTLD is planning to go to two meetings each year with an optional opportunity for regional meetings in wherever we don't have a main meeting. >>CHRIS DISSPAIN: Subregional meetings. >>DON HOLLANDER: Subregional meetings, that's right. [Laughter] >>DON HOLLANDER: So it's really a question of the purpose of the meetings. The ccNSO is really looking at global issues, we think so there are already regional meetings. And my take, just on the ICANN -- the two recent ICANN regional meetings, those seemed to have been focused very much on outreach into the community, into participants who aren't already actively engaged in the ICANN community. >>CHRIS DISSPAIN: Sure. Absolutely. I think they were specifically focused at a particular time, and in fact, they were done in cooperation with APTLD as I -- effectively. I mean, as I recall, but yeah. Okay. Dotty. Sorry. >>DOTTY PARKS de BLANC: Will somebody please invite North America to some of its exotic regional meetings because we don't have enough people to have a meeting. >>CHRIS DISSPAIN: Oh, come O you've got Guam. You can go to Guam. >>DOTTY PARKS de BLANC: They're not a member. >>CHRIS DISSPAIN: Doesn't stop you having a meeting there. >>DOTTY PARKS de BLANC: Yes, it does. [Laughter] >>CHRIS DISSPAIN: All right. We're going to wrap this one up and we're going to go into the participation survey unless there's any other burning issue. Okay. Hilde, the floor is yours. Oh, sorry. Yes. Gabby. >>GABRIELLA SCHITTEK: I'm just going to hand out the participation list, so please fill this out. >>CHRIS DISSPAIN: Yes, please fill out the participation list. It's the only way, apart from my appalling memory, that we can remember who is in the room for the meeting. Sorry. Hilde. >>HILDE THUNEM: I'm Hilde Thunem from the Norwegian -- >>CHRIS DISSPAIN: Can you turn this mic on, please? Okay. >>HILDE THUNEM: Okay? Yeah. Also known as the exciting to-be-continued item on the agenda, I would actually like to ask you how many of you are at the ccNSO meeting for the first time in your life? [Show of hands] >>HILDE THUNEM: Ah! Good! Welcome! Since you are here for the first time in your life, and since there may be people here who don't avidly follow every meeting -- although I know that's unlikely -- I thought I'd start with a recap on what the hell is the participation working group. Because that is a group that was set down to look into the issue of participation in the ccNSO and in the regional organizations. So it was set down to research and report on what is the current level of participation in the ccNSO, what is the current level of participation in the regional organization, are there barriers that stop people from coming, is there opportunities where the ccNSO can serve the community better, can we communicate what's in it for the people who show up better, and what's in it for the people who show up at the regional organizations, are there possibilities of better relationships between the regional organizations and the ccNSO, and then somebody actually said we had to do stuff! So how do we implement all these good ideas? We formed a fairly large working group, which is open for everyone, so if anyone else wants to join, you are very welcome. We would like you to work, but you're very welcome to be there. We immediately set up three task forces: A research and reporting task force, a communication task force, and a relationship task force. We haven't really gotten around to the implementation task force yet. It will come. And this is actually a report from the research and reporting task force that has tried to find out a few things. Because we wanted to learn what is the current level of the participation in the ccNSO. Why do you come to these meetings? How can we better serve you? And the entire ccTLD community. Are there barriers? What are they? And are there things that can be done differently to make it easier for you to come? We sent out a survey. And it was sent out by the ccNSO Secretariat, to the ccNSO members list, to the ccTLD discuss list. We sent it to the regional organizations and asked them to pass it on to their members, and we used ICANN's regional offices in order to try to reach other ccTLDs. Basically, we are now going to summarize what we learned from the survey. There are a set of areas. First, it's interesting to look at who actually responded to the survey. Who are the people we managed to get answers from. And keep that in mind when integrating the answers. Then there's what they said about the value of the ccNSO meetings, what barriers they identified, how they suggested we could do something about the barriers, and what further improvements they suggested. Now, in English, I have learned, there is an expression that goes, "There is lies and then there's damned lies and then there's statistics." [Laughter] >>HILDE THUNEM: This actually is just meant to show that you can use statistics to prove anything. If you want something specific, you just piddle a bit with the numbers, and then there you have your result. So in order to not do that, to not sort of do this nice, fancy showing of results that aren't there, I have tried to avoid fancy graphs and lots of percentages, and tried to show you more the number of answers we actually got. Now, this means that there are tables instead of these fancy graphs in the presentation, so it makes for a more boring presentation. I'm sorry for that, but that's what you get. So who were the respondents? Who did we want to reach? Well, we wanted to reach everyone. Every ccTLD. But the reality is that we were trying to reach two very different groups. One of them actively participate in the meetings, and we wanted to know what they found valuable, so we could keep doing it. And we wanted their suggestions for improvements. But then we also wanted to reach those who don't usually attend the meetings, who might not even know what the ccNSO is, and ask them, "Okay, if you don't -- if you know who we are but you don't attend for some reason, what should we do different? And if you don't know who we are, would you tell us about that, so we know that we should try to give you more information." Of course the main challenge was then to reach those people, because they're not here. So who actually responded? And here's the dreaded tables. As you can see, we had 56 answers out of roughly 243 ccTLDs. That number changes a bit when new ccTLDs appear or stuff, so -- but we got roughly 1 out of every 4 ccTLD who answered the survey. And my friends in statistics tells me that this is what you usually get when you just mail out a survey and you're not big and can go into their office and say, "You are going to answer this survey or I will not leave!" [Laughter] >>HILDE THUNEM: So 23% is pretty normal. If we look at how many ccNSO members that answered the survey, 47 -- almost half of the membership -- answered the survey. They were very active, and this might be because -- well, they know what the ccNSO is. We actually had their address so we, you know, could reach them. And they probably know why the survey is being sent out and have an interest in making the ccNSO a better place. But we need to keep in mind that the people who answered the survey is mostly people who are members. A larger degree of members than of the sort of average ccTLD. You can also see from the regional answers that comparing between regions gets very dodgy. When you have one answer from North America, which actually is 25% of the ccNSO membership is in that one answer, and you got 10 answers from the African regions, which is a measly 16% of the membership in that region, so trying to sort of look at regional variations there gets very -- well, into the field of black magic. I haven't really done that, so unless there's very, very, very clear regional tendencies, they will not be mentioned in the summary or in the final report. You can look at the tables and you can make your own thoughts about what the strange numbers means, but that's it. So as I said, how many were ccNSO members. There were 36 of the 56 that were members, 20 nonmembers. So that needs to be kept in mind. Then we also asked: How often do you go to the meetings? And here's a percentage graph, instead of a table. I'm very proud of that. As you can see, there's almost as much saying never been to a meeting that says that, okay, we've been to a few meetings, and then there's almost -- semi-regularly 23%, almost every meeting 36%. So basically what we see is that 59% of those who responded to the survey goes very often to these meetings. And if we count participant lists and look at how many of those who participate go to three or more meetings of the last four meetings, that's 35%, so it's lower. Which, again, shows that the people who answered this survey are very active. It's a larger degree of the very, very active people that have answered. Not very surprising. So if we then look at who -- what's the characteristics of the respondents, well, they are ccNSO members or active in the meetings or both. EU and LAC region seems to have had particularly active ccNSO members, because over 70% of their members answered the survey. But basically, what we can see is that the survey reached the first group, those who go to the meetings and we could get information from them on what they like and what they want us to keep doing. Not so much the second group, those who aren't really here. Not surprising, but we had hoped to get more. Still the 40% that is less active in the meetings might give an indication on what we lack. So going on to what did they value of the ccNSO meetings? Well, there are very many that feel that the meetings are of value. 44% say, yes, they are valuable. Before we pat ourselves on the back and say the majority think they are valuable, we have to remember the people answering this survey are the people that come. Obviously, they find something of value. And we see that very clearly if we take this question and look at that sorted on how often do you show up at the meeting. So those that say yes, all the "almost every meeting" people say yes, these are valuable; not very surprising. Semiregular people usually say yes, they are valuable meetings, et cetera. What is interesting is to see that in the "don't know" category, they don't know whether the meeting is valuable or not. There is someone that goes there semiregularly, which is more than having been to just three meetings, and they still don't know whether these meetings are of value to them. Maybe we as a community should be a bit more clear on what you get and what we can do for you. And that's where the communication group has come in and sort of made a small brochure saying, well, what is the ccNSO? What can you get from being here? And what is the regional organizations? Gabby has them in English and in French so people who want to pick up, especially those for those of you who have been here for the first time and think this is very cryptic, please do so. And we asked them, okay, what do you find of value? Most the two bigger results is informal talks with other people from the registries, networking, and exchanging information through presentations. Much more popular than surveys. So I'm really glad all of you answered the survey still. Then we go on to barriers of participation, what can be a barrier that stops people from coming? And the major ones are cost of travel and we don't have the time or the personal resources. One thing is paying for the journey. The other is when you are a small registry having people being at this meeting instead of being at home working for two days, three days, an entire week, which is a serious drain on the registry. Then there is information, lack of information is a barrier. Language is a barrier. I know I've tried suggesting that we could have these meetings entirely in Norwegian, but Chris denied me and I think that's bad, but still... There's limits on the working groups -- on certain working groups. And there's the legal structure of the ccNSO and other barriers, and we asked a bit more of the legal structures and barriers to sort of get an idea. And the response we got was that in the legal structure, there's a need for clarification of the ccNSO scope as felt by some ccTLD. And some ccTLDs respond that the ccNSO is for those with accountability framework and others are just tolerated. Now, this is the answers from the people that have answered the surveys. These are their perceptions. They might not be true or we might not agree with them, but perception is reality and we need to look into it if we actually want people to feel more at home here. Also, on the other barriers, people point out that travel costs is not the only issue of travel. Some people have to go through very many steps of the journey to get to a meeting. They might have to get to a meeting by visa to get to the destination. But they might also have to get a visa to get to wherever they change flights and that can get very, very difficult for certain countries. The issues are complex; they're fast-paced. There are too many meetings. We've already discussed this before this presentation. Some say that it is a barrier that the ccNSO is totally irrelevant. I don't think we necessarily can do all that much with that, but it is a valid viewpoint. And, of course, the registry is just a small part for a lot of us who have other duties, if we are connected to the university or other things. It might be that just 50% of the time is spent on the registry and the rest is spent on another job. Then we also asked, are you a ccNSO member? And if no, can you tell us why? And this is a result. There's a lot that haven't decided yet of those who answered. But do remember that the 20 people who responded to this are 20 of the roughly 166 non-members out there, so we can't sort of call this very, very representative, but it is still interesting information. Many of those who respond are still thinking about it. Now, this might be why they bothered to answer the survey because they are thinking about membership. One concern is what the ccNSO can offer. Does it have a value for them? And one concern is the legal structure of the ccNSO. So these might be things we want to look into. Then breaking the barriers. This is not the working groups' suggestion on how to better this. This is what the people in the survey came back with as steps. They said that, well, we have limited resources. We have limited time and staff to send to the meetings. So in order -- it would probably be nice if the ccNSO could hire lots more people for us, but they probably can't. So then in order to be better able to participate in the meetings, we need to know what's going on so we can prioritize. We need to know what's going on beforehand. We need easily accessible information so when we show up and people start talking about this cryptic thing, we can be able to participate. And if we haven't been to every ccNSO meeting, we need information on what's going on in the meantime so that we can pick up the thread. Of course, some will say that, well, they're still talking about what they did three years ago so I didn't have to go to the intervening meetings. But that's another issue. So 16 ccTLDs say we would like more information and then they have concrete suggestions on how to improve that information like, for example, explain to new members what is going on, inform about the agenda beforehand and what is going to be discussed, put up documents on the Web site as soon as possible so that people can know in realtime what's going on. Help people arrange their travels, and do more presentations from different ccTLD so you get more information in the meeting. Travel costs. Lots of ccTLD suggested that financial assistance would help and two explicitly said that the fellowship program had been of help for them. Others said, well, try to make sure that this doesn't collide with our regional meeting or whatever so that we have a chance to show up. And then one said, well, if more people keep coming, it is easier for us to defend why we're going and why this is a good investment. Then there's the other issues like language, legal structure, limits on the working group, et cetera, and there were some concrete suggestions for translations, starting the process to clarify the scope, open up working groups for all interested ccTLDs, remove regional groups within the ccNSO or allow self-selection. Send direct invitations to the different managers. Then there's the improvements, how can we better serve the ccTLD community. And the main theme was, okay, try to focus on the core mission and cooperate with others, especially the regional organizations in what they are doing so there's no duplication. Try to assist newcomers in getting involved. It is not that easy. Maybe it easier to participate without traveling. Assist information sharing and assist in influencing ICANN. So of the core mission, there was the avoid duplication part and make sure the ccNSO issues are raised at the regional organization meetings so we have a two-way flow of information. Please when you -- because you need to consult with the local communities and not do as an organization something that the local community doesn't want, you need to make the proposals easy for understand for non-English speakers. And you can try combining meetings with other regional groups to conduct outreach. Then there is the assist newcomers getting involved, like having a list of who's going to be there so it is easier to connect with people. Start by explaining the meeting, what is going to happen in this meeting and what's going to happen outside this room that might be relevant for you, like Chris tried to do in the beginning of the meeting. Have Webcasts but also have a chat channel so you can send questions back so you don't have to be at the meeting in order to participate in our thrilling discussions. The information sharing, having a mentor program which is something we're already actually trying. Help with sharing information about registry management software, et cetera, et cetera. You can read and the presentation will also be on the Web so I won't go through every part in detail. But in meeting improvements, there are some specific points that might be interesting, like try to facilitate networking by not setting people up like in a church, listening to the gospel like we're in at the moment. Everybody can go "hallelujah" or whatever is appropriate for their religion. But instead trying to have small discussion groups perhaps sometimes like with the IDN issue ones. A discussion on procedures and try to work more on exchange of best practices, more on actual information on how to be a big or small registry. And then assist in influencing ICANN. For example, possibly, as one said, a project on developing joint ccTLD positions regarding relationship with national governments, if we are ever able to agree on that and communicate them to the GAC. Try to improve participation and policy development process, do away with the regional groups. Someone suggested even do away with the GAC, but I think possibly a bit optimistic. And then we come to the part of the meeting where I would like input from you. Now you've seen a summary of what the survey results were. Having seen that, are there comments you want to make? Do you have suggestions on how to improve participation in the ccNSO? Because then Gabby will be taking them down so that the working group can work with them later. Yes, I'm asking a question to you in the room. >>CHRIS DISSPAIN: Okay, is there anyone out there? Dotty? >>DOTTY SPARKS de BLANC: Hello, hello? Okay. I feel that instead of the ICANN core meeting having to go to the regionals to make sure they don't overstep the subjects, that the regionals should make sure they don't overstep the subjects of the main ICANN meeting. >>CHRIS DISSPAIN: Patricio. You know that's your job the rest of the day now? [ Laughter ] >>PATRICIO POBLETE: Just once, then it is somebody else's job. If you could go back to your slide about barriers to becoming a member of the ccNSO, I don't remember if those were the options offered or if those were the things that people wrote. >>HILDE THUNEM: Those were, if I remember right, the options offered in an e-mail form so you could write whatever you liked. You didn't have to sort of cross off. >>PATRICIO POBLETE: In talking to people in our regions who are not members, I have discovered another reason, and that is that once this organization exists and enough people have joined to keep it existing, there doesn't seem to be a good reason for other people to join. So I would add another reason like it is unnecessary to join because you can get almost all the benefits without having to become a member. >>HILDE THUNEM: Yep. >>CHRIS DISSPAIN: Anyone else? Martin? Your first-ever comment at a ccNSO meeting, as a cc person. >> MARTIN BOYLE: Thank you. Yes, Martin Boyle from dot uk and formerly a member of the GAC. So I hope it wasn't dot uk that commented that perhaps the abolition of GAC would be a good thing. [ Laughter ] I would actually like to turn that one on its head and say that participation is actually also a very big problem for the GAC. Getting outreach and getting other governments involved, we have similarly in that community the same sort of issues, the same sort of difficulties in explaining and understanding. And, yet, both sides, I think, have got quite a lot of shared interest in improving their understanding of the system and, in particular, for the GAC understanding the cc community, I think, is particularly important. So I wonder whether -- and certainly for this meeting, I think it is unfortunate that we are not meeting the GAC on more general issues. But I wonder whether we should be going to the GAC, presenting a brand-new leaflet to help explain what we are about and seeking to work with them in trying to get that wider outreach. >>CHRIS DISSPAIN: That's a very good point. We are -- the GAC liaison-ccNSO liaison thingy is in the process of being reconstituted since someone left. So it is your fault, basically. But, yes, I think that is a very, very good idea. >>HILDE THUNEM: Olivier? >>OLIVIER GUILLARD: Olivier Guillard, dot fr. Thank you very much for this report. I'm impressed by the work behind and we are coming back to the participation issue in working groups. That's just a huge work. I heard, I think, two meetings ago that there were -- the question is now what's next for the working group? >>HILDE THUNEM: Next slides. I will do that after. >>OLIVIER GUILLARD: You still have some slides so I don't want to steal, okay. The two questions I had is, what's next? Because it sounds like a report already. I'm not sure you need to -- I don't know what you want to do, but if you want to write a report, I think this is already one. And the second one was what we as ccNSO are going to do with it. >>DOTTY SPARKS de BLANC: Thanks. To me one of the biggest problems with outreach to any level is a lack of education about ICANN and what it does. I mean, if people ask me what I do, if I start in the most elementary way to explain, their eyes start to glaze over and I'm sure that everybody else experiences the fact that the man on the street has no idea about this. And I heard scuttlebutt that ICANN is going to set up a lobbying office in Washington, D.C. Well, before they set up a lobbying office, we need a big educational thrust, massive, so that even first-graders can understand what this is all about because if you start a lobbying office and start talking to people about ICANN, their eyes are going to glaze over, too, and you are going to get nowhere. I really think it is a matter of education and we have made ourselves into such an elitist with regard to nobody else being able to understand it at all group that we really need to come down to earth and educate everybody in plain talk about what this is all about. >>HILDE THUNEM: Well, that's definitely a point. One of the reasons why I feel very happy when I come to these meetings is I meet other people and I say, "DNS" and they say "Yes, we work with it." >>CHRIS DISSPAIN: It is a clothing store. >>HILDE THUNEM: I remember the incredible relief the first time I went to a CENTR meeting and I said, "I work with a registry. Yes, mm-hmm." We are in a very special community and usually there is just one of us inside the country. Well, not one person but one organization. This is one of the places where we can meet and share things. I do agree we have a major issue in actually telling everybody else about what we do, except that it has to do with the Internet. I would like to be -- to ask people -- and you are very much allowed to say no by sitting still. I say no by wearing it on my T-shirt. I would like to ask the people that are here for the first time and probably are feeling really confused now, is there anything we could do to make it easier for you? Is there anything you would like to mention to us that we as a working group can take back and think about how to make it easier for you to actually come here a second time? And if you don't want to answer, that's okay. I mean, it's scary the first meeting. >>CHRIS DISSPAIN: Who is here for the first time? Would you please put your hands up if you are here for the first time. [ Laughter ] Thank you. Someone -- that's Byron from Canada. Thank you very much. I know there's more than two of you in the room. Martin, well done. Dot uk is here for the first time. >> [SPEAKER OFF MICROPHONE] >>CHRIS DISSPAIN: Yes, I did. So the part of the problem is the survey goes to the e-mail addresses that we have but that doesn't mean the person that turns up in the room ignored the survey or returned the survey. That's quite challenging. What would be really great is the people who are here for the first time would at some point in the next two days find Hilde, just look for the "no" sign and actually have a chat with her about participation and how you got here, why you're here and what would make it easier for you. Is that okay for the time? Excellent. >>HILDE THUNEM: Then the very last slide, as Olivier said, what happens now? We made a very nice survey, but that's just the beginning. Well, one thing is the research and reporting task force who will actually make a report -- and it's halfway finished -- that will be published on the ccNSO Web site. And that will contain all the suggestions from the different participants instead of just my short summary of suggestions. And then the participation working group, which is open for everyone, and we would like more people to come there and work, will take the input and actually try to develop some proposals for actions. Some of these we will just try, like the mentor program, without really doing a big fuss about it. And other things we might come back with to the meeting is, "We think this is a good suggestion, what do you think about it?" And then we actually have to do something. The implementation part of it comes in and see if these things are useful. Is this brochure going to be of help? Is the mentor program where somebody experienced tries to help somebody new getting through the meeting and surviving actually helping? And other things we come up with. So that's what's going to happen forward. Any more questions? Patricio? >>PATRICIO POBLETE: Since we hold our meetings within the context of the ICANN meeting, we depend on ICANN for many things. And I wonder if this group has gotten in touch, with ICANN, with people in charge of public participation to see how they can better help us or what we can contribute. For instance, there is no video coverage for this meeting. What do we think about it? Were we aware that was going to happen? I hear that this text is being streamed in realtime, which I find a good thing, but I wasn't aware that that was going to happen either. That's something that I would like to look to consider. >>CHRIS DISSPAIN: Patricio, just on that specific point, actually Kieren McCarthy did yesterday -- at the opening session, Kieren did say about the text being streamed and mentioned about the Webcasting. My understanding of the Webcasting is that -- basically, they've come to the conclusion it is incredibly expensive. It chews up a massive amount of bandwidth and their figures are there are actually very few people who are watching it at the other end. But I agree with you about the communication side of it. That was just to tell you the -- what I think has happened. Sorry. >>HILDE THUNEM: That's okay. Any more questions? Okay. >>CHRIS DISSPAIN: Can I say something? Can I ask everybody -- there has been a huge amount of work done to get to this point on participation. And Lesley and Hilde and Oscar and the various other people on the working group have put in a huge effort. So can we thank them in the usual way, please. [ applause ] Okay. Well, with this impeccable sense of timing, Dr. Twomey has just walked into the back of the room. Would you like to come to the front of the room? Oh, and he's gone again. There will just be a slight hiatus because members of the board have been dispatched to the wrong room. They're currently wondering where we are, I suspect. >>CHRIS DISSPAIN: While -- >>PAUL TWOMEY: Here we go. >>CHRIS DISSPAIN: Ah! Sir! Wrong room, right? Okay. Ladies and gentlemen, we're going to start our next session, which is an update from Peter and Paul. And there's at least one board member -- two board member -- three board members. Fantastic! -- in the room. Which one of you is going to start? Peter, are you going to start? >>PETER DENGATE THRUSH: We're negotiating. >>CHRIS DISSPAIN: Oh, you're negotiating. A couple hours' time... >>PAUL TWOMEY: I believe I'm starting. Well, listen, thanks very much. I'm very pleased to be here. I'm sure Peter is. Probably Peter has more reasons to be pleased to be here. It's always good to -- the room seems to get more full each time we have a meeting. So it's good to see as many people participating as there are. And I can see some people who, even in the last week, specifically told me that they'd make the effort to come here, so -- from the Pacific, so I'm -- good to see those people participating. So we've got a very busy week this week, as you all have seen. And you'd be surprised to know that the issue of new generic top-level domains seems to be getting some attention at this meeting, and a lot of attention from the media, at least yesterday and today. Just -- perhaps I might just talk through some of those specific things coming up in front of the -- potentially for the board, new generic top-level domains is clearly one. We'll be very interested to hear about your progress and discussion on the issue of internationalized domain names, particularly as they apply to country codes, because that is something that we have tentatively scheduled for the board to discuss on Thursday. The issues of add-grace periods in the GNSO space, in the gTLD space, is also a topic that's coming up in consideration. There's a proposal from the GNSO on that. The operating plan and budget is part of that as well. So that's sort of some of the, I suppose, key areas. Perhaps to come to the new gTLDs process, and I know many of you have got an interest in that, the policy was developed, as you know, over a long period -- two and a half years or so -- and the board asked -- was concerned to ensure that the policy, which in some respects is detailed and some other respects is a product of a consensus and therefore has various issues not addressed in the policy. The board was concerned that the policy be implementable before it made a decision about adopting the policy. Now, that's unusual in ICANN procedures, in that normally in ICANN, policy is approved by the board and then the staff are asked to go away and implement the policy. In this circumstance, the board asked management to go away and really try to work through the procedures around that. We have been doing a lot of that work, and this meeting is the first chance in some detail to go through the issues and potential implementation steps around new gTLD implementation, so the question before the board, which I don't think the board has come to a conclusion yet but which will come to the board on Thursday is essentially: Do you have sufficient confidence in what you have seen in the processes of implementation for you to have confidence that you can move forward approving the policy? It will not be a question of approving the implementation. The implementation procedures are being put forward now for consultation with the community. We expect at least another two months of discussion around those implementation issues. They will then be written up into a request for proposal and an accompanying draft contract. And so they are the two documents that actually take the implementation process and put them into writing context, and then they will be available for comment and then board approval. So if you've got an interest in this arena, for whatever motivation, we are looking forward to your feedback on the process for implementation. I would make the following observation about implementation. There are a couple of outstanding issues that we're still needing to get expert advice on. We're still finalizing advice on implementation of the objection headings. We're in discussion with very -- a number of international arbitration organizations of good reputation, but we're still working through with them potentially how we -- how some of the objection arbitration processes could work, and that is an ongoing discussion, so we expect to see more detail of that here. And some of these entities have not given us permission to release their names yet, as we're still in this discussion period, so we're not in a position to say arbitration path A will be conducted by arbitration provider B. But we hope we will be in that case in some weeks. The other one is that we have a company CRA International. You guys from North America, it used to be called Charles River Associates. It is an international firm of economists, who do economic analysis for us, and one of the tasks in front of them at the moment, they have been helping us think through issues of pricing of the application fee, and I can tell you on that point we are being very, very careful to show a bottom-up process for both the costing of how this has worked and then according to the policy, how to then set a fee that ensures that the applicants -- that the application, whole application procedure, is a cost-recovery procedure. Which is what was in the policy from the GNSO. But the other thing that they've been working with us on and have not yet completed is an economic analysis of the benefits to the consumers of a two-part marketplace, and the consequences of shifting, if we were shift at all from structural separation between registries and registrars. And this is an issue because in the -- that we need to do analysis on because we have -- at the beginning, when ICANN was formed, quite clearly the idea of registries and registrars, that's expressed in certain legal language. In some contracts, that language is available for interpretation from either side as to its consequences, though we have undertaken that we would, with the registrars -- major registrars, we've undertaken that we would get this economic analysis done. That's not yet completed and we -- you know, that also will come out in the next several weeks for comment and implications. What does that fundamentally mean? It comes down to: Can registrars own registries, and can they own registries that they themselves sell? That's -- to summarize it down. They're the two key questions. And so we're waiting for that response. So that's sort of an introduction, I think, perhaps to the new gTLD process. >>CHRIS DISSPAIN: Can I ask a question? >>PAUL TWOMEY: Sure. >>CHRIS DISSPAIN: If I can get my mic on. Can I get my mic on, please? Thank you. Sorry. On the -- after having run the new gTLD workshop thing yesterday afternoon, Paul, have you thought about -- let's assume that the brand owners who were fairly forceful yesterday afternoon there, so let's take eBay as an example. eBay applies to register dot eBay, right? And it decides to use that for all of its addresses. How are you going to get paid? Given that they won't be actually issuing domain names, other than effectively -- well, they won't be issuing domain names at all, probably. Only intern ones. Have you thought about how, from a brand owner's point of view, if they're going to buy them, if they're going to get them, how you would get paid on an ongoing basis. >>PAUL TWOMEY: Yeah. No, we haven't -- well, we've thought about it. We haven't come up with a proposal yet. And the other thing which is related to that is, if I am a second -- if I am a single user TLD, like the sort of dot trademark and I want to use it for my e-mail addressing -- >>CHRIS DISSPAIN: Yeah. >>PAUL TWOMEY: -- we presently require a compulsory use of -- nondiscriminatory use of all registrars. >>CHRIS DISSPAIN: Registrars. >>PAUL TWOMEY: Is that going to be applicable? And if not, then how do you stop gaming? The other thing which is clearly also in discussion is if you are a very small registry and you're a small registry targeting, in particular, a niche segment, does the present requirement actually produce a reverse market power problem of the big registrars controlling -- having influence over who's -- what strings get put up when and how difficult is it for me to sell into the marketplace? So these are some of the questions we've asked people and we're still looking at. >>CHRIS DISSPAIN: Okay. Thanks. >>PAUL TWOMEY: One of the things I didn't mention in that list I went through before was the topic that Peter is going to talk to. >>PETER DENGATE THRUSH: Okay. Well, good morning, everybody. It's a pleasure to be back. I see many new faces, so perhaps I need to reintroduce myself. I was the dot nz manager in this room for many years. I'm one of your two appointments to the board and I am -- I appreciate the confidence shown to me recently by reappointing me for a second term to the board. I don't sit on the board as your representative in any sense. That's not the way the system works. But I do remain on some of your lists so that I can keep in touch with the ccTLD community, and I can tell from that, as well as from the large turn-out this morning, that the ccNSO has an extraordinarily good heart. I see a lot of activity and really good work being done and perhaps the flagship of that at the moment is the leadership that you're showing in relation to IDNs and particularly cc IDNs, so things look -- are going well. Having said that, I would remind you that I have asked before for attention at some stage in your policy development process to: What should we do when a country, for which there is a ccTLD, changes its name or goes out of existence? At the moment, you know, the IANA staff are working on a policy which seems to be a good one but it hasn't been produced by a bottom-up process through the ccNSO. By all means, decide that you are not going to do that and you are happy with the existing policy but at the moment, it seems that there's a little bit of a vacuum that you could usefully look at. Let me about two of the things that are occupying us at the moment, in addition to the one that Paul mentioned. One of the major ones from -- of significance to ICANN is the reform process in the GNSO. You may not know much about that, but that's the other support organization that deals with gTLD policy. There's a huge amount of work generated. It's probably the major policy shop that we have in ICANN, and it's certainly the source of a large amount of the revenue. And much of what's being proposed in a way of restructuring that body and its work has been accepted relatively noncontentiously. And I won't go into that. What we're left with facing us at the moment is a huge amount of dissent and Paul and I have just come from a two-hour breakfast session with a portion of the dissenters about that proposal in relation to the restructuring of the council and the changing of their votes. That is -- that is occupying us. That raises a number of very challenging issues of economics and competition law and representative democracy and working structures, and it's not going to be easy. People have taken, for very good reasons, diametrically opposed positions on these issues and I'm not sure the board is going to be able to resolve that this week. The other one that we're putting a lot of time and energy into, of course, is the change in relation to one of our agreements with the United States Department of Commerce. One of the most important documents in the founding of ICANN, after perhaps its bylaws were settled, was the agreement in 1998 with the Department of Commerce that said if we build an ICANN and it looks like this -- and there's a description where the "this" goes -- then the U.S. Department of Commerce will transition management of the root to ICANN. So that was the original bargain. That's why we came -- why we dragged ourselves across the world to places like Berlin and Santiago and Cairo and Stockholm and Accra, was to build the thing that a we wanted, so that we could take control of the management of the root. And the importance of that early document and its succeeding documents -- the first one was intended to last for two years, which was really, looking back, kind of hopelessly naive of us, but we had the best of intentions and we all worked hard, and it's now ten years old. That agreement is the one that said the ICANN that we will transition management of the root to needs to have these features, and it listed the things that -- there had to be a CC -- had to be an arrangement with the ccTLD managers and at the time there wasn't. Looking around the room now, we can probably say we've passed that point. There had to be a stable agreement with the root zone operators. There had to be all these different conditions for ICANN to exist. Over the years, that shopping list of requirements has been gradually reduced, as we've met the targets and we've gone from just having a single board to having all of the different elements of ICANN in place, and stable relationships and operating procedures and income and those things. So a couple of years ago, we changed the term of it from a memorandum of understanding with a list of things that we had to do to a statement of responsibilities that the board wanted to carry on, and they're all the sort of thing that we expect to carry on into the future. Now, that agreement finishes, as a matter of contract, next September, and so we're going through a process of saying, "Well, what should follow it?" And the position that the board has taken is that we don't think we need to follow it with any further agreement of that sort, and in March -- in January, February, March of this year, a process that was built into that document which was the midterm review of it resulted in the U.S. Department of Commerce, with us holding hearings and taking submissions and saying, "Well, what do we think of that?" And the President's Strategy Committee has taken the output from that and has prepared a set of documents that said, "Here's what we think we need to do after the -- to get to the stage where the Joint Project Agreement terminates and here's what we think we should do afterwards." So there was a well-attended session on that yesterday. Many of you, I know, were there. There's three documents that have been produced: A transition plan, a document called "Improving Institutional Confidence" and then a facts sheet that sets out what the obvious questions are. So I won't go any more on about that, because many of you were at the session, but please contribute to that process, either as individual ccTLD managers or as the ccNSO. So there's just perhaps a snapshot too of the issues, Chris, that the board's going to be dealing with this week. >>PAUL TWOMEY: Other things that were -- kind of the mechanics, one is this proposal for the add-grace period. It's a proposal that's coming up from the GNSO, and it is to -- that there be a limitation on how many changes to registration, if you like, or deletions of original registration a registrar can actually process in a particular month. I think the threshold is 10%. Or a set number. And it's specifically a response to the sense that there's been a lot of use of the add-grace period to, you know, test out marketplaces and that's gone too far. The number that is there, which is about the 10% number, is to allow the sorts of changes that the policy originally called for, which was the ability to reverse a registration if, for instance, there had been an error made by the registrant, if there was a bad-debt problem with a credit card, a number of these sorts of issues. So that's up for decision as well. I think that, plus the operational plan which you were going to talk about, I think, with Doug tomorrow, so I won't talk to that. >>CHRIS DISSPAIN: Okay. That's the -- >>PAUL TWOMEY: That's it. >>PETER DENGATE THRUSH: Well, there's a helluva lot more on the board's plate than that, but the question is how far would you like us to go. >>CHRIS DISSPAIN: Well, can I ask -- I've got a couple -- well, I've got a couple questions I'd like to ask, but are there any questions from the floor, first of all? I have Dotty. I have Young Eum. I have Dave. I have Roelof. But let's do it in that order. >>DOTTY PARKS de BLANC: Can you elaborate on the rationale for setting up, in Washington, D.C. -- >>CHRIS DISSPAIN: Office? >>DOTTY PARKS de BLANC: The lobbying office. >>PAUL TWOMEY: Sure. It's a -- actually a decision which was incorporated in last year's operational -- this is just in the operational plan, so the funding was actually part of this year's, as well as the following year. There's a two-part process. We already have something like five staff based around Washington, D.C. Many of them are policy staff. It's a product of simply recruitment, and where people have come from. That's five-four. The other issues, one of the purposes of which we need to be in that part of the world is just better service for registrars and registries on the east coast of the United States, so we actually have a lot of the registries and a lot of the big registrars -- or not just -- not just the big ones -- are all in the east coast of the United States. Many of them are in Virginia or near Virginia. And frankly, one of the things, as the CEO, I have been concerned about is: How do we ensure that we're in contact with those people more regularly? And being based in California, and of course remember why we're based in California. We're based in California because that's where Jon Postel was. I mean the reason we're in the building in Marina del Rey is because it was originally Jon's office. Okay? So there's no business rationale as to why most of the ICANN staff are based -- you know, clinging to the Pacific coast of the United States, and so there is a business rationale for us to have at least some people closer to a lot of the registries and registrars. We also have made a decision that it would be useful for us and our community to -- as we look at this transition period and beyond the transition period, that we also maintain a more regular interaction with the various parts of the Washington political process, including, you know, business associations but not -- also obviously the Department of Commerce and the Congress and other things. So that's -- we're also shifting a resource specifically there to manage that process. So that's the -- that's the rationale. It is not some statement of -- I'll remind you we have an office in Brussels. We've had an office in Brussels for several years longer than we've had an office in Washington, and it's not some attempt to put up a large stars and stripes statement. It's a simple business decision. >>CHRIS DISSPAIN: Young Eum. >>YOUNG EUM LEE: Yes. This is Young Eum Lee at dot kr. Yesterday at the new gTLD session, I was actually glad to see many of the concerns being expressed and I think Chris did a very good job, an excellent job, of bringing those out. But then I was very concerned, also, because of some of the things that were being said, which was, "Just let Internet be what it is," and that there is a fallback mechanism for registry failure, we are taking care of that. And that's where I'm concerned about. Because -- do I need to stand up? I don't think I need to. >>CHRIS DISSPAIN: You're okay. >>YOUNG EUM LEE: Okay. Because I did see a real need being expressed for the new gTLDs, for example, from the language community, from certain geographical communities, and those communities that have not been represented on the Internet so far, and that's -- that was very promising. But if we're going to start talking about possibly thousands of new gTLDs, I mean, yes, currently the current system is working very fine, but then even within the current system, we have phishing, we have -- there are lots of problems that are arising, even within the system, and we're constantly trying to make amends for that. But now, if we have a system where we can allow for thousands of new gTLDs, unless it's a new gTLD that a community or a group of people really, really need and really, really want -- like the ones I've mentioned previously -- I mean, if there is something wrong, if they really wanted it, they will do everything to try to fix it. But if it's something that, well, just let it happen and -- and just let it run away and then later on, if it doesn't work and if nobody else cares about it, what happens to those people that have registered for that domain? I mean what happens to that? And I'm really concerned about the threat to the security and the stability of the Internet, that so many new gTLDs might incur. >>CHRIS DISSPAIN: Yeah. >>YOUNG EUM LEE: And I'm actually asking you: What is your thinking on this? Because lots of concerns were raised yesterday and... >>PAUL TWOMEY: Unfortunately I wasn't in the room for all of yesterday, but -- >>CHRIS DISSPAIN: But you know the consumers. >>PAUL TWOMEY: Well, I assume I know the consumers, and I think the issues you raised are certainly a good part. Part of the reason we're doing this discussion around the implementation process is specifically to allow people like yourself to make observations. I would make a couple of points, I think. First of all, a lot of these issues that are getting raised now, by a broader group, were certainly raised within the GNSO policy process, so I think, first of all, we shouldn't assume that this -- what was proposed came out unthought, and there was a lot of the same discussions and a lot of the same interests were in the GNSO process, so there was a lot of discussion of these issues. I think the second thing I'd say is, there's a fundamental question about offering competition and choice to registrants, which comes to basically: Do you or don't you? And we've gone through two rounds of experiment -- you know, two rounds of introducing more competition, which were not an open process. They were either a formal of beauty contest or they were a formal of, "Here's a particular set of criteria we might be willing to receive." And in both situations, I think the conclusion was they were not -- they were not particularly long-standing approaches. You know, there was always -- the first one had problems -- you're basically playing venture capitalist picking, which one you like. The second one showed the ability to people to game and to twist and to try to get certain models within the sort of criteria you set. So the -- I think the sense is that it's best to have an open process. Will that end up with lots of TLD applications? Yes, probably. Will that end up with TLD applications that will not necessarily be popular with users? Yes, it would. Will that end up with TLDs that may, indeed, in a business sense fail? Yes, probably, in the long term. But inversely, you know, that's sort of what comes with the market. Are we going to be able to -- also understand what strings really work for people, what do users really want, what are really going to be business opportunities, the answer is no, it's probably best we let people use a market mechanism to determine that. Now, the second part, which is -- I think you're absolutely right about, let's be concerned about the registrants here and let's be concerned about potential failure. We have been doing a lot of work in the existing gTLD environment to -- and we need to do more work -- on ensuring plans for registry failover, how to plan for that, how to do a similar thing for registrar failure, and how to ensure certain provisions. We're looking at the registrar accreditation agreements. We are -- our thinking is heightened by the issues that you're raising, that there will be, you know -- we have unknown unknown problems here. There will be things that will happen we haven't thought about. As a consequence, we do have to think quite a lot about that, how to keep a monitoring on registry failure. And that's some of the things we're going to put into the RFP and contract process. >>PETER DENGATE THRUSH: I'd just add to that, Paul. In addition, obviously, to the registry failover, we do the obvious in the new process and require reasonably good proof of performance and technical conditions on entry. Obviously things change, so the -- but we -- as well as trying to pick it up at the end, there are threshold requirements on entry. >>CHRIS DISSPAIN: Okay. Dave was next. Dave Archbold. [Speaker is off microphone] >>CHRIS DISSPAIN: Hello. Sorry. Could you -- would you mind waiting your turn? Because gabby, no, we've got a speaking order. Dave is -- I'll get to you in a minute. Yes, Dave. >>DAVID ARCHBOLD: Dave, Archbold, Cayman Islands. Could you give an update on ICANN's review of geographical regions that was due to be completed by the board in 2006? >>PETER DENGATE THRUSH: I can assure you it's not going to be discussed at this meeting. >>PAUL TWOMEY: I understand from staff that this is -- and perhaps Denise can help more on this answer -- that this is an issue being discussed in other constituencies and SOs. I don't think their discussions have come to any conclusions. >>CHRIS DISSPAIN: I think we've asked -- we're asking to -- >>DENISE MICHEL: That is correct. The board directed the GAC to work with the GNSO, or the ALAC and the GAC to solicit their opinion on geographic regions and how -- [Audio cutting in and out] >>PAUL TWOMEY: Thanks, Denise. >>CHRIS DISSPAIN: So hang on -- so that we're clear, does that mean that we're waiting for the other SOs to say if they think that our suggestion that there should be a large working group across the SOs to discuss the regions is a good idea? Or are we waiting for them to tell us to tell us what they think about regions? >>DENISE MICHEL: Both. >>CHRIS DISSPAIN: Both. >>DENISE MICHEL: Yeah. All three of them actually want to address both the process and the substance. >>CHRIS DISSPAIN: Okay. Dave, did you want to... do you have anything else you wanted to say? Nothing to say. Okay. Roelof is next. Roelof? >>ROELOF MEIJER: Roelof Meijer, dot NL. I have a lot of questions on the gTLD issues. I'm not going to ask all of them. Chris, what do you want me to do? I have got a couple of questions. Do you want me to ask them? >>CHRIS DISSPAIN: Yeah, just ask them. >>ROELOF MEIJER: First, if I were considering applying for a gTLD apart from what was presented yesterday, I would need more information to see if I had a business case or not. For instance, briefly touching that just now, what would be the price for application? Would there be any other criteria that would make my business case disappear altogether? When do you think that all that information will be available? >>PAUL TWOMEY: I'm hoping -- well, I'm hoping in the next four to six weeks we will have all of that information. Please, that's my hope. Don't hold me to that because we're actually dealing with some outside dependency issues of people we are in consultation. The biggest part of the talk is the price of application. We are doing -- I can tell you now that the costs so far of the process are coming up to around $10 million, that the price it has cost us in terms of development. And the application fee process is supposed to look at some return. It may be a bit less than $10 million, but there is not much change left out of that process. And so that's one thing, we're looking through the cost process. We got a very careful -- we've had outside people working with us, Deloittes and others, working for us this whole trying to figure the whole transparency of the costing and then looking perhaps at the price. We've also had some economists working on us on some form of modeling for what sort of demand we're going to see. But the demand question is very difficult because you are caught with a price demand trade-off in so many applications, if it is $10 in so many applications or if it is $1 million. We are still trying to work through exactly the price, of how to get some sense of the demand before we can set the fee. We are not trying to make money out of this, okay. Let me make it quite clear, we are not under a policy that says "ICANN go make money out of this process," but we are trying to work through in a way which is quite clear to people here's the costing that's involved, and here's how the price has been set. But that price is not yet completed. The secondary, I think, probably the biggest area that's still outstanding, is some of the issues on the rules that will apply to the objection criteria. Probably mostly the community one and the morality of public order, there's some more details of what will be behind those two protection criteria. And the third area, as I said before, is going to be this issue of registry-registrar functional separation which we're still waiting for the economist's report. Apart from that, please let Kurt and others know if there would be further things you would need to be to make a business decision, you as a business person, not you, Roelof. But if a person was going to make this application, please let Kurt know if you think there is further information that one would need to have. >>ROELOF MEIJER: I can think of a few. Are there going to be additional criteria? Are you taking a first whatever bunch of 100 or 1,000 and who you want to earn back your 10 million plus with that first bunch or is it going to be over several years? I mean, it is not only the prize of an application. Okay. Now -- >>PETER DENGATE THRUSH: Sorry, perhaps, Roelof, the Board Governance Committee is dealing with that right now and has got pages and pages of analysis of all of the costs and is trying to determine the repayment rate which affects how much each will be because if we pay it off over ten years, then it is going to be slightly different if it pay it off over the first 100 applications obviously. We are trying to analyze what the additional sum for risk et cetera should be. If you want to look at any of that in its raw state, talk to members of the board -- >>PAUL TWOMEY: It will be available for you, but don't go and ask today. But it will be available. >>PETER DENGATE THRUSH: I was going to suggest that you don't because at this stage it is just lots and lots of data. I can assure you that that work is going on and it is actually a complex process. >>PAUL TWOMEY: We will make it transparent. >>CHRIS DISSPAIN: One more question, Roelof. >>ROELOF MEIJER: Okay, Mr. Chairman, I was just going to ask you if I had time left. From a registry perspective, I think competition is a good thing. But what has me worrying a bit is that so far I haven't heard if there's going to be any limitation. Yesterday somebody talked about the completely flat system, the DNS becoming a flat structure instead of a tree structure. Just from a commercial incumbent registry perspective, that doesn't sound overly interesting to me. So is this something that you -- no, I have to rephrase the question. Do you at the moment already foresee a certain limit? Or is it just open everybody who can pay the fee and for every application that ICANN can approve and, of course, every approved application that ICANN can process is going to go into the root? And so you might end up being the largest registry there is? >>PAUL TWOMEY: There is certainly the discussion that ICANN becomes the registrar of registries. The policy as has been put forward pretty much goes down the lines you have just said. >>ROELOF MEIJER: Sorry, is that the first line or the second? >>PAUL TWOMEY: That it is a flat structure in the sense it will be open to people to apply and that there is no hierarchy being imposed upon the structure. And we have taken advice from security and stability and the root server operators and other as to whether there are any technical limitations for such an approach. And the answer we've received is there is no real technical limitation for that approach. >>CHRIS DISSPAIN: I believe he was next. Let me say I do have a list of speakers but we are going to run out of time, so you might want to save your questions to accost Paul. Emily? Emily was next. Yes, you were. >>EMILY TAYLOR: Thank you, Emily Taylor from Nominet. Peter, just wanted to say, this is your first ICANN as president, right? >>PETER DENGATE THRUSH: No, but -- >>EMILY TAYLOR: Great speech the other day anyway. >>PETER DENGATE THRUSH: Merci beaucoup. >>EMILY TAYLOR: I understand there is a group of European parliamentarians who wanted to come and visit the ICANN meeting. Are they going to be meeting with the ICANN board? Do you know? >>PETER DENGATE THRUSH: I think the answer is yes. I think I've scheduled for a lunch with them tomorrow. I can give you more details offline, if you'd like. >>SEAN JACKSON: Sean Jackson from Grenada asking how much of the pressure for more gTLDs comes from antitrust concerns? >>PAUL TWOMEY: Let me put it another way. Part of the foundation of ICANN and one of ICANN's four foundational principles is promotion of and choice for gTLD registrants. That's one of our charters, and the community has been strongly supportive of that. "Antitrust" is an open and vague term. I'm not sure what you mean. If by that you mean that there is a community objective and ICANN objective to give consumers more choice than the original seven gTLDs, yes, that's a key part of the rationale. >>CHRIS DISSPAIN: There is a gentleman behind Roelof. You had your hand up? Yes. >> My name is Jiankang Yao. Yesterday I attended the new gTLD session. There will be thousands of new gTLDs in the near future. So maybe in the long future there will be thousands and thousands of new gTLDs. So these will be, however -- [inaudible] traffic on the root zone servers. Currently, there are three -- 13 root servers. As far as I know, only one root server, Asia-Pacific in Japan. And my question is, is there any plan for ICANN to add a new root server because in the future there will be thousands of new gTLD [inaudible] bigger traffic. So adding more root server is a solution. Thank you. >>PAUL TWOMEY: Three parts to the response. First part is there will be a cost to running a TLD -- a new gTLD. There will be an application fee. It will not be insignificant. There will be ongoing contribution costs. So, you know, one of the things that's going to be a natural selector, I think, about how many gTLDs there will be eventually is a simple return-on-investment calculation. We have gTLDs that have not done particularly well in the existing rounds. There will be those that don't do well secondly. The second part of the answer, at least for everybody else, because I think Harald is giving the answer personally, is that there are something like 160 instances of the root servers distributed, of which in the Asia-Pacific I think there is something like 20 or so. And there are sort of mathematical reasons and why there aren't going to be 13 root servers. The third one I would make, we are doing a review of the root server Advisory Committee starting later this year. And one of the potential questions you and others may wish to pose to that review is how would that committee deal with the question of giving advice on allocation of the root servers in particular if one of the root servers decided they would no longer wish to be an operator. How would you wish to decide to have another operator? That might be an opportunity to take that set of concerns into that review process. >>CHRIS DISSPAIN: Thank you. You were next, sir. >> MAO WEI: Thank you. I have a question about the ccTLD. >>CHRIS DISSPAIN: Could you say who you are? >> MAO WEI: I'm Mao Wei. Yesterday we have a meeting about a new gTLD. In the meeting, I know the schedule of the new gTLD, when will we open that? . But for ccTLD, IDN TLD, I don't know what's our schedule for that. >>CHRIS DISSPAIN: We're discussing that tomorrow. So we will discuss that tomorrow in our meeting. That's half a day set aside for that. We are rapidly running out of time. I can't see who that is. Is a Sabine. I will take a question from Sabine. >> SABINE DOLDERER: Sorry, thank you. I have a follow-up question to Paul Twomey. Speaking from experience, you say there will be a significant application fee for new gTLD and there will be, let's say, significant costs for working gTLD. Speaking from experience, I know that as to the amount of the domains go up, usually the price decreases. So even now it is a significant annual fee, if you have, let's say, 20 million TLDs in the root, I don't think that the annual fee will be as significant as it will be at the beginning. So do you have to take -- have you thought about that and how have you had a strategy developed in how you want to proceed in that? Unless you don't want to ship in money. [ Laughter ] >>PAUL TWOMEY: Well, we are thinking -- numbers like 20 million are -- You have just way outreached the upper bounds of what I have been told by others. But if you are going to put 19 million of those in, can you talk to me later? The numbers that one hears vary from some hundreds to potentially a thousand sometime next year in terms of what applications might come in next year. That's sort of the range of numbers that one hears. And we are thinking about that because it is, basically, an amortization table over what period of time do you do it? My point was just the following. There will be a cost. It is not like this is going to be just free for somebody. And the market, I don't think, is going to be sort of infinite. People probably share the same view. There will be some natural tailoring off when people feel the market is saturated. >>PETER DENGATE THRUSH: One of the other obvious checkpoints is the number of people that can actually run a registry and prove they can do it is actually quite limited. And the process to become an ICANN-accredited registry is going to be something they will have to go through. >>CHRIS DISSPAIN: Hilde? >>HILDE THUNEM: I will try to keep this short. I apologize for not having followed all the details of the new gTLD process. I have been a bit busy with other things. I want to ask the question that goes back to what was discussed at the Los Angeles meeting. Are there going to be any limitations on -- or any principle limitation on registering a country as a gTLD? Or is it left up to the governments and ccTLD of the world to sort of try to keep track on whether things are there in Chinese and somebody is trying to take their name? >>CHRIS DISSPAIN: The GNSO policy that went to the board says there should be an objection process reserved list. But both the GAC and the ccNSO have written to the board to say their views are that -- I mean, as to specific country names and territory names that there should, in fact, be a reserved list as I think there is in dot travel, dot info, I think. So that's an issue for the board to decide. >>HILDE THUNEM: Which is why I would like to know if the board has any thoughts about it. >>PAUL TWOMEY: We are still working this through for the public RFP process. So we have not yet -- we, staff, have not yet put it to the board in working it through. But there has been very strong recommendations from one of the GAC and this group that there should be some form of process followed for preservation. And I think frankly the GNSO policy process was a product of not being able to come to some other consensus with perhaps the recommendations they did. So I think there is a certain degree of sympathy for the proposition. The other thing I will be quite clear about my own personal perspective on, we will also put to the board that if there is an application for a geopolitical term, we have to work through what the application is for cities. But if there is an application for a geopolitical term that the clause provisions that were applied in the sTLD round, that were applied earlier, will be applied; that is, you will have to show either a letter of support or a some sort of statement of non-opposition from the relevant government at some level as was done by the people who applied for Catalonia and dot cat. Frankly, let's be really explicit about this, folks, we do not need ICANN to be the focus for every separatist group in the world. And as a consequence, there will be something in the contract which will have that perspective. >>HILDE THUNEM: My concern is back to the principle of what is a gTLD and what is a ccTLD. And just to make the point that do not go into opening the new gTLD process without having actually sorted out what is the ccTLD space and keeping that outside of that process, in what manner, practical implementation. >>PETER DENGATE THRUSH: It is pretty clear. ccTLDs are based on ISO 3166-1 two-letter country code list. >>CHRIS DISSPAIN: Peter and then we are going to close it. No, that's it. Peter, you can have your question and then we have to go. >>PETER van ROSTE: I have two short questions, yes-no, basically, on the budgets and one comment on the budget. I must say I am a bit -- >>CHRIS DISSPAIN: I'm sorry, what's this about? >>PETER van ROSTE: On the budget. >>CHRIS DISSPAIN: We are having the budget discussion tomorrow morning with Doug and Kevin. We are going to do that tomorrow. I didn't say that at the beginning. I didn't say it clearly enough. We will talk about the budget tomorrow morning with the people who actually put the budget together rather than now. So I will bring this session to close because these gentlemen have to be elsewhere and we have other things to be getting on with after a coffee break. Can I say thank you very much for coming and we will see you again next time. [ applause ] >>CHRIS DISSPAIN: Ladies and gentlemen, we're going to start again at 20 past 11:00, on time with the IANA section, so please be back in the room. [Break] >>OLIVIER GUILLARD: Starting shortly. >>PATRICIO POBLETE: Okay. We are ready to begin again. Our fearless leader is going to be in a different session, so I will be chairing this, and as I understand it, that just means that I should introduce Olivier to chair the session, and make sure that he finishes on time. So it's all yours, Olivier. >>OLIVIER GUILLARD: Thank you very much. Is this working? Is this better? >>MULTIPLE VOICES: Yes. >>OLIVIER GUILLARD: Okay. Welcome to all of for you the IANA session. We have not much time because initially we should have had one and a half hours, and at the end we are -- we have less, so I'm going to go quite quickly -- not to say very quickly -- through the topics, since as you can see the agenda is quite loaded. We will have a brief presentation -- a brief update and report on the IANA software from the IANA working group perspective and IANA, with the development of the new software that IANA is currently deploying. I had a note from VeriSign that might -- and that should arrive over this session -- to provide an update from its point of view about the root zone management. We will have an update on DNSsec with the help of Richard and Kim. Gabriella Schittek has sent a couple of mails to ccTLDs managers using the IANA database contacts and she will make a report on what happens with the mails she sent. We will have the usual report from IANA by Kim, and also a word on the IANA working group work plan. So I'll start with an initiative that the IANA working group has launched to test the new IANA software, which is currently deployed by IANA. I will go very quickly through the slides because all the information is here, so -- and we don't have a lot of time. So as a background, you may remind that IANA is deploying a new software for TLD to update their data in the IANA repository. The goal of this software is to increase an automation in IANA operations. You can find background information in the presentation that was performed in Delhi about it. So IANA announced in Puerto Rico that they had set up a platform for TLDs to test the new interface, and it's possible for those cc's that would like to test this interface to request an account from IANA staff to have access to the test bed. IANA working group has proposed a testing approach to help cc's that would like to test this test bed, and it's documented -- the approach is documented and can be accessed through the ccNSO IANA working group Web site. The paper is referenced in this presentation. The IANA working group has also called for volunteers across the world ccTLD community to participate in the work and to ensure a more systematic testing approach of this new software. So thank you to those that have volunteered and participated in this testing initiative. A quick word on the testing approach that was proposed. We have sorted the different kinds of update that a cc could send to IANA for updating its information in the IANA database, so four main types of requests. And you should have a particular look on the difference between those that are not changing the root zone and those that are producing changes in the root zone, because they are different in the process flow. I'm not going to now go into details. If you have questions, come see me afterwards. So the work was distributed amongst the testers, and as I said previously, the testing approach is documented on the ccNSO IANA working group Web site. We also had to launch properly this testing approach, a couple of coordination issues to deal with with IANA. First, the problem of communicating amongst testers, and with IANA. IANA has set up a mailing list for us, or reactivated, actually, a mailing list that was existing previously. We had a problem, also, to properly report the bugs that we could on the interface, and we asked IANA -- and they did it, actually, and the developers -- to set up a bug tracker for us to report through a unique means, with the proper archives the bugs that we could notice. And also, one problem is that IANA still needs to manually review all the requests that are sent on the test bed, so the staff agreed to review and to proceed with the request we sent to the interface manually at certain particular times to facilitate the testing process. Another problem that we met, as testers, is that before implementing any root zone change, IANA performs technical checks on ccTLD DNS configuration and you may recall a consultation that was performed two years ago by IANA about the technical checks that are performed. By them before changing the root zone. You have the URL here. So before the new system, IANA was launching the technical checks manually and now the interface is doing the checks automatically, so one of the problems we had without entering into details, to test this interface we needed to have properly installed DNS, so we couldn't use our real DNS servers because if we wanted to play with the test bed, we would have needed to change the real information in our DNS, so we had to set up a test bed for the purpose of testing. Okay? So it has delayed a bit the testing process. So where we are, based on the four types of requests from ccTLD to IANA, we have more or less -- I say "more or less" because some operations could also be relaunched or tested again -- we have more or less tested all the type of information that we can change in the interface. We have checked -- we have launched the updates that are regarding administrative operation in the IANA database. If a contact -- if a technical contact wants to change its telephone number, this will not produce any change in the root zone, so this is the kind of change which is addressed here. We have started to check simple modification like changing a particular technical information on the DNS that holds the TLD, like an IP address. We have started this process. It's not finished because the test bed to test the IANA test bed was installed just four weeks ago. And we have not tested things and to be concrete things like DNS server that would host more than one TLD. We come back to the famous "new issue," which has not been tested. Okay. In the meantime, IANA has indicated that the implementation of the software would require amendment of the IANA contract with the [speaker is off microphone]. It was announced in [speaker is off microphone] and the 12th of June -- You can't hear me? Is it better? Have I changed anything? Okay. It needs to be -- sorry about that. You have my sympathy. Is it working? Yeah. Okay. So IANA has indicated that the implementation of software change will require amendment to -- of the IANA contract with the DOC. And the 12th of June, IANA is supposed to mail to the testers to inform them about the cessation of public testing. It's not clear yet if it's a definitive cessation, or if it will come back later. I go quickly to our kind of interim report based on where we are and what we have seen up to now, testing the software. And it's just, let's say, a consensus of communication that we are -- we had across the testers. In our view, the IANA software is still under development. The bug tracking process is established. The developers are really working hard and are responsive. Many bugs that were reported are no longer showing up in the bug tracker, so we assume that they have been fixed. But the software requires continued testing. We also have noticed not only bug in the interface, but also in appropriate behavior in the process flow of confusing output information is still noticed. Another question that we asked to -- that was asked to -- amongst testers is that the new software doesn't change the IANA process flow with regard to USDOC and VeriSign interaction, so there are still external actions to IANA that must be undertaken for the ccTLD requests to be managed, so will the soft -- this is an open question: Will the software really improve IANA performance? As you saw in the testing -- and it has been confirmed and we think actually it's important to have this manual review check over each request -- IANA still needs to review manually each request. So a question is: What is really meant by "automation"? Last thing, the interface and the software doesn't change the back-end process flow but it does change the front-end process flow. It changes the way the ccTLD is interacting with IANA, because we have an account and an interface plus the usual technical and a mid-contact. So the interaction between IANA and ccTLD to update information in the software become more complex. The question is: What is the benefit? One of the questions that we asked is -- because to be honest, we were in the process of testing the software and at the end we were thinking to ourselves what was really the question that this software was defined to respond to? And we just raised the point to ask for the initial specification, so that's the current question about the software. What are the specifications and what was the real point of these tools? Okay. That's about it for my presentation. Initially, in the agenda -- and I see Ken, Ken Silva. Maybe you can come. Basically, the question in this report, Kim, in his general report, will talk about -- please, sit down here. Kim will talk about the deployment of the new IANA software in his presentation. We also, like we started to have VeriSign talking of root zone management from VeriSign's point of view because they're, of course, involved and they made nicely a presentation in New Delhi. We have asked Ken Silva to come and to talk about this root zone management from the -- their point of view, so thank you, Ken. >>KEN SILVA: Thanks, Olivier. Can y'all hear me? So this was really just -- I don't have any slides because this was really just sort of a quick five-minute update here. Basically, the root zone management process includes this new IANA process which Olivier was just talking about, which is to -- as it stands today, what happens is if a ccTLD or any TLD wants to make a change to the root zone with respect to their top-level domain, there is a relatively manual process where a template must be filled out, it has to be sent to IANA, and then it is sent to us and DOC. We begin technical checks, manual technical checks, of the system as were described, and then -- and we do that while we're pending approval from DOC to actually make the change. The new process, which has been in testing since November, has -- which includes the IANA piece to quasi-automate the process, it is then connected via EPP back to VeriSign, that automatically updates the database, and then the checks are performed in an automated fashion, which should reduce the time that it takes to turn these root zone changes around. We still have to wait -- even after this process is complete, we still have to wait for the approval from DOC, so that part of the process hasn't changed, but that wasn't the slow part of the process. So we've had -- we think that the software is ready. In fact, I think we're really just coordinating now to try to go into what we'll call "parallel operations" which means that the manual process will still be used, the automated process will be used, we'll verify that the results are the same for some period of time, and then -- and then we'll switch over and this will become the primary process. So that's really kind of where it's at right now. The software on our end has been in OT&E for some time and through IANA has been opened for public testing since -- I think its November. Is that right, Olivier? >>OLIVIER GUILLARD: Yeah. >>KEN SILVA: Yeah. Okay. So really, I think right now we've done most of the testing, and in fact, some of the testing which was pointed out that hasn't been done by IANA yet, we've actually already tested and we know that that functionality works. Both through their interface as well as through our own. So, you know, we think that the process is ready to move to the next level, which is to come to agreement that we're ready to go into a parallel operation with it, which is both with the old system and the new system simultaneously. >>OLIVIER GUILLARD: Are there any questions about root zone management, software? I think -- yeah. >>MAO WEI: I have a question. I'm Mao Wei. How long the whole process for the modification? How long will it take? >>KEN SILVA: As it is today or in the new system? In the system, we would expect to be able to turn that around literally about as fast as it will take the DOC to respond, and that has typically been within, you know, 48 hours for us. >>MAO WEI: I have another question. Why are we still need the approval of the DOC for the modification? >>KEN SILVA: Well, that process has been the process that we've had, you know, really since the beginning, so I -- I don't -- there's -- that I know of, there's no plan to change that process. >>OLIVIER GUILLARD: Maybe Kim wants to add something on that. >>KIM DAVIES: Hi. Just a couple of clarifications. With respect to the time frame, I'd just mention that's VeriSign processing time, not end-to-end processing time from the time a TLD operator submits a request to when it gets implemented in the root zone. Secondly, the contractual relationship the DOC has with ICANN dictates that requests to change the root zone require DOC authorization. >>OLIVIER GUILLARD: I have a question, actually. [Laughter] >>KEN SILVA: That's cheating. >>OLIVIER GUILLARD: Is it meant here that there will be modification in the VeriSign contract and the ICANN contract or... >>KEN SILVA: Well, I don't understand that there's any need to change any change to the contract and I'm not sure that that's clear yet. >>BARBARA ROSEMAN: Hi, this is Barbara Roseman. I'm the GM of IANA. We have had conversations with DOC and in their view, depending on the full proposal that we send to them, there may need to be modifications to both the CRADA and the IANA contract. Right now we believe that there are only some very minor modifications to the IANA contract, having to do with the process as it's outlined in the contract itself. And so it really -- we're not talking about any fundamental changes to the relationships defined in the contract. These are really modifications of process details that are in the contracts at the moment. >>ONDREJ FILIP: Ondrej Filip from czNIC. I just wanted to ask you what all kind of requests have to be approved by DOC? Is it just the root zone-related things or also the -- I don't know if I would like to change a telephone number in my IANA contact. >>KIM DAVIES: Every change to the root zone database except extremely routine changes require authorization, so changes to contacts, persons and so forth, require authorization. Changes to the root zone itself require authorization. It's -- if it's correcting a telephone number, we send them notification but we don't wait for authorization. >>KEN SILVA: Did someone in the back have a question. >>OLIVIER GUILLARD: Oh, yeah? Any other questions? I think this is it. Kim will come back in his presentation to provide -- oops. Sorry. -- to provide an update on the deployment of the software later. So Ken, thank you very much. >>KEN SILVA: Thank you. >>OLIVIER GUILLARD: For this update. [Applause] >>OLIVIER GUILLARD: Okay. Thank you. Okay. Can you -- yeah. That's better. Update on DNSsec. Before Richard provides some information on signing the root and the test bed that IANA has performed for DNSsec and signing the root, a couple of information from the IANA working group point of view. Just a quick background. I'm not going to get into details. Just to remind that the IANA working group was asked for help in providing input to the ccNSO council on root zone signing from a technical perspective. You may remember that the IANA working group set up a ccTLD group to write a paper on DNSsec, and basically with the goal to increase awareness about this technology and also to respond to the council request. You have -- you can go back to the presentation that was performed in New Delhi about that. Some feedback from CC about DNSsec and signing the root zone issue that we had and that we can share with you, a survey was conducted last year and was presented at the last ICANN meeting already. It was conducted by the ccNSO. This survey shows that not every CC responded, okay? So -- but from those that responded, it's shown that very few cc's have deployed this technology, but many believe that DNSsec will be deployed in the future. Of course those TLDs that have signed their zone are looking forward to the root zone to be signed to facilitate their DNSKEY dissemination and RIPE has also sent a formal request to IANA for their key to be published. On the other hand, some TLDs have expressed concern about DNSsec. Some of them, DNSsec is complex and heavy to deploy for an unclear benefit. It could send the wrong signal to the market that the DNS would be perfectly secured with DNSsec, which is obviously not the case, because DNSsec improves security but it doesn't deal with all the threats that the DNS can face, could face. There are side effects in the technology, zone walking which is now fixed with NSEC3. A lack of available tools to deploy DNSsec and also there is an argument which is now going across the community which is at the time of the design of the DNS, the DNS context was not the same as today, so some threats that we had ten years ago are not any more valued for the new DNS that are now announcing this technology. So DNSsec may not be as useful as it would have been ten years ago. So yet another CC feedback. We -- there was a discussion over the last GA -- CENTR GA on DNSsec and a report from the tech group, so following this discussion, I asked the question: Would you have any problem for the root zone to be signed from a technical point of view? Then following that, people were consulted by mail, but it was last week so I don't have a lot of responses yet. 17 responses to the question were received. 14 cc's said that they didn't see any problem for the root zone to be signed from a technical point of view, but two expressed concern. The one is asking for additional information about the DNSsec technology as such, and the way it would be received not by the TLD but by the cache operators. Many what he says is that I don't feel any demand from my cache operators to install and deploy this technology, so... This is one of the questions. But the paper that the IANA working group started to draft may provide some information, first information, to respond to this question. And another one asked for documentation about the procedures that would be implemented if the root zone was signed, so this is another type of concern. I had one response of someone that didn't understand the question. Okay. Some additional input. The RSSAC was also contacted by the IANA working group, and they were asked exactly this: Would there be an issue for the root server operators if a signed root zone was to be published. As you know, DNSsec increased the zone, adds load to the normal DNS operations, so it was a concern that might need to be asked to the DNS -- to the root operators. I had, last week, a response from Matt Larson, who is cochairing the RSSAC, I believe, and he said that up to now, root server operators have informally indicated that they would be ready at this time to serve a signed root zone if they were asked for, but they will have a meeting in Dublin at the end of July and because of our question, it will be formally raised in their agenda, so we should have a response -- a more formal response from the RSSAC after this meeting in Dublin. Some other indications from the SSAC and from IETF also. So the SSAC has posted -- I can't remember when, but a couple of -- a few months ago a recommendation and a paper recognizing that any technology deployment on the global scale is apt to reveal issues not considered in protocol design and development nor in controlled test environment. And more recently, SSAC has also launched a survey of DNSsec, capable DNSsec implementation, so this is still from the SSAC perspective an ongoing issue that is considered. Last thing -- yeah. So just to let you know that the RFC 5155 is now published and practically, this is the standardization process for DNSsecbis that includes NSEC3, which is now fulfilled. You have some expert here, if you have questions on that one. But the standard -- basically, it means that the standardization process is now practically fulfilled. That's it. Okay. So two quick things. From IANA perspective, there are two different things that needs to be viewed with regard to deploying DNSsec at the root level. First, there is the IANA test bed, which was launched -- how long now? >>RICHARD LAMB: A year? >>OLIVIER GUILLARD: A year ago, and so the root zone is signed currently by IANA and proposed as such on a test bed, which is accessible by cc's, and Richard will provide an update on that. Some open questions on this test bed. And another thing is that on the last April, ICANN has authorized the creation by IANA of a DS key registry for top-level domains, DNSsec key. A Trust Anchor Repository to be set up by IANA. So I don't know if Richard -- maybe it will be in the presentation of Kim? >>RICHARD LAMB: Yes. >>OLIVIER GUILLARD: Yeah. So Kim will update about this. As a first approximation, the Trust Anchor Repository looks like a good initiative, since it would help those TLDs and DNS cache operators that wants to deploy and use DNSsec without exposing the others to any risk. There are still open questions about this Trust Anchor Repository. The first one is: What would it look like? Which format would be used to publish the keys from TLDs? Which protocol would be used? What would that cost to deploy such a thing? And will it be used effectively? Because there is no point to deploy something new if it's not matching an effective need from TLDs and cache operators. So yep. I leave now the floor to Richard that will update on the first issue with regard to DNSsec at IANA. I'm not opening to questions now. Let's wait for -- because we have not much time, so let's pass through. >>RICHARD LAMB: Hi. I'm Rick Lamb. I'm the DNSsec program manager at IANA. And one of the reasons for me to give this presentation -- short presentation is to just let people know that we are doing something and that there is progress being made. One of the key points -- I've listed here three things that are next steps for getting the root signed: Specifically, further consensus from the community that ICANN, in fact, should be the one that -- ICANN-IANA should be the ones that, in fact, sign the root. We've gotten some support from this, as Olivier mentioned, from RIPE and dot se and dot uk. They have all published letters. The ccNSO survey that was done is actually very useful. I very much appreciate that work. That's something that I've been passing around lately because there are still some parties that have questions about whether DNSsec is something that the community even finds useful or even wants or would even accept. The other issue that is a step that has to be overcome is there are still some issues we need to get clear with our relationships with D.O.C. and VeriSign as far as modifications to the contracts -- the IANA functions contract as well as the VeriSign CRADA contract. That's actually something that's in play and work is being done on it. So I feel that's got a life of its own. And then, finally, are we technically ready? And I believe IANA is. We have had this test bed, as Olivier pointed, out for a year at ns.IANA.org. We are very happy to have anyone please test against it. We have had a fair amount of testing done from many of the folks in NLnet Labs, which we appreciate very much, as well as some others. I think that's important. What needs to be done in that last step that we are completing now are some of the operational practices, procedures that need to go in place that may sound somewhat technical. And I am not going to go into too much detail on this slide but they are issues of key management and other aspects that need to be taken care of. But some of the things that would be very helpful for me at this meeting in particular to have people come up and tell me are there concerns, tell me what your concerns are because as we design some of these practices and procedures, for example, for key generation and rollover, it would be very useful to understand your concerns. For example, there's something that's often referred to as a key ceremony when you generate a key -- a root key. The current design that I am working on and proposing is one that very much reflects that of a certification authority where you have multiple stakeholders involved. You have a wide range of participation which makes this more of a transparent process. Anyway, the point here is that sometimes in the technology -- in the design of the technology, it is important to get those concerns addressed and built in. So that's something I'm working on. That's pretty much it. If Olivier doesn't mind, there are a few questions that I've heard while I have been at this meeting that I would just like to make clear. DNSsec is an optional, market-driven thing. Once there is a switch thrown, once this is turned on, it is not like people can't go back. It doesn't encrypt the root file in any way. It is simply additional functionality. And so it's not something that is being mandated or being pushed down in any way. It's something that can help, and I absolutely agree with some of the findings that it's not an answer to everything. It is just something that is simply going to help. That's something that -- I think some of these questions need to be clarified and people need to understand because I do get some of these questions sometimes and I'm perplexed by them because it's not -- this is just additional functionality. So I hope during the course of this meeting, I get to talk to some of you, the ccTLD operators. All right. Finally, just the related efforts, that Kim will talk somewhat about, the trust anchor repository that's being developed. Some of the IDNs have been signed -- the test IDNs have been signed for people to work with. ICANN.org would be one of those things that fall under the category of eating your own dog food, so we would try to do that as well. And I know that some of you may have heard that dot org is on the way to being signed. And another piece of information that may or may not concern you, I know the U.S. government is about to release some guidelines that require all of their own agencies as well to deploy DNSsec. So whether you care about what they do or not, that's a pretty good indication of at least a direction that one part is going in. So it's a good thing. Let's see. The dot ARPA transition and signing, we have been asked some time ago to sign dot ARPA and we are currently collaborating with the IAB and Department of Commerce to get that to happen. All this is technically ready. It again still depends on some policy issues to get worked out and some contract issues to get worked out. But just myself as the DNSsec program manager, I am always optimistic. [ Laughter ] Thank you. That's it. Just questions. >>OLIVIER GUILLARD: Any questions? >>ROELOF MEIJER: I'm just quoting somebody very famous but I think this is one of the subjects where the phrase, this is not only a technical issue but also a political one, is eloquent. How big do you think the chance is that they are there are going to be political reasons why the root is not going to be signed any time in the near future? >>OLIVIER GUILLARD: Just before anyone responds, outside the scope of IANA working group. Sorry, was just joking. >>RICHARD LAMB: I think it's important for all parties to understand how it works. I think the importance is education. I think once all sides understand how this all operates, things like trust about root key issues, holding root key issues, will go away. Other issues about changes that just simply take a long time, not based in any particular political issue, those are things that -- I have no control of, but I do feel that I have some input to be able to educate both policymakers and operators as to how this works. For example, like I mentioned the root key -- a key generation ceremony, something like that, if it is done in a very open and transparent fashion where no one holds the private key -- and I will even go so far to say that my understanding is that U.S.G. -- the technical parts of U.S.G. have no interest in holding the private key. So that those sort of issues should just go away. Once everyone understands how cryptography works, how DNSsec works, these actually are not complicated issues. I am sure you know that. You are asking the harder question. Right? >>ROELOF MEIJER: But "everyone" is a large group. I am quoting from one of your slides. You wrote "we need consensus of support that ICANN should do it." >>RICHARD LAMB: Yes. >>ROELOF MEIJER: I don't know if you mean it that way, but "consensus" means, as far as I know, that nobody objects. We all agree on the same thing. >>RICHARD LAMB: You know, I'm relatively new to this process so I'm not sure at what line, at what point -- we need to feel before we go forward and do something like this that everyone agrees. And so, you know, at least for me at this meeting, I want to understand if there are any problems or concerns. I'd like to hear those concerns so at least I know I'm not wasting my time going forward with my engineering efforts. So I don't know where that line is. I mean, I think, maybe "consensus" was the wrong word because that implies a complete agreement. But I don't know where that line is. >>OLIVIER GUILLARD: If we take this route, we are going to discuss what a "objection" is and how -- and everything. This is currently an ongoing process. If you have seen all the different competencies about these issues and all are doing their work, are solicited to express their potential problem, this is presently the ongoing process we have now, I suspect. Just one -- No. Any other question on DNSsec? Something that maybe useful, Richard, for me and the working group would be to identify better who are the testers of your test bed so we can contact them and see if we could try to articulate some testing with them from cc's. >>RICHARD LAMB: I would be happy to do that. >>ONDREJ FILIP: I have one question regarding our TAR. We would like to our initial zone dot cz very soon in September and, of course, the situation of uncertainty the wrong root will be signed or not, it is quite a problem for us because we need to advise all users whether they should use some DLV or whether they should wait for the root zone to be signed or whether they should use some TAR proposal. Is there some precise plan, some timing how the TAR will be managed, how it will be resolved and how it will work? >>KIM DAVIES: I'm actually going to present about the trust anchor repository in my presentation; but in essence, we are looking in the next few months. It is not a complicated project, so I don't anticipate it will take very long. >>ONDREJ FILIP: I wonder why it's not technically complicated because, you know, having such a repository, it is absolutely the same process as having such -- to sign the root. You still need to have some cryptography that controls the repository that has some keys that has limited times. I think technically it is absolutely the same. I don't see any difference, to be honest. >>KIM DAVIES: Um, I don't really have any particular insight on that question. For us there's -- I guess I wouldn't say experimental service, but as a service with limited usage, I think the operational impact with the interim trust anchor repository initially will be quite small. And, in fact, as we start using operationally, we will get experience and kind of get a feeling about how it needs to work. Ultimately, though, with root signing, it is anticipated that will be a formal part of the root zone management process. It will involve the same interface as managing the root zone. It will involve all the same formal procedures that roughly are consistent with how root zone changes are made today. At least for us, the engineering aspect of implementing formal root zone signing, key collection, that process is somewhat different to the trust anchor repository which, as much as possible, we are trying to separate from the root zone management function in that it is a discrete service that, in fact, anyone can provide. We're doing it out of convenience and because we've been requested to do so. But, in fact, there's nothing specific about IANA that says IANA needs to run the interim trust anchor repository. In fact, if we didn't do it, I know there is at least one other party that was intending to do it themselves. That's quite distinct from signing the root, which can only be done by the person that edits the root. >>OLIVIER GUILLARD: Since we are running out of time, I think it's better to go to the next topic. For the transition -- sorry. I add this for you and I give this for you since we are talking about security. (Video playing). >>OLIVIER GUILLARD: The spot says -- I'm going to pass it again -- the spot says, "What's the point to be secured if you are not securely linked? So I leave that to your thoughts and go to the next topic. So Gabriella used the IANA WHOIS database to contact the ccTLD managers and we asked her to provide a report on what she saw with regard to the e-mails. >>GABRIELLA SCHITTEK: Okay. Hello, everybody. I have been invited to say something about my experience with the IANA WHOIS database because I had the wonderful task of e-mailing 240-plus ccTLD managers in the world twice. So I do know something about the accuracy. Some background information is we used it, as I said, twice. Once on the 5th of October, 2007, and second time on the 4th of April, 2008, for sending out information which we thought were vital to ccTLD managers, which we wanted everyone to have. And the only official source that we have is the IANA WHOIS database. So this is why it was used. And I sent these e-mails to all the administrative contacts listed in this database. So the first e-mail we sent out on the 5th of October, this was about asking you questions on IDNs. I received 34 bounces in total. These three came back with messages saying the server was over quota, recipient storage full, which means that only 31 were, in fact, invalid but three were still not reachable because their mail server was completely loaded. The second time we sent out e-mails was almost exactly on the day a half year later. This time I had 28 bounces in total and four messages coming back, mail servers over quota, recipient storage full or mailbox full, which means only 24 addresses were actually invalid. So, in summary, if when you compare these two bouncing messages -- reports from October and April, in total 16 addresses had been updated from October. However, 18 ineffective addresses remained the same and there were 10 new ineffective addresses. Three of the over quota or mailbox full messages remained the same and there was one new. And that was all I had. >>OLIVIER GUILLARD: Excellent. Yeah, question from Don Hollander. >>DON HOLLANDER: Thanks, Gabby. As a regional organization, we see similar things. My question is, have you engaged with the regional liaisons to identify -- you know, to get the people -- and that's been fixed or not effective at all? >>GABRIELLA SCHITTEK: I've sent this report to them just a week ago, and with addresses specified. And they will try to contact those who they have contact with. >>KIM DAVIES: If I may, I would just like to add this is an ongoing process that IANA staff under also undertakes. We use these e-mail addresses primarily in operational capacity. If they don't work, we try to make inquiries to rectify them and, where possible, to make them as accurate as possible. Unfortunately, in our position, often a TLD manager doesn't realize the requirement to keep it up to date until such time as they need to make a change, at which point it is more complicated because we can't verify with them through e-mail. So it is definitely a problem that we recognize and if it is not obvious, we certainly encourage everybody to keep their contact details up to date. There are also some more fundamental questions about why do we list these e-mail addresses publicly, what are they used for. And it is something we've raised within the ccNSO IANA working group to consider further. >>OLIVIER GUILLARD: By the way, if there are any suggestions to do more, to try to help in improving those information, feel free to comment. Excellent. Let's go now for the major IANA update from Kim. >>KIM DAVIES: Thank you. I hope it's not too major. Okay. So I want to talk to you today about a few issues. It's not designed to be a comprehensive overview of IANA, but just three particular issues that I think are of particular interest because I don't recognize many of you in this room, which is always a good thing because it means more and more people are participating in these meetings. My name is Kim Davies. I work within the Internet Assigned Numbers Authority. IANA 101 is that IANA is a department of ICANN responsible for executing certain functions, and in particular, most interesting to you, is we operate the DNS root zone. So we're responsible for the delegations in the root zone to top-level domain operators. The three issues I would like to speak to today is, as we've already discussed, the interim trust anchor repository project. I'd also like to talk a little more about the process for implementing the root zone management software that Olivier and Ken spoke to earlier. And, finally, there was an incident a couple months ago regarding -- and I am using quotes here -- root server hijacking. Certainly "hijacking" was the word that used in the media. I am not sure I would quite classify it as a hijacking, but I will explain what happened there and what we learned from that particular incident. Firstly, the interim trust anchor repository. Well, what is an interim trust anchor repository? This term is something that has been created very recently. So I'd be surprised if many of you have even heard of it or know what it means. Essentially, what is proposed by this repository is a mechanism to publish the DNSsec keys for top-level domains that currently implement DNSsec themselves. Today we have a situation where some top-level domains have implemented DNSsec in their zones. However, the root zone itself has not deployed DNSsec. The trust anchor repository is designed to be a stop-gap measure. It helps enable those that do use DNSsec today to use it more easily, but it is not designed to replace signing the root itself. In fact, the aim with the trust anchor repository is to decommission it once the root is actually signed itself. The concept of a trust anchor repository was voted on by the ICANN board in April 2008, just a couple of months ago. Based upon requests that we received from the community that having IANA maintain a trust anchor repository would be desirable. And I will give you a quick illustration of how DNSsec would work in reality if the root were signed and then explain how the interim trust anchor repository fits within that. I have an illustration here that shows a basic overview of how the DNS delegation tree sits and how validation would occur. I've highlighted in green those domains that have DNSsec enabled; in gray those that designed that do not have it enabled in this example. If we look on the right-hand, we have the Chinese test domains. We have example.test on the bottom right-hand side. We wanted to verify whether example.test had accurate data in the DNS. What would happen is there would be a verification process that would involve validating example.test against the dot test zone. Dot test could then be verified with the root zone. And then the root zone would then be verified by a computer that was performing DNSsec validation by comparing the certificate that was used to sign the root zone against a known good certificate that it kept within itself. That is known as a trust anchor, and that would be kept in the computer as a reference point. And that reference point is then used using cryptography to verify the validity of that chain from the domain under verification all the way up to the root. Because the root zone isn't signed today, the tree we have looks a bit more like this. We have a couple of top-level domains that are DNSsec secured, but we don't have security at the root zone. Seems to be a commotion at the back of the room. So if we wanted to verify example.test in this scenario, it wouldn't be possible to do it in the way I just illustrated because we don't have that central root zone secured. So, in fact, what we need to do is on the right-hand side, we need to have a list of the domains trusted to be a bit more expansive than just the root zone so that when we did a verification, we verify out but we would then need to compare the dot test domain with the dot test certificate on the computer. This is a slightly different verification model to the one that would happen in an ideal scenario. The question then arises is that instead of having a root key in the computers, you need to have a list of multiple keys for different top-level domains. How do you maintain that list? And this is where the trust anchor repository comes in. By using the trust anchor repository, it provides a list of top-level domain keys. This can then be used, I wouldn't say easily, but more simply than the current scenario to populate DNSsec validators with keys. So the registry proposal that we're working on is inspired by a set of recommendations that were provided to us by the RIPE DNS working group. I won't go into technical detail, but we support different types of DNSsec signing. And we're publishing the DNS trust anchor repository in a number of different formats. We will have a Web site that lists the keys there. More importantly, we'll provide a couple of different formats that will be suitable for computer software to read in. It should work with major software implementations, but it comes with a caveat, which is that we do not want to encourage implementors to custom develop their software to accommodate a trust anchor repository. That seems to be counterproductive given that this is just an interim step towards root zone signing. We want, when the root is signed, for this particular service to disappear. And if there is a lot of software relying on it existing, that's not a good outcome. So we've been encouraging an approach that does not require the trust anchor repository to exist beyond its lifetime. The acceptance model for these DNSsec keys, TLD operators can submit their DNSsec keys to us via Web form. We can perform an inDNS validation that that's accurate and the key is correct. We will not list the key until it's been correctly validated with technical verification. We also required that the administrative and technical contacts for the domain consent the listing, much the same way as we require approval of regular root zone changes today. And the revocation process is pretty much the same but without a technical test. We would require the administrative and technical contacts to consent. Exit strategy is very important. As we said, this is interim, we put the "I" in the name to emphasize that fact. The aim is that once the root is signed, some days after that, which will be declared in advance, probably 30 or 60 days, the service will cease to function. Limitations of the service is that we will only provide the service for top-level domains, the concept of a trust anchor repository isn't technically limited to top-level domains. If Google.com signed their zone and dot com wasn't signed, theoretically Google.com could provide a trust anchor to a trust anchor repository. But we are constraining the use of the trust anchor repository just to top-level domains. Why are we doing this? In essence because there's interest from the community in us doing so. Those that are experimenting or using DNSsec right now would like the root zone to be signed but in absence of that, having the trust anchor repository is a useful thing to have. I won't go into the many details, but there is a lot of political issues that inhibit deployment of DNSsec. And that's what my colleague, Richard, is working on full-time, is working through those issues as he mentioned. IANA has an operational test bed for some time. Our aim is to be ready to sign the root zone at the time when it becomes possible to do so. But until then, having the trust anchor repository is designed to assist early adopters that want to use the technology until the root is signed. That's the trust anchor repository. Our next topic of the day is root zone management software. I think Olivier said a lot of what I would have wanted to say, so I can be fairly brief. Just to recap for those that aren't familiar with the project, the aim here is to develop a piece of software to help automate the work flow of a root zone change request; so helping assist a process of accepting requests, processing them and implementing them. A requirement of the project was to support all the existing methods of root zone management. You will be able to continue interacting with IANA much the same way as you do today. We'll also have a new Web-based interface management that will allow you to submit changes, perform technical checks online, to review the progress of your change and so forth. The reason why this project was begun was really driven by the ccTLD community. And I know this quite well because, I guess, I was sitting on the other side of this desk back there when I was working at CENTR. And this is certainly very much an active interest for us to have IANA performing in a very effective and functional way. Back then IANA was quite slow -- that's probably an understatement, but quite slow at performing root zone changes. And it was seen from the ccTLD community that having automated software would go a long way to improving the performance of IANA. As it turns out, IANA's performance, I think, has improved quite substantially irregardless of this project. There were issues with IANA, but I think those issues have been, for the most part, rectified. But there's still reasons to implement this software even though the real driving reason has already been solved. That includes reducing some tedious manual processing that's done by ICANN staff right now, eliminating risks of introducing errors caused by reentering data manually within the process and also that increased transparency so that any TLD operator that's making a change can go into the system, see the exact status of their request, see what it's waiting on and so forth. The software we're using has been custom developed. It's been custom developed with the assistance of the dot pl registry. And it is based on a prototype that was developed by the CENTR community. The current issues facing the deployment of this software right now, this software is, by and large, developed. We're tidying up the interface, fixing bugs, but the work flow is more or less done. To implement the software as was mentioned a little earlier will likely require a contract amendment with the U.S. Department of Commerce. We're working with them to identify how that would work. Recently, we've been impacted by some key personnel changes at the U.S. Department of Commerce. This has resulted in a fairly different requirement from them on how we get this new system certified for implementation. We've now come to an understanding about what that process for implementation will be and we're working on developing a proposal to the U.S. Department of Commerce to allow us to implement the software and we're working with VeriSign on that, given that they have a fairly central role in it as well, in that this project also involves changing the interface between us and VeriSign. So on the testing, Olivier really spoke to much of what I wanted to say, but we're working with TLD operators on experimental testing. That was the first phase. The aim there was to try various scenarios of changing contacts, changing nameservers and so forth, supplying known bad information that would foul certain tests, making sure those tests accurately caught those particular problems. The focus now is moving to what's called "parallel operations." The aim there is to continue doing our manual processing as we do today, but at the exact same time, use the automated work flow system as well, go through the whole process every time we do a request, a real production request, and make sure that what comes out the other end of both processes match. By doing this, and doing this over several months, being comfortable that both systems are working the same way, we can then get a level of confidence that we can then turn the root zone management software into the primary interface, and then we can phase out manual processing altogether. So that's my update on root zone management software, and then just for my final topic -- and I'm aware that we're running low on time -- in November last year, ICANN renumbered the "L" root service which it runs, and this was the start of a set of events that I think it's worth reporting to the community, even though it's not precisely related to IANA. IANA is responsible for the contents of the root zone but not necessarily the publication of it through the root servers, but obviously there's some overlap there, so I think it's worthwhile that we raise this. Now, just going back a little bit in history, the "L" root server, originally it was run by the University of Southern California. It predates ICANN. It actually sits in a set of IP addresses that are set aside for Internet peering points, so-called exchange points. The block designated for exchange points is -- starts with 198.32, and for historical reasons the "L" root service was placed within this block. Back then, root zones were quite closely linked to exchange points, and I'm sure there was some good logic for that particular choice of IP address at the time. This numbering took place prior to ICANN's existence, and then ICANN took over the service after some years. In last year, we started a project to move the "L" root service to a much more robust anycast-based service. All semblance of the "L" root service being connected to the building that we're in, which is shared with the University of Southern California, ended. The "L" root service is now completely distinct and as part of that, we obtained a new IP address for the service. In liaison with the community and the root zone committee, "L" was moved to this new IP address on the 1st of November, during the Los Angeles ICANN meeting, and at the time ICANN announced that it would continue service on the old IP address for a minimum of 6 months. After that six months had expired, on the 2nd of May, ICANN discontinued service, and then I guess much -- to much of the community's surprise, or at least the community that was observing these kind of things, the old IP address continued to provide root zone service. It's probably important to point out at this stage that the data that was being served from the old IP address always matched what was in the root zone, so it wasn't a case that there was wrong data being served on the old IP address, but it was continuing service even though ICANN had pulled the plug on its server, which seems a bit strange, although, you know, it could be useful in some circumstances. So what happened? Well, once -- once this was observed, once this was reported and we have some internal reporting, our services that triggered raised eyebrows fairly quickly, and network operator lists also noticed fairly quickly as well, we performed an investigation. Our investigation essentially concluded that our EP.net company that is now the custodian of the -- that exchange point address block entered into an agreement with community DNS to provide root service on the old "L" root IP address. ICANN was not aware of this at all, nor was the root operator community, and I think the general community at large wasn't aware of this either. And whilst it was arguably within the rights of EP.net as a company to do so, because they had the delegation of the sort of master IP address block that the "L" root sat in, we believe that it wasn't in the best interests of the community to take this action without consultation. So lessons to be learned from this particular incident? There are secure routing technologies that are being considered that have been devised sometime but not widely implemented that would not have helped this case, I guess is my point. There was an incident a few months ago where YouTube was hijacked. That kind of instance would have been helped by this technology, but this particular instance wouldn't, because the IP address chain of custody was correct. The organization that was reported to be responsible for this IP address authorized the service so there's no reason to believe that this kind of technology would have assisted. It does highlight an issue that is somewhat unique to root servers. The difference between root servers and other operators is that if you change the IP address of your nameservers, you'd simply need to report them to us, we update the root zone, it gets reflected around the world. However, when we change the IP address of the authorities for root servers, those IP addresses are hard-coded in many different computers around the world, and there is an extended period of time that those old IP addresses are kept in those configurations. The third point I would make is that it's rather disappointing, as I mentioned, that the community wasn't engaged by those involved in implementing this process, that no clear notice was provided. And whilst there was no negative effect on the community that this was done, as I mentioned before the data that was being served was being correct, it does raise concerns about what happens if it wasn't the correct data, what happens if someone provided root service on an old IP address and were providing incorrect results, leading to an incorrect server. So these are all issues that are now being considered by RSSAC, by SSAC, and so forth. There will certainly be a lot of discussion, moving forward, on what the implications of this are. But I thought I'd raise it to your attention, and if it interests you, we have a blog post that goes into more detail available on our Web site, and certainly I'm happy to talk to people about it more. So there are the three issues I wanted to raise. I hope they've been useful. >>OLIVIER GUILLARD: I'm just aware that for logistical reasons, we should stop now. Are there very -- critical questions now? >>CHRIS DISSPAIN: No. >>OLIVIER GUILLARD: No. Nice. [Laughter] >>OLIVIER GUILLARD: Good. So we'll go to lunch and maybe we'll -- >>PATRICIO POBLETE: Yeah. I have the information about the lunch. The lunch will be at the Giacometti room on Level B. Margarita will be at the door handing out tickets right now. Make sure to get a ticket because you won't be able to get lunch without a ticket, and -- [Laughter] >>PATRICIO POBLETE: Okay. And get your tickets for yourselves. We only have tickets for people in the room. It's a sponsored lunch by Afilias, and be sure to come back here at quarter to 2:00 I guess -- >>OLIVIER GUILLARD: They provided the watch. If you have questions to Kim and IANA, of course they are around, so -- and they are open at any time. They are nice guys. >>KIM DAVIES: Thank you very much. [Break] >>CHRIS DISSPAIN: We're going to get started in a couple of minutes, everybody. Sorry for the delay. Good afternoon, ladies and gentlemen. People are on their way back but we need to get started. Your lunch was provided for you by Afilias, and Roland is here to do a short update on Afilias. There's a price to pay for every lunch. [Laughter] >>ROLAND LA PLANTE: Thank you very much, Chris. >>CHRIS DISSPAIN: I say that every time. I think I say that every time. I've got to stop doing that. >>ROLAND LA PLANTE: Well, I hope you all enjoyed the lunch. It looked like everybody actually got lunch, which was great, because it was a pretty big crowd, so I'm glad that worked out. I just wanted to take a couple of minutes this morning to update you on some things that we've been looking at at Afilias, and of course to do the sales part of the presentation as well. When you look at the overall market now for domains, I know you've probably all seen the domain brief. This is data that's a couple of more months along from the domain brief that VeriSign publishes and we use more or less the same statistics. But what we see now is that the total market exceeds 166 million registrations, and you can see the two segments here. Both ccTLDs and gTLDs are growing. And they have -- of course they have -- they've both been growing for quite a while but there's some interesting dynamics that we noticed that I think you'd be interested in. Overall, you know, we've all heard the rumors, you know, things are slowing down. In fact, things are slowing down. We're seeing a change in growth rates from the 30% and higher rates of about 18 months ago or so. These are all month-to-month growth versus the same-month-year-ago. So you can see a pretty interesting trend here. The business overall is continuing to grow at about 20% now. It's growing slower than it has before, but it's growing nevertheless. And I think even though there's an economic slow-down worldwide, the dynamics of the Internet are such that I think we can expect it to continue to grow, although probably at a lower rate. One of the interesting statistics we looked at is the rate of growth of ccTLDs versus gTLDs when you separate them out, and this is based on zooknic data but if you take a look at the same data we looked at here but split it between gTLDs and ccTLDs, you see that the gTLDs are the red line here. They have exceeded the growth rate of ccTLDs for quite a while but back in July of last year, that started to switch, with a decrease in growth rate for gTLDs down to about 15%, and a continued acceleration of the growth of ccTLDs that are up in the 30% range. With a little bit of a decline just recently. Now, some of that is due to China, of course, because China's put on a large number of domains recently, behind a pretty aggressive pricing strategy, but even if you take China out -- well, I covered this. Even if you take China out, you see the China line is at the very bottom here, CN. The red line is cc's without China, and the blue line is ccTLDs in total. So when you saw the 30% growth rate that gets ccTLDs in total up to about 63 million registrations, you know, while some of that growth was China, certainly not all of it, and there continues to be underlying very solid growth in the rest of the ccTLDs put together. But I thought you'd find that pretty interesting because I think it gives you a good sense of the kind of a market that you're competing in now. We also see, as a result of the increasing growth rates, that the ccTLD's share of the market has actually returned to about 38%, which is where it was back in September of 2004. So I thought that was also a good sign, because it's been going up for the last 12 months or so, total share of the market. Now, another interesting thing we looked at was the ccTLDs in the secondary markets. These are the auction markets that none of us as registries actually participate in, but I think are a good measure of overall brand and franchise health, so if you take all the ccTLDs together -- and this is data that we get from the domain name journal. The domain name journal goes to all the auctions. It's a guy named Ron Jackson. He's very expert in the space -- in the whole domaining space, and he captures probably roughly 50% of all the auction secondary sales that happen in the marketplace. He doesn't get the private sales, but he gets all the ones that are made public. And when you look at the ccTLD monthly dollar sales -- that is, ccTLDs that are on the secondary market on a month-to-month basis -- you can see that this number, while it's a little bit spikey month-to-month, it's in the million dollar plus range and it's been -- and it's been going up since the early part of 2007. So there's a lot more action now in the auction segment of the market with ccTLDs than there has been historically. But it seems to be losing share. Even though the dollar volume is going up pretty significantly, ccTLDs are actually losing share in the auction market, and if you look at the share of cc's of the total, it's gone from about 22.8% back in 2003, when we had about four months' worth of data, down to about 8% in 2008. So while the dollar numbers look pretty good, the overall market in the secondary area has been growing significantly faster. So the percent of the business that is being done in ccTLDs, as opposed to the gTLDs -- and gTLDs in the secondary market is basically com. Nothing else really sells. You get a few nets and orgs and so forth but that's pretty much it. Okay. Levers and strategies, things that can help to build your business as a big robust home market, extendible positioning like TV, WS, and ME. ME is coming out now. ME has done the -- as you know, I think Zeljko is here, and some other people from Montenegro are here. ME is just in the process of rolling out. The sunrise is done. It's in the middle of land rush now. Land rush will wrap up on the 26th of this month and then we'll go to real-time registrations. Other levers are competitive pricing, policies that encourage use and not abuse. Obviously good technology, tapping the registrars with distribution, and doing some marketing and PR. The Afilias part of this is, we're now supporting 15 different domains: Info, org, mobi, asia, aero in the gTLD space and ten different country codes. All of this -- all of these pieces of business have grown pretty significantly since we started supporting them and we continue to look for -- to more business and certainly if we can help you, we'd love to. The reason for this is reliability. We have a very reliable system. We guarantee a hundred percent DNS availability now. We've recently built out our own DNS system, and that's working quite well. We do continuous near real-time DNS updating. We have a high availability registry system. We provide 24/7 tech support, so forth and so on. We've also done a lot of work enhancing security for our country code TLDs. Because we support 15 different TLDs, we see a lot more -- a lot more different attack vectors, a lot more different exploits than someone who is simply managing one TLD, and we're -- we've been able to do some analysis recently that helps us understand better about how do attacks start to materialize, how phishing is done. We had a report of one phishing domain in dot info and by looking at the use of IP addresses, the fast switching of IP addresses, the contact information for that particular domain, we found that it was not just one domain, it was a network of 10,000 dot infos that were associated with this phishing attack and we were able to take all 10,000 of them off the Internet. You know, historically we would have only taken the one down that we got the report on, but by doing some analysis that came from our ability to see across these different domains, we were able to take down what was the substantial part of an entire network. Of course nothing is bulletproof but that was a good -- we thought that was a good save. So that's the phishing stuff. We're also linked up to the various CERTs, and if -- you know, we'd obviously like to have a relationship with your cert as well. I'm sure you're talking with them too. We talk about excellence in DNS with these five items: Stability, diversity, security, transparency and speed. This is the kind of network we've built out now for ourselves and it has been deployed on behalf of all the cc's and the other domains that we support. Availability through the registrar system. We're doing business now with over 400 registrars. These guys do basically all the business on the planet. You can see the ones here that are in the top. We put continuous pressure against improving the distribution for each of the cc's we support, and clearly we do that for you as well. So consider Afilias, please, if you're thinking about changing your model. If you want to upgrade your technology. We'd like to keep coming and buying lunch and entertaining you with these marvelous slides and we'd love to do business with you as well. [Laughter] >>ROLAND LA PLANTE: So I will leave it at that. Thank you very much. [Applause] >>CHRIS DISSPAIN: Thank you, Roland. No memory sticks this time or gifts of any description? >>ROLAND LA PLANTE: I -- we bought launch in Paris! [Laughter] >>ROLAND LA PLANTE: We'll let it go at that. [Laughter] >>CHRIS DISSPAIN: Thank you very much. Olivier, you want to take your slides from the -- your IANA working group before we start the ccTLD updates? For those of you who are doing a ccTLD update, Mathieu, Slobodan, and Jian -- who I don't think is in the room -- we'll see how we do with time but if we can make it sort of 15 minutes-ish, that would be really excellent, because we might -- otherwise we might run out of time. >>OLIVIER GUILLARD: Here is the IANA session. [Laughter] >>OLIVIER GUILLARD: Since I'm plugging the -- my computer, I was wondering if there were any -- because we didn't have time, any important things or inputs from this morning's presentations. Any questions? Yes? No? Okay. >>CHRIS DISSPAIN: Seemingly no. >>OLIVIER GUILLARD: Good. >>CHRIS DISSPAIN: What was it they said again this morning? Any idea? Anyone remember? [Laughter] >>OLIVIER GUILLARD: Okay. Just to close the IANA session, I wanted to say a couple of words but I will be very quick. On the IANA working group work plan, so coming from the current IANA challenges that they have, but they are not here so -- the current challenges that the IANA working group has identified as important for IANA with the DNS management, and also taking into account the current activities of the IANA working group and that you saw this morning, you may recall that the new IANA working group charter that we have adopted in -- last time in New Delhi foresees a work plan to be established and published at the beginning of each calendar year for the IANA working group. So a draft for the IANA working group work plan has been prepared in the group, and it was published and submitted to you, to cc's, for consultation at the beginning of June, after a talk in the council. So the work plan is also published on the ccNSO IANA working group Web site. It's presented in two documents. The first one describes IANA's context and introduces the IANA working group activities, of course taking into account the goal and the scope of the working group. And the second document that proposes a concrete time line for 2009, okay? So you have those documents that are accessible from the IANA section -- the IANA working group section on the IANA -- on the ccNSO Web site. Both documents are only four pages. It's very short, okay? Something that members asked me to highlight, it has to be stressed that ccNSO IANA working group participation is based on volunteering and only involves voluntary work. And of course the progress of the group may be subject to the responsiveness of stakeholders that are not members of the group, so the milestones that you will find in the time line are indication. We are doing our best to reach those milestones, but we can't commit on fixed deadline, so it's targeted dates for outcome. We can't say that we will be able to provide input on signing the root to the council over the next meeting, for example. We would have liked to provide so now. Formally, we couldn't. So this is a draft -- okay? -- so this is time for you to provide your comments and view. Please do so. Please! If you have any advices, comments, inputs, contact me or contact the group. The proposed time line is -- I will not propose the council to approve this work plan now, over the Paris meeting, because the charter foresees -- foresees the time line to be established for each calendar year so it's for next year. I think it would be okay if we approve it in Cairo, so it leaves all the time to add additional comments of things that you would see as possibly being undertaken by the working group. Some pending things that I feel are not properly maybe addressed in the current document and for which I would like to have advices: Continuity of the working group. That's one. Another problem that we have -- and it's like, as a report, the overload of the work which is due to internal rules to implement the membership protocol and everything. And there are also some identified areas that would need outcome because we have been told things like service level, for example, that are identified as requiring input from the working group but that have no concrete actions in the time lines. So if you have suggestions for that, it would be helpful. Yep. That's it. Thank you. >>CHRIS DISSPAIN: Thanks, Olivier. André? >>ONDREJ FILIP: First of all, I would like to thank you, Olivier. I think you and the IANA working group is making marvelous work, and I have just two comments. >>OLIVIER GUILLARD: Thank you. >>ONDREJ FILIP: First it's related to RZM. I just would like to see the answers from IANA to the questions you raised. I think it's -- we see that we had no opportunity to comment on the design of the software, so we are doing a testing, but if we raise some issue that we would like to change the design, we've got the answer that it's not subject of testing and nothing happens, so I would like really to -- IANA to take all inputs seriously at IANA. And another issue is the DNSsec. Actually, Chris was true when he asked me in the morning to comment on something what happened in NSEC, and there was two issues. One of them was that there was -- of course there's obviously some phishing problems, talking about phishing, and next issue was the -- that some DNS operators changed the negative response if the DNS responds that the domain doesn't exist. Some operators change this response, and it leads the users to some websites, and I think for both these issues, the DNSsec would be very helpful, so I would like really to get the answers to the DNS questions as fast as possible, because I think it's very helpful for all the community. >>OLIVIER GUILLARD: Thank you. On the first one, this is an ongoing process with the testing. I have -- it's not -- to be honest with you -- perfectly clear if the testing is stopped forever. What I understood from this morning is that now they are going to propose the interface in parallel with the old way to update all data. So, yeah, this question -- the question of the specification of the software has been raised. My understanding is that the software is helpful -- very helpful for IANA internally to deal with the internal work, but of course after this meeting I will raise again this problem of what does it respond really to and document the fact that it really increases the performance of IANA. That's one. For the second one, on DNSsec, the working group has posted a first part of a document. We haven't yet provided to the ccNSO our final recommendation or input, if any, so I think between now and -- this is -- yeah. We are going to relaunch this, and this is still time to bring things in the working group for us to raise it and maybe to echo that in our final recommendation, yeah. So I take that. Does that respond to your question? >>ONDREJ FILIP: [Speaker is off microphone] >>OLIVIER GUILLARD: Thank you. >>CHRIS DISSPAIN: Thank you. Thanks, Olivier. Hiro has a question. >>HIRO HOTTA: Let's do the IDN TLD. I would like to see -- that was the plan including cooperation with and helping IANA in enhancing IANA systems such as its registry or the WHOIS service to be able to handle IDN TLDs. [inaudible] >>OLIVIER GUILLARD: Yeah. I'm not sure if -- I will ask also Chris about the process for introducing IDN. This has not been discussed really within the working group about the ability of IANA to deal with IDNs and how they will deal with it. The question has been raised once or twice informally about the WHOIS service and would IANA be able to provide a full non-ASCII WHOIS service. And the response up to now is not really clear. I think they have many other things on the top of their head and they are probably waiting for more -- >>CHRIS DISSPAIN: A lot of the IANA issues that will arise in respect to IDNs. It is not just ccTLD and IDNs, it is gTLDs, too. Some of those things will have already been worked through with respect to the new gTLD implementation process. And I haven't read that in any detail yet, so I don't know whether it is covered or not. But, obviously, for IDNs, there will need to be some sort of implementation and the plan that IANA uses to introduce IDNs and to maintain them and make changes, et cetera. So I guess the answer is it has to be dealt with prior to the delegation of any IDNs and one thing that I suspect will happen is that IANA will work with the ccNSO IANA working group in respect to IDN ccTLD matters. >>OLIVIER GUILLARD: Just an additional comment from the IANA working group point of view. If you look at the timeline, you will see that there are activities that were raised or identified. I will see how to inform this even if formally -- I can tell you we have informal discussions, and we'll try to keep that on the timeline. But, currently, it sounds from an IANA point of view it is not on the top of -- they have many things to do. >>CHRIS DISSPAIN: Anyone else? Okay. Olivier, thank you very much. And I just really want to echo what Ondrej says about the amount of work that has been done. Thank you. [ applause ] So it is time for ccTLD updates. Can I ask Mathieu and Slobodan and Jian to come to the front of the room and make their presentations. Let's start with Mathieu. It is on Gabby's laptop, okay. Gabby is running back down the aisle again. Whichever one it is on, it needs to be plugged into the screen. So as has become traditional or semitraditional at these ccNSO meetings, we're going to have an update from three of our members, France, Serbia and China. Matheiu? >>MATHIEU WEILL: Thank you. I will be standing while speaking since everyone in the back of the room might have difficulty seeing people sitting here. So, first of all, let me welcome you to Paris. My name is Mathieu Weill. I am the chief executive of AfNIC, manager of dot fr and other various top-level domains related to the French territories. And since there is no such thing as a free meeting, you have to have the local host update and this is my turn after Roland, I thank very much for the lunch to give you the AfNIC update. Of course, I have too much information to provide you with in, like, 15 minutes. Is that right Chris? >>CHRIS DISSPAIN: Yeah. >>MATHIEU WEILL: So I will start early in my presentation. There will be more, I think, on the presentations that have been sent to Gabby already. And I will be happy to answer questions afterwards. Dot fr organization, we are managers of dot fr, dot re for Reunion Island; wf, Wallis and Futuna, in the Pacific; tf which you can see is in the south pole; pm and yt. So we're pretty much on all oceans. Although, only two of these top-level domains are open to registrations, dot fr and dot re. We are private sector, not-for-profit organization. We were founded back ten years ago by the French government, who is still in our board as you will see later. And we are a membership organization. Every stakeholder can become a member at national and international level. I will come back to this later. At this point in time, we have 43 employees and growing and we are located 40 kilometers out of Paris. The train station is right in front of the hotel, very convenient. And our budget is approximately 6 million Euros, closing in on 1.2 million domain names as we speak. This is our governance summed up in our board. On the left, you have elected members from the membership. There are two representatives from registrars, two from registrants usually associations representing users, business users or private users. And one representative from our college international, which is an organization I will come back to a later on. On the right in blue, our representatives that are not elected but appointed by -- three of them by different ministers of France and two of them by NVR, which is the National Institute for Computer Science, which is the organization that was previously in charge of dot fr ever since the '80s and then there is staff and chief executive and so on. We have -- our governance has sort of a timing -- very regular timing. We have once a year a general assembly -- it was last week -- for all members. At least twice a year, board of directors, usually more than that. And then we have consultative committees which are constituencies. That's what we would call them in ICANN. And those take place at least twice a year with registrars on the one side -- on one side and with users, registrants on the other side. We also have set up several working groups with registrars and sometimes with registrants as well. One of them is technical. For instance, we are working on EPP in this group right now. One of them is legal where we handle the way we manage the policies for dot fr. And the third is marketing and communications where we discuss joint actions promoting dot fr with our registrars. And then we organize workshops and seminars on specific projects. Our goals in organization, we are trying to excel in registry operations to provide an open, transparent and efficient government of our TLDs and to contribute to the development of the information society in France and at the international level. And that's where I would like to make a little aside for our college international. I know a members of this college are in the room. I can see a few faces. This is actually an initiative that's embedded in our own bylaws. International organizations can become members of AfNIC to join this college international and benefit from straining activities, joint projects we've developed jointly with ivory coast and Madagascar registry software, Open Source. It is called Codev-NIC and it is in operation with dot ci and we are thrilled there has recently been a transfer of this project software which happened without us knowing. That's, basically, our philosophy in this, is that the best actions that we could make is when the people who benefited the initial transfer transferred themselves, in turn, to others. This happened between ivory coast and Senegal in the last few months. And we only learned about it, like, after it was done. So that's perfect -- it is a perfect summary of what we are trying to achieve after this college international. So if you want contacts with them in the room, it's -- I can point you to the guilty members of the college international. Dot fr, it's an automated registration top-level domain, but there are still restrictions to registrations. You need to have a linguist literary be either a registered company in France or be an individual able to provide an address in France. There are several things, I will come back on the other interesting topics on this slide. Move on. Our core system, our main network site is in Saint Quentin, 40 kilometers out of Paris as I was saying. we are supporting IPv6 since 2003. We were among the first. Most of the infrastructure and software is internal -- is administered by internal staff and we also had two difficult but successful land rushes. One in 2004 when we removed the obligation to provide proof before registration and the second one in 2006 when we opened to individuals. And it went pretty smoothly on the technical level, which was, of course, a challenge. We have one Anycast name server at the moment, and the second one is in preparation with the second provider. But this has been told yesterday in the tech workshop by our chief operating officer and we have mirror sites. Some figures we've reached the 1 million domain names mark beginning of this year and as I was saying, we are closing in on 1.2 million right now. We enjoyed very big growth last year, plus 40% with prices starting below 5 Euros per registration per year. And as you can see the growth of the number of domain names managed was -- the trends were changed twice. Once in 2004, as I was saying, first land rush. And then the trend -- the growth rate is higher than before. And then in 2006, opening to individuals and, of course, there is a land rush and there is also a trend in growth that's much stronger than before. We register under the second level, and there are remains of third-level registrations but it is very, very little compared to the second level. This is, basically, saying the same thing, that you can see the two peaks that are the land rushes and then there are registration rate. This is the new registrations per months. We have a registrar-only distribution model. We don't interact with the end user. Prices have fallen sharply, as you can see on the graph on the top, since -- in 2002, it was 15 Euros per domain. And it fell regularly ever since 2004. And we have 1,000 registrars but among them -- the top 100 represent more than 90% of the domain names managed. So it might look like a very competitive market. It is still competitive, but it is actually concentrating right now. Government relations, important when you have government members in your board. The interesting point is that in early 2007, an executive order, we call it decret in French, was taken by government in order to -- which enables the government to launch RFPs, competitive processes for all French territory top-level domains. It is actually intended mainly to some top-level domains related to French territories which are not under government control whatsoever. But it is also concerns dot fr. So, of course, for us it is a big strategy priority, to say the least. This is still the preliminary phase. There is a public consultation going on for general directions on how to handle this RFP process and what should be policies for the future dot fr, or the future for dot gp for Guadalupe, for instance. It is interesting for you to note that the deadline for this consultation is today. You can all have a look at the Web site of the French government, telecom.gov.fr and answer before tonight. Thank you for your cooperation. I actually was sending AfNIC's answer a little earlier today. So it is a very good choice today. So this decret also introduces new rules related to domain registrations. Part of if is taking out rules that we were using in dot fr that had only the validity of contract-based rules into the law. As you may know, in France, if you are not into the law or any administrative order, then you are suspect of being some sort of illegal person. If you are not in the law, you are illegal. The way people hear about administration in France, so it is a good thing for dot fr that some of the rules were taken into administrative order. But it is also introducing new rules and extending protection on some public authorities and institutions' names. That's an issue because of the way you have to handle past registrations, for instance. And, finally, this new decret is conferring to AfNIC or ccTLD managers in France new powers to react to illicit registrations. And illicit is compared to this new rules. So this is also a big project for us to be able to address this -- to use these new powers without abusing them and, of course, it is a question of balance and we're working on this -- we've been working on this in the latest months. How long do you have? >>CHRIS DISSPAIN: Not long, couple minutes. >>MATHIEU WEILL: Won't have the current projects but you had some yesterday if you were at the tech workshop. >>CHRIS DISSPAIN: Any questions? >>DOTTY SPARKS de BLANC: I can't see over here, over here it is saying elicit registrations as if to solicit registrations. But are you saying illicit like i-l-l illegal? >>MATHIEU WEILL: It is registrations that violate the rules that are set up by this order. Sorry for the English. It is my French. >>CHRIS DISSPAIN: You do not need to apologize for your English. Any other questions? Okay. So thank you very much, Mathieu. [ applause ] Next we're going to hear from Slobodan. >>SLOBODAN MARKOVIC: Okay. Hello, everybody. I'm Slobodan and from the Serbian Registry of Internet Domain Names and we will first now see how the first 100 days of the registry went. The last time I spoke about this was in the CENTR meeting, not the previous one but the one before that. And it was only, I guess, two days before the launch of dot rs, so I'm glad it launched successfully without any technical problem which was really important for me personally (laughing) so luckily for all of us, we haven't had any hiccups or anything and the registrations are proceeding normally. So I will now say a few words about the registry. I will keep to the things you may already know. I will just highlight that the Serbian registry is a rather new organization. It was formed in 2000 -- it was initiated in 2006 but formally registered in early 2007. It is a non-for-profit fund and its members are different. Currently, there are around 40 members, mostly major I.P.s, telecos, not-for-profit organizations active in the ITCP policy area, academic institutions, et cetera. And the membership is, of course, open. There is a membership fee of around 150 Euros and membership is open only to Serbian legal entities. So to cut the long story short, we got our dot rs code in September 2006, submitted a request for delegation in March 2007. Dot rs game visible on the Internet last September, at the end of September. And we launched dot rs on March 10, 2008. So during November and December last year in January, the central registry accredited the first 27 registrars of dot rs domain names because all domain registrations are done exclusively through accredited registrars. And the launch date was set to March 10 at noon. Exactly ten days before the launch of dot rs new dot yu registrations were freezed. So it is not possible to register any more dot yu domain names and dot yu TLD is scheduled for removal from the root zone sometime after the end of September next year. So before, of course, launching dot rs, some domain names were reserved. There were three classes of reservations. The reservations of the first class were reservations for the registry itself. Second class reservations were reservations for government institutions like Serbia.rs, president.rs and that kind of stuff, around 1,000 names. And the third class of reservations were all names that were previously registered under dot yu. So all those names that were reserved in dot rs. All other names which were not reserved became immediately available for registration on March 10. So there was no sunrise phase -- classical sunrise phase. In the first six months, and that means in this period which will end on September 10, only the persons for who those registrations were made will be able to register those -- to activate those registrations. And I will give you some statistics. So today the figures are as follows. We have around 24,000 dot rs domain names in total. Half of it is directly under dot rs. And all other name spaces are much less. I have to mention that there is no limit on the number of domain names a registrant can own and physical persons, individuals, can also register domain names. So the final number of dot yu domains is around 40,000, but we think -- we estimated that nearly half of them are not active. And this is the current statistics on preregistrations. Activation of registrations for dot yu owners. And it shows that we are currently -- that some, around a quarter of dot yu domain names has already transitioned to dot rs. However, it may be that this number is actually half of those who are active. So we expect to have around 12,000 domain names by September, and those will be only -- dot yu owners who use their domain selectively who will register the equivalent dot rs domain name. The first domain name was Aleksandra in dot rs. I will show you this presentation. It is so cute. >>CHRIS DISSPAIN: Who does she know who got the first domain name? >>SLOBODAN MARKOVIC: She says she is almost 5 and her father registered the domain name and her mother is going to make a Web site and that she will tell more about herself later (laughing). So in short, 7,000 domain names were registered on the first day. 15,000 after one month and close to 25,000 after four months. And these are some of the plans for the near future. So this is to conclude the transition from dot yu to dot rs; to sunset dot yuTLD; to improve redundancy and robustness of the critical services; to improve registration information system for the registrars, meaning software; to improve internal and external communications with the stakeholder; and, of course, to promote the usage of the international domain name. So questions? Comments? >>CHRIS DISSPAIN: Anyone? Any questions for Slobodan? Hilde? >>HILDE THUNEM: [Speaker is off microphone] >>CHRIS DISSPAIN: Yes, that's right. >>HILDE THUNEM: I just have to ask the traditional, you know, domain name policy questions. >>SLOBODAN MARKOVIC: Okay. >>HILDE THUNEM: Is dot rs open to anyone or with a connection to Serbia? >>SLOBODAN MARKOVIC: The only limitation is that the administrative content has to be from Serbia. >>HILDE THUNEM: And you don't have to show any documentation for rights or something. >>SLOBODAN MARKOVIC: You have to prove that you are from Serbia, but that is -- you have an additional period of 30 days after registration to send some documents. >>HILDE THUNEM: Yeah. And you don't have to show that you have a trademark for the name you are registering. >>SLOBODAN MARKOVIC: No, no. >>HILDE THUNEM: No? >>SLOBODAN MARKOVIC: No, but there is of course a disputes resolution policy in place. >>HILDE THUNEM: Yes, exactly. The same as most of us then. I'm actually just thinking about the -- that you did not do the sunrise period, but in a way you can say that when you have dot YU, that you're moving registrations over from, that has, in fact, been an extended sunrise period where people have had the chance to discover about the Internet and actually protect their rights beforehand, so it wasn't that much of a need when you opened. >>SLOBODAN MARKOVIC: Exactly. And I have to stress that before, only legal entities could register dot YU domain names. >>HILDE THUNEM: Yeah. >>SLOBODAN MARKOVIC: So basically those were all domain names of the various companies, et cetera, so the community felt that there was no need for the sunrise period. I have to mention that there were some proposals from some of the members of the organizations to introduce, you know, a proper sunrise -- staged sunrise procedure, but in the end, it was felt that it was not necessary. >>HILDE THUNEM: Yeah. Did you have -- I mean, you opened sort after big bang on this day, this time, you're opening for registrations. >>SLOBODAN MARKOVIC: Yes. >>HILDE THUNEM: Did you have trouble with lots of applications hammering your servers or -- >>SLOBODAN MARKOVIC: No. Actually we introduced an artificial delay of one second per request, and there was -- >>HILDE THUNEM: Ah! >>SLOBODAN MARKOVIC: There was an additional limitation of only one IP address and one thread per accredited registrar. So basically, the one -- the registrars which had huge waiting lists of, I don't know, maybe 3,000 or 5,000 domain names, they could register them in some 15 or 20 minutes. So there was no stress. But there were some measures, you know, to prevent -- >>HILDE THUNEM: Yeah. And there was no registrars trying to circumvent those -- >>CHRIS DISSPAIN: As if they ever would! [Laughter] >>HILDE THUNEM: Talk to Roelof about that. >>SLOBODAN MARKOVIC: I expected all kinds of bad -- [Speaker is off microphone] >>SLOBODAN MARKOVIC: I expected all kinds of bad things and nasty stuff but I was amazed. You know, frankly speaking, that everyone was behaving normally. So we needed that, you know -- like, you know, kind of fate in the system. There was one accredited registrar who just for the sake of I don't know what requested logs from the first five minutes of registration, and we will provide them with these logs in due time, but no one actually complained, you know, about the effects of the first day of registration, so... >>CHRIS DISSPAIN: Thank you very much. Okay. >>SLOBODAN MARKOVIC: Thank you. Thank you for your attention. >>CHRIS DISSPAIN: Thanks, Slobodan. [Applause] >>CHRIS DISSPAIN: Okay. And now our final ccTLD update from Jian from dot cn, China. >>JIAN ZHANG: Hello, everyone. Good afternoon. I'm Jing Zhang from CNNIC. I'm going to give an update on CNNIC. First I'm going to talk about a little bit our new structure. Hi. Yeah. First, I'm going to talk about our new structure. Then I'm going to give an update on dot cn service. Next will be update on IDN. And last, I'm going to give update on Internet development in China. CNNIC restructured its organization in 2007 in line with CNNIC's strategic plan, and to better serve users, registrars around the world, international business development department was set up. The function of international business development department is to provide better service and to improve cooperation with overseas partners. Meanwhile, to further research and communication with other international organizations. So from this chart, you can see under "Director-General" right now we have ten departments and we have over 200 staffs. Next I'm going to give an update on dot cn service. At the present, besides second-level domain -- second-level CN, CNNIC provides with seven cert level ASCII dot CN and the 34 geographic names. The registration prices for those domains are all the same. So as per registration service, there are over 50 domestic registrars with their branch subdivisions, and the resellers in over 18 major cities in China, and more than 70 overseas registrars at 16 countries and regions. Altogether, they bring seamless and localized CN registration services to users around the world. Next chart is the category of dot cn. Second-level dot cn was opened for public registration on March 17th, 2003. According to the statistic of last month, second-level dot cn registration is over 7 million, make up 64% of total registration, and dot cn -- dot com dot cn is ranked second makeup of 28%. Here is a chart that shows the growth of the dot cn name. As we can see from this chart, CN domain name experienced tremendous growth starting from 2005, all the way through 2006 and 2007. In 2005, CN registration exceeded 1 million. At the end of 2006, the registration has reached 1.8 million, while at the end of 2007 the number was 9 million. Thanks to experience of CN domain names for ¥1 campaign, the registration has seen a big jump. Since the promotion launched we receive 1.8 million new registrations in March alone. In less than six months, the total registration has been tripled, so now we can see where over 11 million at the end of May. So you may start to wondering why we grow so fast. There are several reasons, I think. First is tremendous growth of Internet industry in China. Also, the enhanced recognition of dot cn. And also, our effective promotions of our dot cn. Internet industry in China has seen a high-speed growth in 2007. The whole market value reached 40.7 billion RMB. That's close to -- almost to 7 billion U.S. dollars. With a growth rate of almost 40% in 2007. In the meanwhile, perfused Internet application, like blogs, RSS, video and social networking Web sites, plus e-commerce has boosted the use and application of Internet. The development of the Chinese Internet industry spurred the demands of dot cn domain name and the profound growth of dot cn registration. Also, CNNIC launched nationwide advertising and promotion activities in 2009. CNNIC went around 84 major cities in China as well as 20 other countries to promote CN domain names. CNNIC also takes advantage of commercial advertisements, including local newspapers, TV commercials, and online advertisement to publicize the CN domain names. 2006 and 2007 together, the total number of the advertisement of different kinds reached 62 times. Over 2,000 promotional articles on CN were published on national media and local media. The publicity greatly raised the awareness of dot cn among the public. Many prestigious entities in China has adapted dot cn as the main domain name for their Web site. For instance, Beijing2008.cn was adopted as Beijing 2008 Olympic games official Web site. Another reason is -- another reason of fast growth is our huge price drop. In 2002, the price for a dot cn domain name was 300, while in January 2007, the price was slashed to ¥45, and in March 2007, CNNIC launched the experience dot cn for YU campaign. The price dropped to Ground Zero so first-year registration only cost us ¥1. This is near 50 cents in U.S. dollars. Next, I'm going to talk about our improved service. We have this improved registry service. We launch three new teams and also we have this self-discipline convention. Also, we have improved customer service, we have 24-by-7 customer support call center, and we also have this promise. Our registration service is up to 99.87% and the WHOIS service is up to 99.99%, and the resolution service is up all the time. So as a frontrunner of all these activities, the registry operations department went through a very busy year last year, to adapt to the fast growth demand. The department went through a series of reorganizations. In addition to three existing teams -- before, we have the domain name team, channel team and IP team -- new three teams named operation team, registrar regulating team and the rural development team was set up to handle the fast development of industry. While the rapid growth of CN registration and development of industry call on improving the registry service and the healthy Internet environment is going up, as a regulator of domain name industry CNNIC called on industry to purify the Internet environment and to improve self-discipline. In response to the call of CNNIC, domestic registrars signed a self-discipline convention in July 2007, promised better service and honest operation, and CNNIC was elected as the supervisor on this convention. To date, 67 notices of breach to convention were published by CNNIC. This greatly improves the Internet industry environment. Next, I'm going to talk about update on IDN. Although CDN has been in existence for many years, the booming of using the IDN comes after IE7 has started supporting IDN. Since IE is still the dominant Web browser in the market, here is -- here is a demonstration of IDN at work. So official ticketing Web site of the Beijing Olympic games is using the domain name (non-English word or phrase) which means Olympic ticketing dot cn. Also when Chinese server input, if they input Chinese (non-English word or phrase), named Olympic ticketing dot China, as a test bed for CDN by CNNIC, the browser also will direct a query to the same IP. The domain name brought -- the IDN domain name brought that Web site enormous task during the three phases of ticket open selling. So you may not be able to see clearly the front page is the IDN.CDN Web site. It's (non-English word or phrase) dot CN, and the back is IDN.CN is (non-English word or phrase).(non-English word or phrase) so that's purely in Chinese. You've got to have a plug-in to run this Web site. From those data, we can foresee that when full IDN is implemented, it will greatly help non-English speaker surfing the Web site. EAI. EAI is e-mail address internationalization. Represent once e-mail address in characters or letters other than ASCII. Here you can see there is an e-mail address totally in Chinese. EAI standards in 2005 CNNIC JPRS and NIDA jointly submitted a draft on EAI. March 2006, IETF set up EAI working group with Dr. Li Xiaodong from CNNIC as come co-chair. March of 2008, the drafting of EAI standard enters the final stage. CDNC. That's something we have done on IDN research. CDNC is standard for Chinese domain names consortium. It's a nonprofit organization. Its main function is to coordinate members, research, and the implementation practice on Chinese domain name. Established in May 2000 as an -- actually, members including CNNIC, TWNIC, Hong Kong NIC, MONIC and SGNIC. It was collective effort in the consultation. CDNC members made a contribution to the CDN standards like RFC 3743, RFC 4713. Currently, CDNC members are working on EAI. And last, I'm going to give update on Internet development in China. This page lists several reports CNNIC conducted. CNNIC conduct semiannual survey report on China Internet development. Also, conduct other survey reports below. Those are some data from the survey. From this chart, you can see by December 2007, the total of netizens in China has increased to 210 million, with an increase of 73 million as compared with 2006. So annual growth rate is like 53%. The rapid growing rural netizen become important part of the growth. Out of 73 million new netizens, 40% comes from rural area, with growth rate of over -- over 100%. This is -- this chart shows Internet penetration in China. Although the Internet development -- develop rapidly in China, the current 16% of Internet penetration rate is still 3% points lower than the average global standard of 19%, and observes a big gap with well-developed countries in the Internet. The Internet penetration rate of neighboring countries, like Japan, Korea, and Russia are all higher than the penetration rate in China. This chart shows broadband user, some data on broadband user. we can see from the chart, green column is broadband. There is a boom of broadband user in recent years. By December 2007, the number of broadband netizens has reached 163 million, being 77% of total netizens, and an increase of 58 -- 59 millions as compared with year 2006. The rapid growth of broadband is basis for rapid expansion and development of various Internet application. Also, on this chart, the blue one is mobile, mobile data. Currently 50 -- 50 million users has also chosen to access Internet via mobile phone, apart from other Internet access being one-fourth of the total netizens. We have a booth outside. If you're interested, please go to booth 9. You can pick up a hard copy of our 21st survey report on the Internet development in China. Also, you can refer to our C this. Nick Web site to download the electronic copy. And last -- [Laughter] >>CHRIS DISSPAIN: You couldn't resist, could you. [Laughter] >>JIAN ZHANG: Beijing is hosting the 2008 Olympic games. Those are some car stickers that's also available in our booth, so feel free to stop by to pick them up. Welcome to Beijing. [Speaking in a non-English language] Thank you. >>CHRIS DISSPAIN: So things are going quite well in China then. [Applause] >>CHRIS DISSPAIN: You seem to be experiencing sort of reasonable growth. [Laughter] >>CHRIS DISSPAIN: Are there any questions for Jian? Patricio. >>PATRICIO POBLETE: Hi. How about the voluntary code of self-discipline adopted by registrars, I understand? I find it a bit surprising the large number of violations that you have posed, considering that it is a voluntary code. Could you elaborate a little bit about what are the most common violations that you detect? >>JIAN ZHANG: Like improper way to sell. Like the spam. That's the most common thing they complain for. Did I answer your question. >>CHRIS DISSPAIN: Yeah. >>JIAN ZHANG: Yeah. >>CHRIS DISSPAIN: No, but I think certainly I know -- I know that there have been registrars that have tried to sell groups of -- groups of names, Hong Kong and China names against the code. That's what you mean, isn't it? They sell them -- they're using bad methods to sell? >>JIAN ZHANG: Yes. >>CHRIS DISSPAIN: Yes. >>JIAN ZHANG: Yes. >>CHRIS DISSPAIN: Okay. >>DANNY AERTS: Hi. My name is Danny Aerts. Do you have some information about how the 10 million new domains are used? Because if I look at your statistics, roughly a year ago only 1.1 million Web sites were in China. How are the domains used? >>JIAN ZHANG: Yeah. I couldn't deny some of them -- because the price is almost free, you know, some of them are used for investment. >>CHRIS DISSPAIN: Yeah. And -- yeah. >>JIAN ZHANG: Not all of them are in use. You are correct. >>CHRIS DISSPAIN: Anyone else? Dotty. >>DOTTY PARKS de BLANC: I'm not sure you can address this, but certainly we hear a lot about a lot of control by the government over the Internet and its content. Are you able to say anything about that? [Laughter] >>JIAN ZHANG: That's nothing to do -- >>CHRIS DISSPAIN: Are you able to say anything about the control of your government over the content -- >>DOTTY PARKS de BLANC: Maybe. [Laughter] >>CHRIS DISSPAIN: Yeah, the Virgin Islands government, exactly. I think we might just leave that alone. >>JIAN ZHANG: We are not governed, so -- >>CHRIS DISSPAIN: So they are not governed. >>JIAN ZHANG: We are not a regulator, so... >>CHRIS DISSPAIN: And that's exactly the response I would have given if you'd asked me about Australia. We're not government, we don't regulate content. >>JIAN ZHANG: No. That's not our job. [Laughter] >>CHRIS DISSPAIN: Thank you -- oh, sorry, Roelof, were you stretching or did you have a question? You had a question. Okay. Last one, because then we need to move on. >>ROELOF MEIJER: Can you tell us a bit about how the registry managed to, without problems, grow in such a very small -- short period from, what was it, a million registrations to 11 million? I mean, you must have been changing all your systems and applications and whatever. That's quite a job, I think. >>JIAN ZHANG: Yeah. As I said in my presentation, we really had some -- we really did some hard work on it, because of the fast growth. We provide more services. We promoted. We set up new teams to handle all the issues. But obviously we handle it well, so... >>CHRIS DISSPAIN: Okay. Please join us in -- me in thanking Jian for her presentation. [Applause] >>CHRIS DISSPAIN: The next item on the agenda is a brief report from gabby on the phishing survey results. Sorry, the anti-phishing survey results. [Laughter] [Speaker is off microphone] >>CHRIS DISSPAIN: Yeah, I know. >>GABRIELLA SCHITTEK: Hello again. This time I will speak about the phishing survey -- or anti-phishing survey, whatever you prefer to call it. Before I start, I must say that if you remember what Hilde said this morning about charts and percentages and lying and so on, it puts me in a really bad position because mine is full of charts and percentages. So I'm really sorry. Also, I will skip quite a many slides because the session is pretty short and we are three speakers, but we will have the report up in July. So some background information. The survey on this phishing issue was initiated by the ccNSO Council during their meeting in Los Angeles. They suggested that the ccNSO should try to find out what the community knows about phishing, how affected they are and if they expect us to do anything about that. The question was drafted by dot mx, dot jp, the anti-phishing working group and ICANN coordinated it all and it was then launched at the end of February. We sent it to all e-mail lists we had available. In total, we had 28 replies. So my first chart, are you aware of any phishing activities under your domain names? So a better half of the respondents said they are aware of phishing activities. Interestingly, only 6% said that they don't consider them being large scale. And this 6% actually equals to one respondent. So of all respondents, only one considered it being large scale. And we asked where do you get information for these phishing incidents? This was a question are you could make many options. But mostly mention that the information came from affected companies. That was far before the actual anti-phishing agencies. We had some interesting replies that could be from academic research or law firms, but actually also from sources such as spam to the registry. Then we asked whether there were any policies in place to suspend domain names used for phishing purposes. Most said no, only 1/4 had specific policies in place. Those who said no, they said "no, but we have other policies or we have national law under which phishing activities actually are handled." And we asked if you don't have policies in place why. Again, this was a question we could tick many options but mostly mentioned was because there was no phishing problem or in the country they don't consider it being big enough. Secondly, many said no because it has to do with content. And this also kind of related to some other replies I got such as law enforcement agencies or government agencies should deal with this. This is kind of a bit related. But many just hadn't thought of it because they hadn't had any cases yet. Then we asked who decides that a domain name has been used for phishing. Almost half replied a court or a government agency. But interestingly 1/3, it is actually just the registry itself who decides. We asked how much time it takes from when the complaint is received until it is actually suspended or eliminated the domain name. The good news is that most complaints have been dealt with within one week. We had a question where we asked of a description for what a typical procedure would look like when a complainant files a complaint. This was an open-ended question so it is very hard to present the information I got in a good way, so I just tried to crystallize out some main features. First of all, there were a few who didn't have any procedures developed yet. They were waiting for the first case to arrive or they were just -- they were just under development as they replied to the survey. But a kind of normal procedure -- this is very simplified -- the complaint is received and then it is checked by an internal registry team. This team could be only technical people or technical people cooperating with legal people. And after that, the domain is suspended. In some cases the registries would send out a warning to the registrant on even the registrar who's dealing with the registrant to give them a chance to remove the malicious content and it would set a specific time frame for this. For some registries, any complaint would do. Anyone off the street could send them saying this is phishing, that would be fine. But other registries actually needed papers or even orders from an official authority to take an action. Then we asked what the registries consider being the most efficient way to solve a phishing incident. And, again, this was a question where you could take many options. But most mentioned was the suspension of the domain name, followed by criminal prosecution. Under "other" we had some interesting suggestions such as educating the public so they know it is a phishing site when you go there or sending out warning e-mails to all official agencies there are that this is a phisher. Finally, we asked whether people would like the ccNSO to continue -- to take any initiatives regarding anti-phishing. Well, you see the vast majority said yes. Interestingly enough, those who said no are quite active ccNSO council members. >>CHRIS DISSPAIN: Okay. >>GABRIELLA SCHITTEK: And then we asked which activities should the ccNSO undertake? Well, most popular was provide exchange of information, develop best practices, only a few thought we should deal with developing global policies. Actually, there was an interesting suggestion to this question as well. Someone thought that we should kind of accredit anti-phishing agencies so when they get a complaint, they know this is an ICANN-accredited anti-phishing agency so they know this is a real phishing incident. That was it. As I said, the results will be up in July with a small report. And if there are any questions or comments, let me know. >>CHRIS DISSPAIN: And the council will argue about whether we do anything else. Any questions for Gabby? Okay, great. Now, we are going to make a slight change to the agenda. Jonathan is going to talk to us about the McAfee report. Yeo Yee Ling is going to deliver Internet security survey results. But because that is something that happened at the APTLD meeting and I know Don is going to talk about that, I have moved that down to the same section in the sense that it's relevant to APTLD. So that's going to go at 4:00 in the update for regional organizations. So Jonathan, you've got about ten minutes, if that. Maybe ten. >>JONATHAN SHEA: I will try. >>CHRIS DISSPAIN: 8 1/2, 8. I would start, if I were you. >>JONATHAN SHEA: Thank you, Chris, for keeping me the opportunity to explain what we did in terms of anti-phishing and spamming, how we think about the McAfee report. In order to give you the right perspective, I think I have to do it the other way around. So let me first explain what we have done as a registry for dot hk first and then I will touch about the McAfee report at the very end. If time permits, I think we should allow Joost from dot tk to also speak about his view because dot tk was also mentioned in the report. I don't want to spend too much time introducing our registry at this juncture because I have limited time. What I'm trying to point out here is we are a combined registry and registrar. Therefore, we do have a direct interface with our registrants and they can register directly on our Web site. In terms of the type of domain names, we have six different level domain names with both the English and the Chinese types. And also we have the second level which accepts both English and Chinese at the second level. I have to skip this part. I presume we are quite knowledgeable about what phishing and spamvertizing means. For dot hk, we saw the number of reports on phishing and spamvertizing rising in March '07. We can see the number of spamvertizing reports was actually a lot more than the number of phishing reports. And actually the number of reports reached the peak in July with 8,000 something for spamvertizing and you can see there is a sudden drop. I am going to explain why this is the case. You also see from this chart that the phishing reports tend to say at the same level while the spamvertizing reports, they drop quite noticeably. And as we can see in these two tables, actually the situation has improved quite a lot, starting January, February this year, okay, so March 2007 when we received a lot of reports on phishing using dot hk, we immediately contacted our Hong Kong site, friends there, and we have good discussion with how to set up our own procedure to verify whether a particular dot hr domain name has been used for phishing. It actually incurred some time for gathering, accumulating some experience and, therefore, we thank Hong Kong site for giving us the greater expertise on doing that. And in July 2007, we tightened our online payment because we discovered that the criminals, they usually use stolen and lost credit cards to register the domain names. And, therefore, tightening up the online payment would be quite effective. For example, we allow only Verified By Visa on our direct registration for payment, plus some other intelligence experience through the online payment gateway as well. I'm not going to talk about this point by point, so please forgive me. I just will touch upon the main points here. And in July 2007, when we spotted there was a peak in spamvertizing reports, more than 8,000 of them, actually that is because our telecom record authority body called OFTA, Office of the Telecommunication Authority -- right -- they started to post on a daily basis a list of domain names which are suspected to be used for spamvertizing. The first time we received the report, there were more than 8,000 entries. Therefore, we have to go through the list pretty quickly and then chop up most of those domain names. Of course, you may wonder should we just go and suspend them right away or not? Actually, we have to do the hard way of going through them one by one making sure we are not killing the innocent registrants. We did that, and then we tightened up the online payment. And then we started initially some manual checking on the applications on a daily basis and stopping those who are suspected to be used -- who are suspected to be registered by imposters. Actually in early 2008, we introduced a new measure in our computer system. We introduced some intelligence in our application process. For example, if we discovered that they input strange numbers in the document number field, they input large system addresses or they input name servers which we know have been used extensively for phishing and spamming, then we will not allow the application to go full strip away. We will request them to provide some identity proof, no matter whether they are local or overseas. Now that proved to be quite effective because the criminals who never go through this painful process of keeping this document. They would just go somewhere else looking for a more easier place to register their names. Therefore, in terms of numbers as you can see on this table, in 2007, we have something like six per day on phishing reports and 74 per day on spamming reports. But actually in May 2008, the number has been dropped to 00.3 per day. We noted that the criminals actually used stolen or lost cards to register their names and, therefore, this is quite an easy way to detect whether that particular application is likely to be inputted by imposter. There are many other traits and characteristics in the application process that we can use to judge the likelihood of whether the application is actually inputted by a criminal. As far as we understand, as a registry, there are many difficulties when coming to doing suspension of domain names. For example, for most of the registries, the registration agreement simply does not allow that. There is no power by the registry to suspend domain names or stop domain names unless it is requested by the registrant. Also, there is a problem of lack of experience. How can we distinguish whether a report is a real report or just a hoax? And it is very important that we make that determination very carefully. Otherwise, that may lead to, you know, serious liability issues. Since we have accumulated some experience in the past months, myself and my staff have been -- have attended a number of conferences on anti-phishing and spamming in the past few months and we actually had a lot of feedback from anti-phishing working group seeing that, okay, the case of dot hk has been under control and is getting better. And, therefore, when we received the McAfee report, we were really, really surprised how come when the community -- when the anti-phishing and anti-spam community was sort of responding to us that we are doing a pretty good job in the past few months how come the report from McAfee we are still number one in the worse ccTLD. Therefore, we looked at the report carefully and we spotted something like they say we have soared to the number one position in 2008 and we are now the most risky domain name ccTLD. But, in fact, if you look at the report, it was published in May 2008. So how can there be a ranking for the year of 2008 when the data is mainly in 2007? This type of ranking is used by the Fortune 500 when you are talking about Fortune 500. You measure the data in 2007 and you give them the ranking in year 2008. But for negative ranking like this, this is simply not going to work and it will just mislead the readers crossly. Therefore, we have been writing a letter to McAfee to request them to correct the report. If they are going to talk about us -- talk about us in 2007 terms, not in 2008 terms. So I think this is what I'm trying to explain to them. And since dot tk has been ranked number one in 2007, I think Joost is around. Would you like to say something about that, Joost? >>CHRIS DISSPAIN: Very, very quickly. >> My name is Joost from dot tk. We give away free domain names. We are registered about 2 million right now. In 2007, we were hit as number one in the McAfee report. This was, basically, due because our revenue comes from advertising. In 2006, one year before 2007, we had popup ads on our Web site. They were very legitimate ads from all kinds of different companies we actually sell ads through, also sold through Google and Yahoo and other vendors we use. Because of these popups McAfee software saw a tk domain name with a popup ad as phishing, spam or virus. We took that under the attention of McAfee and they, basically, said we don't really care, it is still viruses and phishing and scams, which obviously they are not. Because of the popup blockers months later, we actually took them down and, therefore, we now rank 28. So, I guess -- I don't know how McAfee is really ranking the behavior of everything. It has hurt our brand in the last, I think, two years. We saw really a drop of registrations. We had different requests from the local government in Tokelau about this, what is going on; and we have to explain, of course, about popups and how this all works and that it is not viruses. We didn't have a chance to talk to McAfee to actually tell them that it's not viruses or anything else, it is just their own way and their own corporate power to lay something up to the rest of the world. So not a good thing. I wish dot hk the best in fighting that. >>CHRIS DISSPAIN: Thank you. And Nigel wanted to make a quick comment and then I have a question. But we really do need to keep this very quick. >>NIGEL ROBERTS: I think we can speak on it for a couple of hours. I would like to congratulate dot hk on the progress they've made. I have been in correspondence with McAfee. Everybody here, I guess, thinks they ranked all ccTLDs with the most risky and least risky. Not true. They only ranked 74. I have got it in an e-mail from them today. >>CHRIS DISSPAIN: Right. >>NIGEL ROBERTS: We are in discussions with them about them issuing a correction because clearly the press will pick this up and they simply have not included Guernsey and Jersey. How can they say a country is more or less risky than we are if they don't include us? >>CHRIS DISSPAIN: Yes, understood. Bill you had a question? Gabby, could you possibly microphone Bill? >> BILL SEMICH: Actually, last year dot nu was listed as the most risky in the McAfee report I think in terms of the malware and other stuff. So I put two full-time tech staff on harvesting the McAfee database to see exactly what they were testing. And of the 130,000 domain names which we had registered and active last year, they only tested about 9,000. The tests come only from the users of their tools. So if a user of their tool never goes to your domain name, your domain name will never appear in their results. And of the 120,000 names we had registered they actually found 62 domain names that are red or yellow. I don't know how that became 2.1%, but their data is totally bogus. and we should actually as a group request that they release the raw data for the study so we know what we are talking about. >>CHRIS DISSPAIN: I agree. I think what we'll do, I don't think there is any need to discuss it. We'll end up just talking about it forever, as you said, Nigel. I think what we might do is put this on the agenda for the council meeting tomorrow just to see whether we can perhaps get the council to agree that we should make some sort of approach to them and start talking to them and seeing if we can get a hold of information, et cetera. Obviously, we'll need to liaise with the rest of those of you that are involved and have spoken to them already to get to the right questions. Jonathan, thank you very much, indeed. >>JONATHAN SHEA: Thank you. [ applause ] >>CHRIS DISSPAIN: It is time for coffee. Before you go, when you get back, we are having a presentation from the Angolan registry on the birth of the Angolan registry. And then we're going to move into our update from regional organizations which will include the report on the security. Can I please ask you all to be back in the room at 10 till 4:00 as a courtesy to the people from the Angolan registry to listen to their presentation. Thank you very much. (Break) >>CHRIS DISSPAIN: Please take your seats, ladies and gentlemen. We're going to get started. Please take your seats, ladies and gentlemen. We're going to start again. Okay. So we're going to have a short presentation from Teta from the Angolan -- I'm sorry, the Angolan registry, and -- Hartmut? Hartmut? Sorry. So Teta. >>M. TETA: It is an honor for us to share with you shortly a story of Angola domain name administration, and to present a new registry for Angola. As you know, in 1990, the African countries started to be linked to Internet, and Angola was an exception. In '96, the Angolan University, Universidade Agostinho Neto, the public university of Angola, helped by Instituto Superior Técnico and Fundacao Para A Computacao Cientifica Nacional of Portugal started really the connection to Internet our -- and now we believe that we have to do domain match more dynamic, much more and user friend and come here to present you a new register made by French people, people from Czech and from Poland. Mr. Bernard Gregory will present you our -- the proposition of our registry, and after this, you can put some questions and we will be here to answer you. Thanks. >>GREGORY BERNARD: Thank you very much, professor Teta. So we have to say that the Angolan domain organized by sub-domains, classic classifications, dot cu dot ao, dot it dot ao, dot gov dot ao, and dot ed dot ao, dot bt dot ao and dot og dot ao, and there is a strong technical support which has been provided by FCCN-Portugal, and they are actually hosting the dot ao root server. And there is about 700 domains today, and one of the major issue is to -- for Angola to invest in the Internet, and to try also to have a price of domain names, so one of the main actions consists of trying to reduce the price by some 50%, which will hopefully put the extension under a dynamic situation. And we also plan to develop some specific support for Angolan engineers, and invite everyone that has a specific technical skills to participate into this program, and there is a strong will to future dot nl names under international market of domain name. So this is why we have decided to launch new services for dot it dot ao and dot co dot ao, and at the same time to promote peering links between operators in Angola, because this is also a very important part. Most of the communications are going abroad today and the peering is something that is needed in the country to develop the Internet. So we begin a study in February 2006, and it involves an international team leaded by Angola. We do the funding and the general direction. Portugal give us technical support. France has provided leading and consulting skills. The Czech Republic has provided the main registry handling solution. We are very pleased to announce that we will use, for the first time, FRED, FRED solution, which most of you have certainly heard of, and Poland has provided us with a strong leading team of skilled engineers. This was in the quest of providing Angola with the best solution possible. So we have started from FRED. We have developed a Java connector which integrates the EPP protocol, and it's available as open source under the domain name Afrinet.eu. At least it will be available in short time and this has led to the development of the first Angolan registrar. So -- and we plan to add more registrars in the near future. So now let me show you the organization of the project. So the root server is still going to be hosted at the same place it is hosted, actually, and we are going to develop the registry for the sub-domains, dot co dot ao and dot it dot ao. You can see the EPP connection in the first Angolan registrar, which is going to called reg.IT.AO, and of course as this registrar includes EPP connection, it a plan to open these solutions to other registrar worldwide. So a testing version is already available online. We are entering live restricted deployment for testing during three weeks, and we plan to have an official launch somewhere in September. So this is a picture look of the solution. And so the digital future for Angola is going to be led by a strong relation with local ISP, which will obviously play a role in the development of the dot AO domain names. We have developed a system that will be very compatible with why people work in Angola. We hope that new international connection to the Internet will appear also in the country. And there will be a large-scale hosting facility which will be deployed in Angola. And new products which will be launched based on the dot AO domain. So the ambition of Angola is not only to lead the dot AO domain names, but also to try to put some other African and worldwide country and to try to have persons join the corporation that we have started with -- that I have mentioned at the beginning of the presentation. So Angola and the international partners can provide support for the implementation of a similar project, and we -- some part of the project will, of course, be open source. So thank you very much for your attention, and we are ready to answer your questions. Thank you. >>CHRIS DISSPAIN: Does anyone have any questions? Hilde? >>HILDE THUNEM: Thank you for a very interesting presentation that I unfortunately didn't get quite the beginning of. But I would like to ask you about the registration root that you are planning to have. Will the dot AO be open for everyone like foreigners, or do you have to be in Angola to have a domain? >>M. TETA: That's why you have two sub-domains, it dot ao and co dot ao. IT is for people abroad, for everybody. >>HILDE THUNEM: Okay. >>M. TETA: CO for companies seated in Angola. >>HILDE THUNEM: Okay. >>M. TETA: Okay. >>HILDE THUNEM: And then CO will be for companies only or individuals also? >>M. TETA: It can be individuals also seated in Angola. >>HILDE THUNEM: Yeah, yeah. Seated in Angola. >>M. TETA: The CO, yes. >>HILDE THUNEM: Yes. >>M. TETA: IT is -- means international, CO means commercial. >>HILDE THUNEM: Okay. Thank you. >>M. TETA: Yes. >>HILDE THUNEM: Will there be any limit on domains or can you have as many as you want. >>M. TETA: You can have a million if you want. >>HILDE THUNEM: As long as you pay. >>M. TETA: Yes. >>HILDE THUNEM: Will they have to show some kind of trademark or documentation that before registered Coca-Cola.CO.AO, that I am really the holder of the trademark or just anything I like? >>GREGORY BERNARD: We plan to comply to most of the rules that have been set up internationally, and to the Geneva Convention or to the international rules that our lawyer is working on definitive documents. >>HILDE THUNEM: Yeah. >>GREGORY BERNARD: At the same moment I am talking. So the rules will be published under NIC.AO, and it will be official documents that will set up the rules for the whole domain name. There are still some points which are under discussion. >>HILDE THUNEM: Okay. >>GREGORY BERNARD: And -- >>HILDE THUNEM: Thank you. Well, I think many of us here in the room has been through a process where we had more rules in the beginning, like, for example, in Norway's case, we required in the beginning that you could only have a domain name that matched your organization name or your trademark, and then later on we dropped that requirement but it was there in the beginning. We also have a limit on the number of domain names, but not many other ccTLDs do, so we are a bit weird that way. Thank you very much for your answers. >>CHRIS DISSPAIN: Thank you. Ming-Cheng and then Paulos. >>MING-CHENG LIANG: Okay. I have a question. Because you have co for domestic -- right? -- and IT for international, do you have a different price scheme for them or is it still the same? >>GREGORY BERNARD: The prices policy is still under discussion. What we know is the price today is $300, which is probably one of the most expensive in the world, and we plan to drop that significantly. At least 50% for the beginning, and it may, of course, drop in the very near future. >>CHRIS DISSPAIN: Palos was next. >>GREGORY BERNARD: And the price is for everybody, yes. >>CHRIS DISSPAIN: Just while we're waiting, Don and Peter, could you get ready to come up and make your presentations police. Yes, Paulos. >>PAULOS NYIRENDA: Thank you. Paulos. We did a survey sometime, and Angola is one of country where technical services are still run from outside and maybe you can give us more details on program for moving the services into Angola. >>GREGORY BERNARD: There will be various stages in the -- in the process of having Angola main DNS system put in the country. At this stage, the electrical problem obliged us to have the registry located abroad, but they will have a secondary server deployed with the first version of the project that we are showing in Angola and as I said in the presentation, they will have a posting facility built in Angola that will allow us to relocate the root DNS server of dot AO, probably one and a half years from now. >>CHRIS DISSPAIN: Anyone else? Okay. Will you please join me in thanking our friends from Angola. Thank you. [Applause] >>CHRIS DISSPAIN: Okay. So we're going to move on now to our regional organization updates, this time from APTLD and CENTR, and also Yeo Yee Ling's report, so if you'd like to come up as well. Who is going first? Peter? >>PETER VAN ROSTE: Don. >>CHRIS DISSPAIN: Don. Okay. So ladies and gentlemen, Don Hollander. >>DON HOLLANDER: Thank you very much. This is just an update on APTLD and things that have been happening. For those of you who don't know us, we are the Asia-Pacific top-level domain association. You can see from some of the photos that we have here that our meetings tend to involve food and a lot of laughing and dancing and singing. [Laughter] >>DON HOLLANDER: So in 2008, we'll have a couple of meetings. We had a meeting in Taiwan in February where our focus was DNSsec. We finished a meeting just recently in KL. We had 111 people registered, 30 speakers, 46 sessions, and we focused on ADRP, anycasting and registry solutions plus a number of other topics and Yee Ling will stop about the phishing/security survey that we did. We're also considering meetings in the Pacific and the Middle East if there's interest, and we will be having our final meeting of the year in India in conjunction with the IGF, so anybody's who is planning to be at the IGF, you're welcome to come a few days earlier and join us for our meetings. One of the focuses this year is the training program that we're providing for our members and for our friends. We did the AD -- as I said, the ADRP, and I'll go into that in a little bit more detail. We also ran a half-day policy development workshop that was led by Debbie Monaghan, phenomenally well-received. We also ran a marketing for ccTLDs session run by Adrian Kinderis of Oz Registry International, also very, very well received. That was broken into two sides. The first is marketing to consumers, so this is your -- for most of you, your customers' customers, and then -- and then marketing to your registrars and resellers. The presentations for all these meetings are up on our Web site, and hopefully by the end of July, we'll have some of the videos from KL. We also ran a software solutions review where we had six registry software solution providers come in and talk to us about their system, so we had six -- I won't name them because I'm sure I'll forget one of them but they're all available there. We're also running a training -- technical training workshop in Brisbane in conjunction with APNIC on the attack issues around the technical aspects, so for those staff members of ccTLDs that are geeky, this is the opportunity. And we're considering a nontechnical training session in December. I'd like to talk about ADRP quite specifically. This is an initiative that stemmed from our meeting in Bangkok in October, and the question was: What keeps ccTLD managers awake at night? What causes you to start or startle in the middle of the night, sit up, bolted upright and say, "Oh, my goodness?" Because my job, of course, is to put people to sleep easily, so they get me to talk from time to time as well. So the focus here the program that we ran in KL and we'd like to run -- we plan to run again is focused at management, at your CEOs, at your chairs. This is not a geeky issue at all. How do you make sure that in the event of a problem, you keep your ccTLD alive, you keep your chairs sleeping at night and you keep your CEOs employed after any instance? And a key aspect there is communications. As I said before, we'll have a program in Brisbane that we're working with APNIC on, looking at the design, the mitigation, and the response to -- at a technical level to attacks for when they do happen. And on the right are just a couple of quotes from the evaluation. The obligatory statistics, so APTLD has members. I am grateful to those members for increasing their membership contribution in this past year, and I hope that they continue in that trend. We do have a program this year for external engagements, so there's a bunch of letters there that some of you might know what some of them mean. APTLD is also working with the regional organizations. We had a brief meeting yesterday. We do that at each of the ICANN meetings. We try to get together for dinner or for drinks or what have you, and we want to share jointly the ADRP program. We also talked about sharing some study tours across regions for ccTLDs that have common aspects. We're working through a CENTR-led initiative on the IGF. We're sharing documentations and reports. So CENTR's building a number of one-page facts sheets. LACTLD is also doing some workbooks. We do share ideas, and one of the things we're talking about is sharing some research in 2009 and Peter will talk a bit more about that. So next, for APTLD, the board has just completed a strategic review. What are we here for, what are we doing, why are we doing it. We'll be producing later, in the second half of the year, a catalog of services that members can offer to each other. Doing an update on members' contact details, similar to what gabby's doing. We'll be further engaging with nonmembers, outreach to international organizations, study tours, consulting, and one of the things we like to do -- I like to do is visit ccTLDs. I liken it to being a bumblebee, so when I first started, I didn't know a lot and I was picking up ideas from visit to visit, and now I'm fortunate that some people say, "Ah, well by the seventh or eighth visit you know something about it and you just plant other ideas that you hear." So that's something that we do for our members as well. So if you have any other questions or information, please see the APTLD.org Web site. All our material is there, open and available. If it's not clear, then just send a note to Don@APTLD. Thank you very much. >>CHRIS DISSPAIN: Thank you, Don. Just before we move on to Peter, I just want to apologize to Michuki and to Hartmut for not saying that they were going to give an update on -- working off a very old piece of paper here which is clearly out of date. Peter? >>PETER VAN ROSTE: Thank you, Chris. Good afternoon, everyone. Red seems to be the color for at least two of the regional organizations. I don't know Michuki and LACTLD. I'm going to give you a brief update on what we've been doing at CENTR. Obviously the time frame does not allow to go into any sensible amount of detail, but regardless, as a teaser, if there are things that I will go through that you are very interested in, feel free to contact me. Quite a lot of our documentation, information, and data is restricted to two members, but obviously I'm very happy to make it available to ccTLDs that are interested in it. So CENTR, we're one of the four regional organizations. We have 55 members in total. Our members have, in total, just over 42 million domains in their databases. We have a European focus, but we have members from other regions as well, and as I think when most of the other regional organizations, we have a focus of ccTLDs, although some gTLDs are members too. What have we been doing? And again, this is basically to give you a idea of what information you would -- could get from us, a member or nonmember. The last general assembly, which is our big meeting, we focused on the market analysis and new services. We commissioned a study from Matthew Zook, which I will give you some more details in a minute. We discussed new and interesting WHOIS services that can be provided to registrants, trademark protection. These were a couple of topics under new services. The next meeting in October will focus on new trends. What does that mean? We will, for instance, try and aim to get a decent panel of people from the search engines to our meeting, and ask them what their future plans are when it comes to ad words and advertisements, a topic that I think is crucial to the future of ccTLDs. We have an admin workshop -- we have a couple of specialized workshops. The most active are the admin, the legal and regulatory, and the technical workshop. The admin workshop focused on registry/registrar communication, ENUM IDNs and there was a large-scale administrative survey. I will give you a couple of statistics in a minute. Legal and regulatory workshop, unfortunately did not have time to focus on more than one topic because that topic is crucial to us. At least to the European ccTLDs that are hosted in a member of the European community, because The European Commission came up with a directive, and there is room for debate on that, but one could read in that proposal that the commission would become responsible for the regulation on ccTLDs. It's formally slightly broader but that's basically the issue. Obviously our members are slightly concerned about that, especially given the unclarity that surrounds the whole issue. So we've been working very hard on this. The technical workshop has been focusing on IPv6 and critical infrastructure. More in particular, what is role of a ccTLD in that critical infrastructure, and are we that critical. The "A" level survey, 77 detailed questions, so it's a big survey. We had a very good participation percentage. I think about 43 out of the 45 full CENTR members participated, and it is the third time that we have such a survey, with almost identical questions, so we have very good reference points. And just the highlights. 43% would be considered as a public entity, whereas 57% of our members would be considered to be a private entity. If you break that down, you see that out of the entities that are considered to be private, a majority is structured under the form of a foundation. Another relevant point, I thought, was that time to registry -- to register, and that is, as soon as all the necessary requirements are fulfilled, has improved quite significantly, if you compare 2002, 2005, 2008. Also an also very interesting figure I think was currently 57% of the CENTR members do not allow IDN registrations. . A second topic I'd like to give you some more detailed information on is the zooknic study. What we did -- and this was basically based on a -- Don's initiative. APTLD last year commissioned a similar study, and they basically asked does price matter? What is the influence of pricing on the number of domain names in your ccTLD? We slightly broadened the scope of that study, and we formulated the question as: What are the relevant factors, price probably being one of them. The findings were intriguing. They are not -- I think we should definitely not treat them as the Almighty truth, but they're definitely food for thought. And for those who are wondering, yes, there are -- they have very sound academic statistical -- they have a very sound academic and statistical basis. Does price matter? Yes, price does matter, but it has an almost insignificant effect in the very low and the very high ranges, so a domain costing 300 U.S. dollars or a domain costing 290 U.S. dollars would probably not make that much difference in the number of registrations you'll get. Growth of the Internet is the key factor, and I was very pleasantly surprised when I saw that same element play in Jian's presentation on dot cn. With the CENTR members, this was measured by the number of secure layer certificates that were handed out in one country, and the very easy-to-measure broadband penetration. A mild dot com substitution effect, so would people choose a dot com instead of a ccTLD if it's cheaper or more expensive. Obviously in Europe we slightly benefit from the U.S./EU conversion rate, which was also factored into the study. Policy changes to our liberalization have very strong effects on the short term. That also means that the long-term effects is almost not measurable. More registrars equal more ccTLDs under particular domain. Apparently the registrars or the agents, whatever they're called, they want to sell and, therefore, they're doing a good job. Strategically enough, for one or two domains, this does not work at all. Marketing campaigns. If they are combined with price incentives, sometimes one domain for free type of actions, they do work on the short term. On the long term, it was very difficult to measure. If there are no price decreases that go hand in hand with the marketing campaign, even the short-term effect is not very visible. So these were just the highlights, and again, definitely room for debate here. A last thing on my list, IGF. As Don already briefly mentioned, we are cooperating with the other regional organizations on IGF. We did that successfully in 2007. We want to repeat it in 2008. We have filed an application for a workshop around the world in eight ccTLDs. It will be a regular workshop. And we're also aiming at an open session, with focus on IPv6 and we're still looking for partners for that venture. And then we have -- we will have, as we had in Rio, an educational booth, so that the participants in IGF can learn more about the ccTLD world. This is a booth that is organized by all four regional organizations. I would greatly appreciate it if those of you who will be at IGF make it their meeting point for every meeting that they have. That generates a lot of traffic and, therefore, makes this initiative very useful. We still have our domain wire, which is our magazine. It can be -- it's in English. It can be helpful in educating people about our business. Feel free to use it. There's our Web site. There is tons of information on there. There are plenty of locks on there, too so if you hit a lock, feel free to contact me personally and make sure that you get to the information that you need, so Web address. Next meeting in Pisa. There are sponsorships available for travel, and the meetings are not open only to members, but all ccTLDs are very welcome. That's it for me. >>CHRIS DISSPAIN: Thank you, Peter. >>PETER VAN ROSTE: Thank you. >>CHRIS DISSPAIN: Thank you very much. Michuki, do you want to go? >>MICHUKI MWANGI: Thank you, Chris. I guess a lot of issues have already been pointed out in terms of the areas of collaboration we have between the other regional TLDs, so I'll probably just restrain myself to just giving just the main activities that have actually occurred within AfTLD in the last six months. One of the things we started at the end of last year, we engaged in membership formalization process and recruitment drive. And the objective of this was to actually formalize the relationship we have with our members. This has been ongoing and has been quite successful to date. We have 13, 1-3, formal members of the 54 countries in Africa. And we are hoping that this will grow. One of the main challenges we have is that most of the ccTLDs in the African region, well, some of them are actually in a dire state and need a lot of help. So they may not be in a position to join at this point in time. But as they go on in terms of growing, finalizing the redelegation processes that they are in the middle of, we'll be able to see them joining up. We also did have our annual meeting, which was held in April in Johannesburg, South Africa, courtesy of the south African government. And this event was one of the most successful AfTLD activities being the most successful one, the last one being last year in Cairo. To this meeting we had 57 participants attending and most of them coming in from governments, ccTLD managers and also the new registrars -- TLD registrars in the region. We also were happy to be graced by the presence of APTLD, CENTR, and Nominet and huge other range of representatives also from the ITU and also we had Gabby coming all the way to give a presentation as well and dot fr. Really, it shows that there is a lot of collaboration that is ongoing between the various regions. And we want to thank them once again for taking the time to actually come all the way down to South Africa. The meeting was quite impressive in terms of the presentations that were given. We were able to learn a lot from what's ongoing and most importantly there was one presentation that caught my attention, at least I also believe the attention of most that was development of ccTLD in Africa. It shows where the ccTLDs were way back to today. At that point in time, we'll see that the money just was actually individuals or academic institutions and governments are getting more and more involved in ccTLD management in the region. So that presentation is actually available on the Web site so you could download it and go through it. It presents some very interesting insight into the status of ccTLDs in that region. Again, from this, we were also able to identify some of the future things that we would want to talk about in future meetings. And one key thing that came across was billing solutions. And so ccTLD billing solutions seemed to be quite a topic of interest to quite a number of the members who are present. And this shows that the ccTLD are moving from a point where they are actually providing free services or free domain name registration to a place where they want to have a sustainable model which has fees levied to domain name registrations. And I believe this is a critical point, especially for the growth of the ccTLDs in the region. Again, something also which was good from this meeting was that they were able to extend the mandate of the ExCom for another year and we also got two new members nominated to the ExCom which is the executive committee of the AfTLD and we got two new women so we have good gender balance this time around. Basically, one representative from Egypt and the other from Botswana. Again, this assembly also looked at the stability model of AfTLD and realized with membership formalization process we needed to entrench into a sustainable model in the structure. And so we were tasked to go and review the structure so that we can have fees being paid by members to enable AfTLD, be able to conduct its activities. And so as a result of that and other discussions, we formed up various working groups at the end of that particular meeting. And so we have four working groups: A technical working group, one on constitution, IDNs, and one to do research. The IDNs will mainly focus on planning activities, capacity-building activities in the region. The constitution will review the constitution to include issues of structure and model of fees to be -- the fee structure to be paid by members. IDNs will have a specific focus to address issues of IDN within the member communities that -- or the members, rather, who are really interested in the issue of IDNs. The research will focus on more areas of research as what Paulos was able to present on the status of ccTLD and how we can be able to research into more issues that affect the members. And then, finally, towards the end of that activity, we had a member, actually two, offer to host the next meeting next year which is going to be in Tanzania. Previously, we had to go out and solicit a member to host. And in this case, we have members now offering to actually host the subsequent meetings. So we feel that AfTLD is getting to a point that now the members have actually realized the importance and the value of the organization and there's ownership from the process. And they are able to embrace the activities and we feel that's significant progress within those two years that we've been trying to revamp the organization. And I think with that -- well, yeah, we are also looking to hold one particular capacity-building workshop toward the end, hopefully something by the time we get to Cairo or within the Cairo meeting. But we have to finalize the final details of that. And with that, I think that comes to the final of my update of AfTLD. Thank you, Michuki. Hartmut? >>HARTMUT GLASER: I will introduce an update of LacTLD. My name is Hartmut Glaser. I work Nic br for the last 12 years and now I am a board member of LacTLD. Since New Delhi in India, we have our yearly meeting in Salvador. This time in Brazil sponsored by nic br. This meeting was together with Lacnic meeting. In Latin America, we have a joint meeting, LacTLD and Lacnic and all other entities related to the Internet. We spent a full week together and three days only for LacTLD. During this meeting we have a election. A new board was elected. Oscar Robles from mx, Mexico, the chairman. Myself as treasurer. Edna Samudio was present from Panama as secretary. And Victor Abboud and Rafael Ibarra as substitutes. LacTLD is not so young but the entity as a legal entity under the law of Uruguay was only formalized in 2006. Now we have the status of an international organization under the law of Uruguay, and we share the office with Lacnic so we have space for both entities in Montevideo. It is an organization that aims to promote communication among all the ccTLDs in our region. We have 22 full members. You have the codes there: Argentina, Bolivia, Brazil, Belize, Chile, Colombia, Costa Rica, Cuba, Dominica, Ecuador, Guatemala, Honduras, Nicaragua, Panama, Peru, Puerto Rico, Paraguay, Salvador, the youngest member is Trinidad/Tobago, tt, Uruguay and Venezuela. Normally our yearly assembly is in May/June as mentioned this year in Salvador, in Brazil, sometimes in other meetings during ICANN meetings in our part of the world. It is the first time that we can announce that we will have a full-time employee. Margarita Valdez, she was the chairperson until now, was very difficult to work because of some limitation and the money. At this time, we have Erick Iriarte. He is our new full-time employee. He is very well-known. [ applause ] He lives in Lima, in Peru. He is a specialist in the area of DNS and domain names. He is a lawyer. And he will work for us now full-time. And we hope that he can be a help for the other regions and for the country in the collaboration with other organizations and taking care of the membership and some other services that we try to put in place. As I mentioned, our office is in Montevideo. All the administration will be done there. And Erick will travel to other countries to visit other members. For the second half of this year, there will be an outreach problem in the Caribbean, probably late July. We need to confirm one detail but it will be a jointly meeting, Lacnic, the Carribean Telecommunication Union. And there will be a workshop we expect to hold in Curacao, Netherlands Antilles. Later there will be a training workshop in Panama with ISOC funding, so we try to support our members and train and bring some information and some help that we can develop together. It is a very short information, our next meeting will be next year. We have only one meeting a year. We will be in Panama. And if you need more information, we will centralize every information on our Web site or on this web mail -- e-mail, Erick Iriarte will be our man who will give all the information that you need. So please take an advantage that he is here, myself and others. We are, I don't know, eight or ten Latins. So if you have some question or some request, see us please. Thank you very much. [ applause ] >>CHRIS DISSPAIN: Thank you, Hartmut. Okay. We're going to have the final presentation of this session which is from Yeo Yee, and it is a presentation of the APTLD Internet security survey results. Our first technical issue of the day. Anybody know how to make it work on this screen? While we're waiting for the technical issue to be solved, can I deal with a couple of housekeeping points? The council is in the room. We have a breakfast with the board tomorrow morning. Councillors, Patricio, councillors, Dotty, we have a breakfast with the board tomorrow morning at 8:00 and it's in Giacometti which is where I think we had lunch today. Just wanted to let you know that. And we are firing. Thank you. >>YEO YEE LING: Thank you, Chris. Hi, good afternoon. My name is Yeo. I am policy officer from Mynic. Mynic stands for the Malaysian Information Center. We are the ccTLD for dot my, former Malaysia. We conducted this internet security survey together with APTLD. So just to summarize on the survey, we wanted to examine the roles and responsibilities for ccTLDs in Internet security. But there was a particular focus on Fast Flux and phishing. The objective of this survey was fivefold. One of which is, basically, we wanted to assess how ccTLDs can improve on the security level for customers of domain names. So out of the 36 ccTLD members of APTLD, we received 22 responses and the responses, basically came from 19 ccTLDs. So the percentages are slightly skewed in the next couple of slides because we had two respondents from the same ccTLD answering the same question. So I'm going to skip now a couple of slides. These were on registration renewal, transfer process and go straight to question 21. So this is the question that was asked on Fast Flux: Has your ccTLD received any complaints from registrants that their DNS resource records were used for Fast Flux activity? A majority 90% answered no. But interestingly enough one ccTLD that comprised the 10 percentage point there answered yes. And when asked which DNS resource records were used for the Fast Flux activity, the answer majority, 100% was the a record. 30% of that regard responded name servers. The next question was on phishing and we asked: Has your ccTLD domain names been used for phishing activity? 55% responded yes. And the next question was how is this phishing activity carried out. 64% answered that they were -- that the domain names were registered by the phishers. Slightly lower number around almost 36% answered that they haven't experienced any names being used for phishing. We then asked what forms of domain hijacking does your ccTLD registrants experience? Big percentage, almost 87%, answered that they haven't experienced any form of domain hijacking. Smaller, equal percentage, 6.7% answered that it was in a form of unauthorized DNS configuration changes to their name servers and impersonation that leads to unauthorized transfer of the domain name from the rightful owner to a third-party. And on the next question, what action does your ccTLD take when the complaint is directed to you? 61% answered that they would notify their registrar. Almost 54% answered they would notify the registrant. 46% would notify their regulatory authority. 38.5% would suspend or delete the domain name and minimum percentage of 15% answered they would notify their CERT. And when asked who complains on the phishing activity to your ccTLD? 77% answered that the affected companies themselves, the banks or financial companies that were impersonated by the phishers. 61% answered the victims themselves would report on the phishing activity. Equal percentage 53, almost 54% responded and answered members of the public or the CERTs. 38.5% answered it is the government agents. Almost 31% answered the registrant and small percentage, the registrar. And when asked what's the type of phishing activity that the ccTLD domain names experience, a big percentage, almost 92%, answered banking followed by shopping and last on the list, investment. And then we asked what are the patterns of domain name registrations that were used by the phishers? 70% answered it was a form of typo error of the domain name. You can see the example abcbakn instead of the original abcbank. 50% answered it is part of the URL. 40%, equal percentage, gave two responses that it's a type of variation of the domain name. So it is abcdbank instead of the actual abcbank. And also on the subdomain level of the top level, so it is phishing.abc.tld. And 20% answered it was a type of homograph of the ASCII domain name, where the example given was bank with the letter "e" substituted with a Cyrillic character. When we asked if you don't suspend or delete the domain name, on what basis would your ccTLD suspend or delete it, if there is a complaint on phishing activity? 77% answered they would require either a court order or a directive from a regulatory authority company. And smaller percentage, almost 8% answered they don't suspend or delete at all. And when asked if you feel that your ccTLD has a role in reducing phishing activity? 88%, a big percentage, a majority answered yes. And when asked what can your ccTLD do to reduce phishing activity, 61% answered they would strengthen the identity verification of the registrant. 55% said they would educate their registrants on maintaining accurate information. 50% would support legislation against spamming or phishing. 44.4% answered they would cooperate and work closely with their CERTs and protect e-mail addresses. 33% responded they would hide the WHOIS display of the administrative contact e-mail address. Almost 28% answered they would hide the billing contact's e-mail address. 22% answered they would deploy DNS security extension for domain name's delegation. And 16% answered they would adopt anti-phishing tools at the network level. This chart is borrowed from Don's paper on the sleeping patterns of ccTLD managers. So these are the top five critical security issues in ccTLD's minds. Number one is DDOS attacks, followed by spam, Fast Flux and double flux number three; protection of personal data, number four, and cybercrime ranks number five. So just like to end by thanking ccNSO for the phishing survey. That was the basis for this joint survey with APTLD. And I would also like to take this opportunity to thank APTLD members who responded to this survey. Thank you very much. [ applause ] >>CHRIS DISSPAIN: Any -- no? No questions? Okay. Thank you all very, very much indeed. Thank you. [ applause ] So Dotty and Bart, Patricio and Slobodan. We're going to move on now to a session on the -- for ccNSO procedures working group, which is chaired by Dotty. So... I'm surrounded by procedural people. If the law enforcement people who are coming to talk to us are on time -- they will be, thank you, Keith -- then you have until 5:15 to complete this presentation. >>DOTTY SPARKS de BLANC: The process of this working group was set up in Delhi at the planning session that the ccNSO Council had the day before the ICANN meeting began. And the members of it are Slobodan Markovic, Patricio Poblete, Dotty Sparks de Blanc, me, and the ICANN staff which was invaluable, Bart Boswinkel and Gabby. Basically, this project was not a reinvention of the wheel, and it is very non-controversial. It was an attempt to develop a set of procedures and write them down and, basically, draft guidelines for the things that we do all the time. It's based on two existing documents. The first are the ICANN bylaws, Article Number 9 which is relating to the ccNSO. And the second is a document that maybe many of you haven't really focused on very much called the ccNSO rules. They were adopted in Cape Town in December of 2004. So using those two documents and principles related to the following set of ideas, one -- first we did was to document the current procedures as much as possible. And second was to clarify the roles of the ccNSO members and non-members. The ccNSO as a group welcomes and has increasingly been welcoming the participation of non-members of the ccNSO, both in meetings and in discussions and activities of working groups. So the activities that are reserved entirely for members are related to decision-making and the formal votes, such as nomination and seconding of candidates for the ccNSO Council. At the same time, looking at it from those points of view, we wanted to retain as much flexibility as possible and introduce a little bit of procedural activity and discipline with guidelines and these guidelines as distinguished from rules. Each of the guidelines offers an opportunity to deviate from the procedure wherever it seems appropriate. So with that, we drafted guidelines for the following activities: ccNSO Council meetings, ccNSO general meetings, setting up a working group, ccNSO liaisons and observers and the selection procedure for ICANN board seats 11 and 12 and the ccNSO Council election procedures. And Bart is going to highlight for you the elements of those documents. >>BART BOSWINKEL: Yeah, I want to do it as quickly as possible. If you have any questions, please, please ask them. They are published on the ccNSO Web site under the working groups, maybe if you have a chance to read it. I will just go through some of the most important ones, is the introduction Dotty explained is included in the document itself. It is a kind of handbook. So everybody can see how it works and it includes the ccNSO rules, as you can see. I think the first important one is rules of the ccNSO. That's obvious. We haven't looked at them at all. They are a given, as Dotty explained. The council meetings themselves, I think the first one is Section 2, the agenda setting of the ccNSO Council. It is very clear we needed to do something about it. It's sometimes too much of one person driving the agenda and, yeah, that needs to be more structured. The second one is, I think, what is the way the resolutions are proposed and these are adopted. Again, this is a ccNSO Council matter, and it reflects the current practice more or less. And what we've done in all these guidelines were applicable is we set up something about who could be on the e-mail list. What is important to know here, you will see it in the liaison and observers, say, the representatives of the regional organizations should be on that e-mail list and participate in the discussions as well. I will come back to that later. This is more or less -- maybe this is a good point to reflect on bullet point 10 and 11. In every one of these guidelines, there is, say, this general clause of when, say, there is an omission in the guidelines or its impact is unreasonable, the chair of either the working group or the session or the ccNSO Council can make a decision and the guidelines should be reviewed more or less every year and it could be very much as ticking the box, but it is a moment to review and evaluate how things were going the last year, should something be improved. That's more or less the general idea. It is not that we have to go through a very heavy process and review every guideline there is. That's one of the reasons for choosing it as a guideline. Okay. I think for you the more interesting one is the second one, guidelines in general meeting, we called it the ccNSO general meeting. Again, this is an attempt to structure it and I think the first one is setting the agenda and background documentation. This is based -- more or less based on the input we've received from the participation working group is that it's sometimes very unclear when and how the agenda of the ccNSO general meeting is available. So we have a very high standard that we try to have the agenda, at least tentative agenda, two months in advance so people can see and look if anything is of interest and offer the opportunity to put stuff on the agenda. That's the basic idea. Another novel at this, I would say, is chairing of the ccNSO meeting. It is very clear that chair of the ccNSO will open and conclude the meetings but what we try to do is to get session chairs not being the chair of the ccNSO. Either it is the chair of the working group or somebody who is, say, from the ccTLD community who wants to -- who puts something on the agenda, does the preparation. So it's more to involve others than, say, a small group of people running the ccNSO. Maybe what is important as well, it's -- you can see it here -- no, it's not. Again, in this document, it is very clear that the ccTLD -- or the ccNSO meetings are open for -- yeah, as open as we always used to do. And that's one. There is a specific provision that is of importance. It is ratification or veto of council decisions, a way of this process. According to the ccNSO rules and -- and probably most of you were not aware of it, and some of the council members were not aware of it, I know -- is the ccNSO membership can veto or ratify a decision of -- or any decision of the ccNSO council. And so that is now embedded in the guidelines for the ccNSO general meeting as well, and hopefully, yeah, now that the rules are a bit more public, people start to act in that manner. The ccNSO members e-mail list that is, again, just a description of the current practice, and again, here the omission in review of the guidelines. The second -- I think this is again based on the experience we had until now is how do we set up a working group. Until now, it's been done more or less on a very loose basis, but if you look in the way we've conducted that over the last couple of years, you can see a certain practice evolving and we try to describe it. I think the start of it -- and that's a good thing -- is the expression of need for a working group, and this is where you can see, for instance, there is no distinction between members of the ccNSO and nonmembers. It is -- if there is a reasonable -- if there is a need for a working group, they can indicate such and, yeah, there is one, say, condition and that's a bit of a heavy word. It is to describe the issue or topic that you want the working group on, so we can focus a working group on a specific topic so it will not become too broad. The second step is then that the ccNSO council initiates that working group on the basis of this expression of need, and then again what is important is the membership of working groups, as is currently the practice, is open for members and nonmembers of the ccNSO, and that remains to be the same. And I think this was -- this is clearly the practice we've, yeah, developed over the years. A first step for a working group is to draft its charter. What does the working group want to do? How they want to do its work. And there is -- further down in the document, it shows an annex. There is a type of template and it's not used that you really need to fill it in, but it is to assist those people who are setting up the working group to think through how they can draft the charter. Again, it is just a -- yeah, it's, yeah, for assistance. Adoption of the charter. We said something about work group activities, how they could work together, and it also includes -- because not everybody is aware. ICANN staff support is available, if needed. Either to set up conference calls or organize meeting rooms or to participate and do some work, prepare documents, as we've done in this working group. Again, here the omission in charter is reviewed. One of the more -- yeah, again, this is a practice but we thought it would be good to put it in this, a disclosure of the working group. One of the things we're very good in as a ccNSO is to keep working groups alive while nothing is happening, and so what you see, you have all these working groups and people on these working groups, but nothing comes out of it. So we thought it might be a good idea that, say, one of the things is that we have a provision that we can really close off and close a working group. Maybe you've noticed, say, in the last couple of -- say, over the last couple of ccNSO council calls two working groups would -- were, in fact, closed. So that's something to think of. Then I would go -- this is the template. You can look it up. Let me go to -- and this is one of the things we tried to clarify as well, based on the bylaws, is liaisons and observers. Specifically from the regional organizations, there was a request of, yeah, to clarify the roles of liaisons, and observers. Now, first of all, there is a distinction between liaisons and observers, and that is more -- it reflects the background of the organization. Liaisons are, for instance, people from the GAC, people from the ALAC, and people from regional organizations. Observers are members of the GNSO and members of the -- or representatives of the GNSO and representatives of the ASO, so from other supporting organizations. In fact, it means it will only be, if we ever have -- the impact is, if we ever have observers, it will only be with the GNSO because according to the ICANN bylaws there is no provision to have an observer from or with the ASO. So, in fact, we talk -- when we talk about observers, it's just the GNSO. The rest is liaisons. [Speaker is off microphone] >>CHRIS DISSPAIN: Right. You got there in the end then. >>BART BOSWINKEL: Yeah. Finally, the role of liaisons and observers in the ccNSO council. Again, this is pretty much defined in the bylaws. They can do everything a ccNSO council member can, except vote. So they can speak up. They can try to influence the debate. But they can't vote. That's all. Again, the appointment, there is a clear procedure defined in the bylaws, and we've implemented that. Appointment of observers, and there is appointment of ccNSO observers to other supporting organizations. That's one thing these guidelines will be adopted and something to discuss, if and when we want to -- the ccNSO wants to appoint an observer to the GNSO Council. That's about it, about the procedures. Any other interesting stuff? No, not really. Maybe -- yeah. Maybe reflect with regard to the election and selection of -- say, the selection of an ICANN board seat. Again, this is just a description of the way we've handled it until now, and it is quite heavy, unfortunately, but, yeah, that's the way the ICANN bylaws require things to do. And because the ccNSO has been able to -- let me start again. According to the bylaws, the ccNSO council selects an ICANN board seat member or the candidate for the ICANN board seat. However, what the ccNSO has done is use a procedure that ccNSO members can nominate a candidate and this candidate will then be put forward to the ccNSO council to be selected. So what is included is all the -- say, the invented nomination process from the ccNSO itself, so the role of the ccNSO members. And what happens and will happen, probably, is that the ccNSO council will select the candidate the ccNSO members have nominated. So therefore, it's quite heavy. And because of the region natural -- ICANN regional diversity, the procedure regarding the election of ccNSO council is quite complicated as well, and to take in -- to take into account that sometimes some regional -- some regions have more than one candidate. It could happen, so we had to think about that. That's about -- yeah, these are, I think, the highlights of the documents. Maybe one more thing is what is not included and what will be included in time is a -- say, a guideline how to interact with the ICANN strategic planning and budgeting process. That was one of the requests from the ccNSO council as well, to start thinking about it, but we thought this is easier and there were some steps and we can wait up till, say, the next meeting in Cairo before we look into that and then have it prepared by then. That's all. Thank you. >>DOTTY PARKS de BLANC: Bart, thank you very much. Do we have any time for questions? >>CHRIS DISSPAIN: Yes. >>DOTTY PARKS de BLANC: Would -- does anybody have a question? Yes. [Speaker is off microphone] >>ANNEBETH LANG: I have to take the floor instead. Actually, I appreciate the work you have done. It's very good. It's a very good piece of work -- a very good -- for Gac -- [audio cutting in and out]. Yeah, it's very good, but I would like to add that I'm -- [audio cutting in and out] -- I could take that -- Gabby -- if we could have a link to document that everyone read before we come here, even if it has been on the Web site. I'm sure that will be of great help for many people, and if it's for discussion or for a decision or what we shall do with it. So just as a recommendation. >>BART BOSWINKEL: You mean something like this? >>DOTTY PARKS de BLANC: Well, I think we did have -- well, on one of the agendas, had links to the documents, but I'm not sure if it's the one that went out to the masses. Anybody else? >>CHRIS DISSPAIN: That is very helpful. >>DOTTY PARKS de BLANC: It is. It's a wonderful idea. Any other questions? Or comments? Or requests? >>BART BOSWINKEL: Maybe next steps is -- yeah. I think the next steps is that we want to -- if there is no real objection from the ccNSO membership, that we put it up for vote for the ccNSO council and get this done with. Say at tomorrow afternoon's meeting. And then they are -- yeah, they apply. So then we have to structure our lives. >>DOTTY PARKS de BLANC: Yes. I just want to thank Patricio and Slobodan and Bart and gabby very much for their help. >>CHRIS DISSPAIN: Okay. Thanks very much. Can you thank our committee? [Applause] >>CHRIS DISSPAIN: All right. So now the next session, which is due to start in about 4 minutes, is slightly unusual. New -- what are they called? NeuStar. Is sponsoring our lunch tomorrow, and they asked us if, instead of giving a presentation before or just after lunch, we would give some time instead to a group of law enforcement officers who are present in -- at the ICANN meeting, and asked if we would -- and it looks like a group of law enforcement officers entering the room as we speak. You guys are so obvious. So obvious. [Laughter] >>CHRIS DISSPAIN: This is an ICANN meeting and you got suits and ties on and, you know... And I say -- and we said, "Yes, that would be absolutely fine." So they're going to talk to us about accuracy and availability of WHOIS data. I guess what I should say is that this presentation by law enforcement is sponsored by NeuStar. Would you two -- I presume there's two of you. You always travel in pairs. Like to come forward? Thank you. So while they're getting themselves sorted out, just if I may, just one more thing, housekeeping. We're going to start at 9:00 tomorrow morning. Gabby sent an e-mail out. We're going to do the budget first thing. Most of you all know that there is a ccNSO members dinner tonight. It's full. We have 100 seats. We have 100 people coming. However, we also have some other people who would like to come but can't because we haven't got any room, so if you have told gabby that you are coming and you are not, please will you tell her that you are not? And if you have told her that you are bringing your wife and 17 children, and you are not, would you please tell her so that we can make some space for other people. If you are coming, you must be in the lobby at 8:30 tonight. We are not going to wait. We will set off at 8:31 1/2, so please make sure that you're there. It's a very short distance. We don't have to do anything other than walk down the street. Now, who am I handing over to? Scott? So Scott Aken from the Department of Justice of the United States. >>SCOTT AKEN: First of all, thank you very much for giving us a little bit of time. I know that you guys are as busy as we are. My name is Scott Aken, from the FBI, and also we have Paul Hoare here from SOCA in the U.K. And we had a rather large law enforcement forum here today, so we had a little bit of time and you guys had a little bit of time and we thought we would share a few of our concerns with you. I know I see a few faces in the crowd that I've spoken with before, but we wanted to -- [Laughter] >>CHRIS DISSPAIN: That's scary. >>SCOTT AKEN: And probably will speak to again, I'm sure. Hopefully under good terms. [Laughter] >>SCOTT AKEN: But, you know, a lot of people are -- kind of look and say, "Why is law enforcement involved in ICANN, and why does law enforcement come?" And by the representation there were 13 different countries here today, we had presentations from most of the large constituency groups. Everyone from the SSAC to IETF. We even had the CEO come in and give us a few words. But, you know, if you think about how crime and terrorism is now very rampant across the world and a lot of these things and these people are using the Internet to future this crime, so in order for us to catch these people, we have to understand the medium as well as they do. So we spend a lot of time understanding what decisions are made at ICANN and how they will impact our investigations. So a few things that we obviously are interested in that we follow very closely are WHOIS, as everyone seems to be very interested in these days. We also are very interested in things like DNSsec, things like IDNs. That's -- that's a big -- that's a big -- that's something very big for us. I mean, all of a sudden we have, you know, hundreds of different languages on the Web that we've got to work through, we've got to translate, we've got to figure out new processes for. When things are made available to the good people, they're also made available to the bad people, and the bad people seem to catch on a lot faster than the good people, so we definitely have to pay close attention to how this is implemented at this level and make our voices heard just like everyone else. We come to these meetings to speak to that people can get an idea of what our concerns are. Our concerns are really not a lot different than yours, just that we have access to the same information that everyone else does and that we can catch the bad guys. We don't want to violate, you know, anyone's rights, as much as people seem to think we do. You know, we are good people, just trying to catch the bad guys, and, you know, please feel free to catch us in the hallways as we're walking through to discuss -- you know, if you've got questions about things that we're doing or our various concerns on some of these things, please stop by. In terms of the ccTLDs, it's obviously very important that, you know, WHOIS is a word that's thrown around a lot. We all know that there is hundreds of WHOIS systems out there and most of you manage one of them, so if someone is registering nefarious -- or domains for nefarious use and we can get information to help an investigation off of those WHOIS systems, obviously we're very interested in that. National law is very difficult between countries. Treaties between countries are there and in place for some countries, but they take a long time. Sometimes these investigations need to happen very quickly. So having processes in place and things to understand how the data is there, how it's being used, is obviously very important for us. And not just for the U.S. I'll let Paul here discuss obviously they use dot UK a lot. I'll let him discuss a little bit about how they use and how they work with their ccTLD. >>PAUL HOARE: Good afternoon. I'd like to reiterate Scott's thanks for seeing us this afternoon and the fact that we are good guys. I don't profess to be representative of international law enforcement in general or even law enforcement in the U.K., but we are interested in this area, and we have been engaging with no, ma'am, I net around this issue. There are -- as Scott's touched on, there are jurisdictional issues and problems against jurisdictions and the time scales which are not insurmountable but very difficult for law enforcement in this particular arena, which I'm sure you'll empathize with. What I'd like to point out, on top of that, is how few offices across the world are actually engaged in this type of work, and we rely pretty heavily on the major banks, the security server -- not the security servers, the security companies, and anybody else who can assist us in this type of work, and their use of the WHOIS database is probably as important as ours. And that's something I really don't want to lose sight of. It's -- what we don't want to engage in, we certainly don't want to be in a position where we're contrary to you. We want to work with you to get a resolution which is suitable for everybody, and there are 13 countries represented here and I'm sure with a little bit more notice, there would have been considerably more, and certainly there's been considerable more interest noted. What I would encourage you to do is to consult with your own law enforcement, not take myself and Scott's word for the issues that are involved. I mean, we certainly will be encouraging your law enforcement that they come and see you and highlight their issues. >>SCOTT AKEN: A couple other things I want to mention real quick as well. I know that there's a lot of -- you know, WHOIS is obviously a big discussion point and we probably bring it up more than what we should. We certainly understand it's not the only issue. And the other thing I want to point out is we know that WHOIS data is not accurate a lot of times, but remember from an investigative perspective, a lot of times even the wrong data can help us lead to the bad person. You know, a lot of times criminals aren't the smartest cookies in the world, and they'll use the same information -- the same bad information multiple times. So even wrong information sometimes can lead us in the right direction, so I know a lot of the argument is, "Well, the WHOIS data is wrong anyway." That's not necessarily a bad thing. We have used that in several investigative steps to lead us to the right person. The other thing is, right now over at the GAC, there are 12 other countries represented, their law enforcement, that are, you know, speaking to the GAC. That's why we -- it's just us two right here. Otherwise, you'd have a whole crew of law enforcement that could state the same thing that we -- we're doing, and -- >>CHRIS DISSPAIN: The GAC is useful for something, then. [Laughter] >>SCOTT AKEN: Touche. But we have -- let me see if I can go through them all here and help me out. We have obviously the U.S. and the U.K. We have Switzerland. We have Japan. We have South Africa, Lithuania, Sweden, cypress, and maybe one or two more, but if those -- if you're from one of those countries, please let us know and we'll see if we can hook you up with the individual. They're going to be leaving here the GAC shortly. It would be great if you could, you know, talk to someone from your country and get it from them, too. Hopefully you're already in discussion with them. I know that a lot of the major ccTLD operators are in discussion with their local law enforcement to help. So I mean we didn't want to take a lot of your time. I know it's the end of the day. But we will, you know, happily take any questions if you have questions of us, please ask. >>CHRIS DISSPAIN: Thank you. Thank you, Scott. Do you -- I have some questions, but is there anybody else who would like to -- at this stage would like to ask some questions? Martin, do you want to go first? >>MARTIN BOYLE: Thank you. It's not so much of a question. More of a statement that, yes, I will confirm that we have been talking to law enforcement, but also to other people who have got quite a reasonable and legitimate need to have very quick access to WHOIS data. For example consumer protection people. But I think the comment I'd like to make is that within the U.K., we're subject to European data protection laws in the same way as other European countries, and subject to anything that Paul might say, we don't actually think that this is a major barrier to law enforcement, but rather, the important thing is ensuring that we do get the cooperation between the various actors and law enforcement to be able to respond to legitimate and very reasonable requests for support. Thank you. >>CHRIS DISSPAIN: Thanks. Did you want to talk about that? >>PAUL HOARE: I wouldn't disagree at all -- or I wouldn't dare disagree in this forum with anything that Martin said. [Laughter] >>PAUL HOARE: But certainly the EU and national law is something that -- as law enforcement, what we work to. And we wouldn't be encouraging anybody to be in any way in breach of any of their national law or the EU directives that are in place. What we want to do is find a common ground where everybody's requirements can actually be serviced, where certainly bad guys can be captured and put away and removed from the Internet, whilst we're actually complying with the laws there at the time. If the law is not suitable for that, then our role is to flag that to government and see what we can do about that, but certainly at the moment -- and the law of the land and the law of the EU is what we work to, and we'll continue to work to. >>CHRIS DISSPAIN: Thank you. I have a question. You said -- I think you said, Scott, that -- you talked about that accuracy doesn't necessarily matter, and I accept that. So what's more important to you? Is -- would you rather have instant access by going to, you know, www.whois -- in Australia -- .com.au to data that is inaccurate or access to data that is accurate that isn't instant. I mean in the sense that you might have to actually ask for it. >>SCOTT AKEN: That's a good question and I know we've been -- I've been part of several working groups that talked to a tiered access system that would obviously give law enforcement a specific tier to data that other, you know, groups or people would not have access to. In theory, that's great. The problem, I think, that what we've had, in discussing that, is more a logistical type of issue in terms of who is law enforcement, and it's as much of a problem for us as it is for anybody else, and I'm sure when you guys get some kind of legal process from someone in your country, you obviously do your homework to make sure that the legal process is coming from a legitimate law enforcement authority. So I think part of -- part of the discussions we've had and part of this tiered WHOIS working group that we're on, or that I was on, was how do we, you know, across the hundreds and hundreds of countries that we have in the world, how do we segregate that tier, that law enforcement tier that then we could actually get that information to. >>CHRIS DISSPAIN: But you're assuming -- you're either assuming that you have open access to the tier -- to that tier all the time, and if you don't, then you just have to -- you just have to enter into a -- I mean, you can ask -- sorry. I'll start again. Let me just explain to you what happens in Australia. We publish very limited data, so we publish the name of the registrant, we publish a registrant contact's name and we publish an e-mail address. Other stuff as well, but nothing of any concern -- consequence from a law enforcement point of view. Of course we have the rest of the data, but we don't publish it. And our data is probably 90% accurate. I mean it's -- because you have to provide information to show who you are. What we do with law enforcement -- and we do it also with -- as Martin said, there are other authorities. We have a competition and consumer council, for example, both state and federal -- is we have a protocol and what we do is we simply say, "If you want some information, you just need to ask us for it and just write -- send us a note." I mean, this sounds awfully wieldy, but it isn't -- unwieldy, but it isn't -- "Send us a note that says we're investigating Fred Smith, or whatever. Can you please provide us with the information on the following domain names or can you tell us what domain names he owns," et cetera. And that's -- the only complaint we've ever had, in respect to that -- I'm going to get to the international in a second. The only complaint we've ever had in respect to that was, one, from the Australian federal police who wanted to actually go fishing -- with an "F, not a "PH" -- in the database and we had said. It has to be specific. We can't -- our privacy rules won't just let you go and have a look. Now, is it not possible that from an international point of view, we could -- the same situation could be -- or is it just too cumbersome for you, that you simply can't do it? >>SCOTT AKEN: I'm sure, you know, we eventually could come up with some type of solution that would allow international authorities to get to you. But, for instance, say, a -- I'll use the U.S. as an example. A sheriff in a local municipality in Georgia has a child pornography case and there's a Web site hosting child pornography. Our state and local police work child pornography cases all the time, and they're accustomed to looking up this domain in an open WHOIS. That data goes away. Now we have to, you know, come up with some type of solution to allow someone, you know, that generally doesn't work a lot of cyber crime who are arresting people for drunk driving and speeding and everything else to get to that data, understand what the process is and get through it. It would take a significant level of effort to get through something like that. And that's just in the U.S. perspective. I won't speak for the other countries, but in the U.S. it would be -- it would be significant. >> Maybe I thought which we've discussed with people in Canada. I don't know where it's at right now, but one of the things we considered was exactly your problem and it's more a problem of coordination, law enforcement -- different bodies of law enforcement work well together. So if you just arrange to have coordination and one group as the access to requiring the data it can streamline the thing very quickly because then the registry is not looking at finding out if a law enforcement agent from your example is actually valid or not. They've got one main contact point from the federal task force which coordinates those inputs and everything can go a lot quicker. It is just a thought. And you could then do exactly the same thing on the international level, which would probably speed up your stuff quite a bit, too. >>SCOTT AKEN: We actually talked about that very thing because, you know, I think someone in the working group said, you know, FBI, why don't you just go ahead and put a point person where the 57,000 different municipalities in the United States can call. Well, that certainly becomes more than a person and becomes a large department. So I think it's more of a coordination thing, like you said, absolutely. And it would be something that would take a long lead time and some certainly above my pay grade to set up. >>CHRIS DISSPAIN: Patricio is next. Could I suggest to you also whilst I acknowledge and accept your example, it seems to me if you are talking about a local sheriff in Georgia who doesn't know any of this stuff, then actually inaccurate information is quite dangerous. If he thinks that information is accurate or he makes assumption about that information, I would suggest that could actually be quite dangerous. Patricio? >>PATRICIO POBLETE: Patricio Poblete from NIC Chile. I wonder how you could handle phishing incidents, phishing with a P-H. In Chile, we are notified that something like that is going on, we usually do not take an action as a registry. We pass that information on to the police or to ISPs. But a meeting like this we sometimes get people from the organizations that combat phishing. What they say sometimes is that going to the police or going to the courts takes way too much time, that there is a very short time window to react. Sometimes hours, so they need someone like us to take action for it to be effective. Kind of like the time is so short that we can't afford the luxury of due process, okay? So what are your views on this matter? >>PAUL HOARE: I think that's exactly right. I think time is of the essence in a lot of these matters. As I touched on earlier on, there are only finite resources dealing with this in law enforcement across the world. If we need to then deal with the WHOIS inquiries for all the major banks for all the phishing, it is not going to get done. That's a realistic view. We would have to prioritize our work and if we need to do all the inquiries for all the security companies, all the phishing, all the people who are affected by phishing, by the time we've gotten around to it, they have moved and if you look at the way the Fast Flux works and how phishing is evolving, it is measured in hours, minutes a phishing site is actually active. And if it needs to come through us, it is a very, very realistic proposition. >>SCOTT AKEN: I would agree as well. The companies like the anti-phishing working group, the context they have and the speed that they can move, law enforcement cannot move that fast, requiring subpoenas and also working overseas, outside boundaries, we can't work as fast as what they can. >>CHRIS DISSPAIN: So you would actually take -- you would actually take action on their say-so? Because that's what you are actually asking us to do. [SPEAKER OFF MICROPHONE] Actually, I happen to agree there are ways around this, that you can do this. What you are actually saying is that we should -- we as runners of a ccTLD -- should perform -- should turn someone off on the say-so of an organization that is not law enforcement, that is not government, that is actually -- in the case of Australia, Queensland University I'll assert. I'm not suggesting they get bad information because they don't. I am trying to illustrate the difficulty from the point of view of actually taking the action because all they are is an university computer department. Sorry? >>PAUL HOARE: I'm certainly not advocating that you turn people off on the say-so. I'm not sure you would turn people off on the basis of law enforcement saying so without a judicial process. >>CHRIS DISSPAIN: That's probably true. Yes, under certain circumstances. >>PAUL HOARE: But the actually -- >>CHRIS DISSPAIN: You want the information. >>PAUL HOARE: The WHOIS information is important because then they can approach the ISP and the ISP can make a decision to turn people off. >>CHRIS DISSPAIN: I'm sorry. You can do that on our restricted WHOIS. I want to take Keith and then Bernie. >>SCOTT AKEN: Just a quick comment. The way that -- I would never tell you to turn somebody off either without you having something within your acceptable use policies that you also deem that that site should be taken down based on your acceptable use policies. So I would go based on your own decision, not on someone telling you to do something. >>KEITH DRAZEK: In the dot U.S. registry, over the last year we have built a small team within the company that actually looks at phishing activities in the dot us domain and other malware and botnets and things like that. We do take proactive action and we do, as Scott mentioned, we do have an acceptable terms of use policy that allows us to take down a domain name if we determine that it's causing any type of stability issues or confidence issues in the domain. So we actually do -- and we do take comments and recommendations from law enforcement and from groups like the anti-phishing working group. But we determined that we had to build our internal capability to be able to make that judgment for ourself because there is some legal liability for taking somebody's domain down if you're wrong. I guess my comment is we do it, we're proactive. We do take recommendations from external sources; but we've taken the responsibility to make a judgment of our own rather than taking it at face value. Again, back to the WHOIS data, we've been able to detect a pattern of these registrations based on the WHOIS data that's registered, whether it is accurate or not. So, again, the importance of the WHOIS database to us is critical and I think it is also to the law enforcement agencies. >>CHRIS DISSPAIN: Thanks, Keith. Bernie? >>BERNARD TURCOTTE: Just following up on the point before where you said -- well, you know, you considered coordination and it becomes more than one person. I think that's the issue that's going to end up between us, the registries that have a privacy policy on the WHOIS versus your requirement. And I think really maybe what we're heading to is there is going to have to be a common ground. Because the registries aren't interested in having a huge staff that are going to deal with all the different law enforcement inquiries that can come from all the different levels. That doesn't make sense either. So there is going to have to be some sort of middle ground where both people can be happy that things are coming through in the proper format and being provided to the right people. >>SCOTT AKEN: And we welcome that. We're open. We've now been at the last ten or 12 ICANN meetings. We're around. I'm sure you have seen us before. We're more than welcome to come in and have discussions on this stuff. I mean, obviously we're not policymakers within our own organization and we can't make multi-million dollar decisions on creating new departments. But what we can do is certainly take that back, take that back to our organization and say, "here's what's going on and these are the recommendations we would like to make." Just the same as you do with your own organizations. We certainly don't want to, with any of this, cause the registries any more cost than what they need to -- they need to already incur for day-to-day business. We don't want to add a layer a cost of that on top to help law enforcement. >> Hi, Byron Holland from Canada. As of June 10 we just masked our WHOIS data which was a moderately contentious (audio cutting out). We have tried to find a balance, and it is still a work in balance in doing what part of our privacy law requires, what we think is the right thing as well. In addition to trying to find accommodation to other interested stakeholders, and in Canada the RCMP has been the primary representative of law enforcement in dealing with it. We effectively have tiered access based on both what we do for a living, to run the network and ensuring the security of the network as well as the particularly egregious nature of child porn or in our law we have a limited child endangerment. So for everything else, we require a production order, sort of the [inaudible]. Roughly a two-day process. So not perfect, some delay but not terrible either. The two other categories I listed, we have an administrative procedure which could be almost immediate, as fast as they can fill out documentation we will provide the information to them. Now we do set a relatively high bar on the information required and they are simply required to certify that it's true and accurate. But we have found a path, I think, that addresses some of those -- the needs that you articulate, yet maintains the privacy of individual, by and large, so their data is not on the WHOIS to be scraped off at who knows what time. So it is a path that, I think, is trying -- has found a balance and 12 months from now we will also have a public consultation to see is it working, people to be able to redress any concern. So it is brand-new. It is still to be tested live right now. But we think it is an appropriate balance that the RCMP has represented all law enforcement in Canada for. We are working with that single point of contact and they represent us to all the other chief of police. The two things, one single point of contact which, as Bernard has talked about, critical to us because we simply don't have the resource to deal with 57,000 municipalities and then to specific [inaudible] that have a high administrative burden versus a court order. >>CHRIS DISSPAIN: Thanks. >>PAUL HOARE: I think certainly law enforcement worldwide is watching with interest what happens with Canada and the experiment that you're going through at the moment. I will question whether the two days is not onerous in certain types of crime. Two days is an awfully long time. >>CHRIS DISSPAIN: I must admit, I actually agree with that. In Australia what we do, it is, basically, all administrative, you just have to ask. We might say, All right, you know, tell us. We are not just going to give it to some bloke without asking. It has got to come from the agreed source that says you are the source of the South Wales police, et cetera. It could come from various different places. It is not just one. We would say court order we would need for mass information. If you are saying you are investigating something, then it actually works. I think it be interesting to see how it goes with Canada. >>SCOTT AKEN: We actually have a the RCMP here next door. They're talking with some of the GAC folks right now but I think they're going to be talking with some folks tomorrow for lunch and they are actually going to give a presentation on that. So it will be good to hear both sides on how the RCMP thinks things are going. >>CHRIS DISSPAIN: Do we have any other questions? I think we're about done. Do you want to close off with anything? >>SCOTT AKEN: Just once again, thanks for your time. I know it is late in the day and we still have a full room. I appreciate you sticking around. Feel free to grab us in the hallway. >>CHRIS DISSPAIN: Gently, gently, very gently. >>SCOTT AKEN: We're more than open to speak with all you and we have the same concerns that you do. You have family members, you have friends, we want a safe and secure Internet as much as you do. So that's all we're trying to get to and we certainly don't want to put any burdensome processes on top of the stuff you already have to do. >>CHRIS DISSPAIN: Okay. Please thank Scott and Paul. [ applause ] Okay. Gang, that about wraps it up for the day. We've got budget 9:00 followed by a fun-filled morning of IDN ccTLD fast-track stuff, breakfast for the council. I have done all the stuff, everything I think I needed to do. So see you all if not later on, then in the morning. Thanks.