CcNSO Member Meeting Tuesday 12 February 2008 ICANN Meeting New Delhi, India >>CHRIS DISSPAIN: Good morning, everyone. We will start in about five minutes. Good morning. Can you hear me? >> Yes. >>CHRIS DISSPAIN: I'm coming through the speakers. Excellent, marvelous. Good morning, everyone. This is an extraordinarily long room, although I think we've had longer ones before now. We are supposed to be starting this morning with a session with Paul Twomey and -- You can't hear me? [SPEAKER OFF MICROPHONE] [ Laughter ] >>CHRIS DISSPAIN: That any better? Hello? The sound coming out of those two speakers in front of you, Eberhard? [SPEAKER OFF MICROPHONE] >>CHRIS DISSPAIN: Maybe it is the microphone. Can I try this one. Can I have this one on, please? I have to turn on my own microphone? Surely not. Surely there is a man that comes and does that for me? Is that any better? >> Yes. >>CHRIS DISSPAIN: Okay. We'll use this one. We are supposed to be starting with Peter Dengate Thrush and Demi and Paul Twomey, but they've disappeared. Some of you may know that Paul and Peter left here at 6:30 last night in a car to go to the Bollywood cocktails in order to get there early to give a press conference and the driver took them to the Crown Plaza in Delhi instead of the Crown Plaza in wherever it was that we were, which is actually another city and so it took them 2 1/2 hours to get from here to Bollywood last night. So maybe they're still asleep. I thought I'd -- I'm standing up because I can't -- I want to try and see everybody. I will sit down in a minute. I thought given they're not here yet that we might take the opportunity to tell you about what the council did on Sunday, which was to have a whole day to create a work plan for 2008-2009. Patrick Sharry came and helped us to do that. And we had a session on the agenda for 11:30 to talk about it, but it is one of those things that we can kind of talk about for a bit and then leave and talk about some more if and when our guests ever arrive. Is that as good? Eberhard has his hand up already and we haven't even started yet. >>DR. EBERHARD LISSE: Would you please call them in the future not Paul and Peter but Peter and Paul? [ Laughter ] >>CHRIS DISSPAIN: Yes, so we can rob one to pay the other. We just need a Mary, don't we? Then we're done. Okay. So, we will put the notes of the work plan meeting on the Web site once we've actually got them sorted out, but I thought it might be useful to just discuss where we've got to so far. And the way that we split it up, we split the calendar up by -- into three per -- three sections for each year so there was up to and at the first meeting of the year, up to and at the second meeting of the year, and up to and at the third meeting of the year. That's the ICANN meetings. So for Paris -- Gabby, do you have the notes on the process stuff? The list of the things that we're going to create processes on? >>GABRIELLA SCHITTEK: Yes. >>CHRIS DISSPAIN: Okay. One of the things we've decided to do was we thought it was important to have a series of processes so that -- that were kind of set so that everybody knew where we were. So we've identified that we need to have a sort of template and process for the agendas of members meetings and council meetings. So, for example, we would expect that that would mean that at every members meeting, certain things would always happen. There would always be a session about latest issues in ICANN, and there would always be a session about certain other things. So we need to put a process together for that. We're also going to create a process for ICANN planning which, basically, means that ICANN has -- ICANN has two rounds of -- every year, two rounds of consultation always which is strategic plan and the operational plan. One of the things that we have not been great at in the past is getting ourselves organized properly so we can make submissions to the strategic plan and to the operating plan. So we're actually going to put in place a sort of little system that means that at the appropriate meetings in the year, we always have on the agenda whichever plan it is and then we can then start to make the submissions in the right time. We're going to standardize our minutes and our resolutions. We are going to have a standard process for elections so that all that happens when an election comes along is that Gabby hits a button and effectively everything rolls out and is always done in the same way. We're going to -- we're going to work through the current membership application process. We've changed the membership application form, but the process itself is still a little bit difficult for some people so we're going to have a look at that. We're going to create a series of working group guidelines so that anybody who is in a working group knows how the working groups will work and so on. So the issues that we've identified that need to be dealt with between now and Paris are obviously the IDN fast-track and in Paris, hopefully, we will be able to consider the final report of the IDNC working group and see if we can support that and, if we do support it, then submit it to the board. I'm sorry? >>GABRIELLA SCHITTEK: [SPEAKER OFF MICROPHONE] >>CHRIS DISSPAIN: No, they won't. We have coffee at 10:30. Where are they? >>GABRIELLA SCHITTEK: [SPEAKER OFF MICROPHONE] >>CHRIS DISSPAIN: Do they have the wrong agenda? >>GABRIELLA SCHITTEK: Yes. >>CHRIS DISSPAIN: Okay. Where was I? Ah, yeah, okay. Demi's here. Hi, Demi, you're the only one. >>DEMI GETSCHKO: I suppose they are coming. [SPEAKER OFF MICROPHONE] >>CHRIS DISSPAIN: Is he coming now? >>DEMI GETSCHKO: I think so. His agenda was something -- 10:00. >>CHRIS DISSPAIN: Come and sit. Sorry, everybody. So the fast-track is obviously something that we're going to need to deal with in Paris, and, of course, there will be stuff to do on the fast-track between now and Paris because the documents will be published. Also in Paris, we'll need to look at the ccPDP and there will be input and feedback on that. We'll in Paris the results of the anti-phishing survey, which Gabby has sent out. >>GABRIELLA SCHITTEK: No. >>CHRIS DISSPAIN: Not yet? It will be sent out soon, the anti-phishing survey and the participation working group survey interim results. So without going through everything that we're going to do, what we've done, we've created a list of things that for the next meeting and the meeting after and the meeting after, which is obviously constantly going to be updated, and a list of things we have to do in the lead-up to the meetings. And we hope that that will make things -- it will be easier for people to bring things to the table, to bring things to the meeting to talk about and will make it easier for us to keep track of what it is we are doing or trying to do. Did I miss anything -- did I miss anything out that anyone else who was there thinks that we should say? Anything specific? Nope? Okay. One of the things that we spent some time doing on Sunday was identifying topics, things that we can see in the next couple of meetings might be interesting to talk about and those things include, for example, DNSsec, wildcards, and so on. But we would very much appreciate it if you told us, also, things that you specifically would like to have on the agenda. That will be very helpful. So there is a particular thing that you as a ccTLD manager want us to have on our agenda, it would be great if you could send us a note about that. And we're also going to start -- from Paris, we're going to start each meeting with a small -- with a short session to update everybody on where everything is in respect to the ICANN issues that we are actually involved in. So at the beginning of each meeting, there will be a little session that says, "Okay, so since the last time we were here, this is what's happened, and here are some new things that we need to look at and here are the things that are ongoing." So we'll do that as well. And that, again, hopefully will give some context to the flow of work between the meetings. One other thing we -- I think -- I can't remember whether it was the last meeting or the meeting before but we talked about setting up a mailing list for ccTLD managers. Currently, we have ccTLD -- we have a ccNSO members mailing list and we have the ccNSO Council mailing list. But what we talked about was actually setting up a mailing list that would be for every ccTLD manager, nothing to do with membership, nothing to do with the ccNSO as such but an authoritative, if you would like, mailing list. We currently have a draft of a letter to go out to all ccTLD managers which the council will hopefully approve on -- is it Wednesday -- Wednesday tomorrow, on Wednesday. And we've registered a domain name which is ccTLD-managers.org, because we didn't think it was appropriate to put it in the ccNSO necessarily. That would be difficult for some people. So we've registered -- well, actually I've registered so I now have all the power -- I've registered the domain name. It is currently being hosted on our -- on Australia's AUD servers in Melbourne and the mailing list has been set up. Once we approve the letter to go out to everybody, then we can go live, people can subscribe and we'll figure out what service to put, whether to leave it where it is, et cetera, at some point. So that will be helping relatively quickly. And I think I've probably just about covered -- give me one second. Okay. No, there are a couple of other things. One of the other things we're going to do again starting in Paris and we'll continue at every meeting is to have probably on the day before the start of the members meeting, so in this case yesterday, the Monday, to have a small session for new -- any new ccTLD managers or new people -- people who haven't been before or people who haven't been for a long time to just kind of catch up on how we work and have an introduction to the ccNSO. So we're going to be doing that. And I specifically wanted to raise one other issue which kind of came out of -- was discussed on Sunday but has actually come out of the conversations we've been having with the GNSO over the last month or so. We currently have an ALAC liaison, so Ron Sherwood who isn't here at this time, but Ron is our man in the ALAC and he goes to their meetings and checks everything is okay and Jacqueline Morris is the ALAC liaison to us. I don't think she is actually here yet, but anyway... What we don't currently have is a liaison with the GNSO. And that's something that we -- we used to have -- we had for a while a liaison. I think, Young Eum Lee, you were our liaison. I can't remember who their liaison to us was. They had somebody they sent us, whatever. And then it kind of stopped because there didn't really need to be much need for it and there wasn't that much going on, et cetera. But it is pretty clear for those of you that were at yesterday's meeting as councillors or observers, it is pretty clear that there needs to be a significant improvement in the communication between the two Supporting Organizations and actually having liaisons might help with that. The problem with it is that if you are the person who is our liaison to the GNSO, because their meetings effectively take place at the same time as our meetings, then you end up being in the GNSO the whole time and not being in the ccNSO. So the job does need to be done by somebody who's prepared to accept that in order for them to liaise properly, they are going to have to be in the GNSO meetings, not in the ccNSO meetings. So it's something we're going to have to try to think about and see if we can get someone to volunteer to do it. But I certainly think it is worthwhile, if we can organize it. I think I haven't missed anything out, have I? No. Okay. So you'll be seeing some stuff coming up on the Web site and on the members list relatively soon, just with sort of notes about processes that we're putting together and so on and hopefully by the time we get to Paris, all of this stuff will have happened and we'll all be finding it a much smoother environment to work in. Demi, would you like to kick us off with some board talk? >>DEMI GETSCHKO: Good morning, everything. I have no presentation to give. I suppose we can use the time -- okay. Sorry. >>CHRIS DISSPAIN: Shout. >>DEMI GETSCHKO: Now is better. >>CHRIS DISSPAIN: Yeah. >>DEMI GETSCHKO: Okay. Sorry. Then I have no presentation, no formal presentation. But we can exchange some ideas and discuss some issues that are actually running at the board level and may be of interest of the community. Particularly my point of view. These days, in the last meeting and this meeting, we are basically discussing budget. It is not really something that has much information to give -- oh. >>CHRIS DISSPAIN: Rescued, Demi. >>DEMI GETSCHKO: Rescued. I am rescued. But just to talk about one or two points that we are discussing now regarding specifically to the cc community. I think it would be very useful if we can come with a definition of what is the characteristic of a CC, and I will say why. Because there are always, at the board level, some discussions about if we can define a CC just as a table. Then the 3166 table defines what is a CC. If you are in the table, you are a CC. Fur not in the table, you are not a CC. If we keep this kind of very narrow way to see the things, maybe we can face some problems with the beginning of the placing of IDN ccTLDs because the IDNs of course are not in the table. In my personal opinion, the concept is much more explicit than the simple table. The table is our way to express the listing of abbreviations for what is the country code ccTLD, but maybe it's a good idea as a community to come up with kind of a definition that can be used when we discuss these issues. Another point that we have to be aware of is that there is some talks going on about if the advent of the IDN ccTLDs will give rise to a different kind of relationship or it may be a different kind of contract between -- or agreement, or whatsoever, between ICANN and the cc's. If we can really define in a very clear way what is the nature, what is the characteristic of a CC, I suppose we can use this to classify, to put the IDN thing under the same concept, and then under the same kind of relationship. If we cannot be -- if we will not be successful in defining in a very precise way this, maybe the IDN have some kind of treatment that's different from what we have right now. Just to raise some preoccupations I personally have and we are seeing this being discussed in these days. There is a lot of other points. I'll give the floor to Paul Twomey. >>CHRIS DISSPAIN: Who is going first? >>PETER DENGATE THRUSH: Me. >>CHRIS DISSPAIN: I should have known. Stupid question. There you go, Peter. >>PETER DENGATE THRUSH: Good morning, everybody. My name is Peter Dengate Thrush and I really probably should be sitting in here because I'm really a ccTLD manager who somehow escaped to the board and was elected the chairman. Let me just give you a quick rundown of what we've been doing and I don't want to reprise Paul's very comprehensive report from yesterdays but some of the highlights for us at the moment, new gTLDs. And as Paul said at that meeting, a huge amount of work -- and I'm sorry, I haven't been here for Demi's report, so if I cross and cover anything again, bear with me. You probably don't look across into the gTLD space as often as the people living in the look across-here. The gTLD space is about to be enormously transformed. The potential under the new rules is going to be for literally thousands of new gTLDs and it's going to have an enormous impact on a number of things, including the structure of ICANN and one of the structural consequences of this may well be the differences between registries and registrars becomes so blurry that that distinction becomes meaningless. It's going to have enormous impact on staff, and on ICANN revenues. It could be one of the -- well, it's likely to be one of the biggest things that's happened to ICANN since we formed. A subset of that, of course, which you're much more concerned with is the IDN TLDs, and even more concerned with the fast track, and I think all I'll say on that, because I think Chris says you haven't yet discussed the meeting that you've had, is just to say that I and the rest of the board are very pleased with the way the initial friction that seemed to be developing has been, first of all, acknowledged and then a solution mechanism put in place and what looks then to be like a resolution mechanism coming out of that discussion. So I wish you well with that. If the board, or the staff can help in any way, let us know, because obviously a solution that you two come to is going to be -- going to be far better than anything else anyone else can do. Perhaps the thing I want to spend a bit more time on is the Joint Project Agreement, the midterm review of our -- one of our arrangements with the United States government, and if I could perhaps just stress something that came up in the meeting we've just had with some members of the GNSO. There's kind of a language developing around this that I'm not very happy with, and I want to encourage you not to adopt, and that's talk of ICANN being liberated or freed or released or some kind of concept of a removal of obligations. That is exactly the opposite of what I'm talking about. I'm talking about ending a contract which actually has very little restraints in it. If the U.S. Department of Commerce wanted to do something to ICANN beyond inviting us and encouraging us, it would not be through the JPA. The JPA is not the mechanism for controlling ICANN. And ending the JPA is not about releasing ICANN or going free. We will still have in place strong links to the United States government that the JPA doesn't address. What I'm actually talking about and what I want you to think about and contribute to is how we increase the obligations of ICANN, how we improve and enhance the accountability mechanisms to all of the Internet community. So very far from it being a freeing or a releasing of ICANN, think of it as a way of binding ICANN more tightly, more responsibly, more accountably to the entire Internet community. So it's more than just a terminological exercise. It's actually a very important legal, cultural, institutional issue. Would we are talking about is more ties, ties that you want so that you feel that ICANN is safe from capture by any particular entity, safe from being swayed in any particular direction of policy-making that you are unhappy about, and so that your voice in ICANN can be properly heard. Okay. I think we've probably talked about what's going to happen. We are -- there's a public comment period about current performances under the JPA. There's going to be a meeting in Washington, a public meeting held by the Department of Commerce, to review submissions and hear from people at the end of February. And then there will be a period of consideration and ultimately the USG will publish a report. We are working with them. This is a joint project and there's a considerable amount of joint work being done in the review. And leaving off from that, the other topic that's occupying people here considerably is GNSO review. The Board Governance Committee has assumed responsibility for the obligations under the bylaws for a very complete review of all ICANN institutions every three years. In September 2006, the organization which had been commissioned to review the GNSO report, the London School of Economics, was hired. They came in, reviewed, analyzed, did the usual review, and published a report. Since then, a subcommittee of the Board Governance Committee has been working to consider that report and come up with recommendations for reform, improvement, review of the GNSO. They have just done that, and a considerably detailed report with supporting appendices has now been published. That's causing the GNSO considerable concern, not so much at the suggested changes of working mechanisms. I think they welcome that. They want to improve the method of doing the work. The issue for them is the structure of the council and the voting. We're working with them to resolve that. So those are -- while we're here -- the current issues that are occupying us and perhaps now I'll hand to Paul to go into detail on any one of those. >>CHRIS DISSPAIN: Peter, sorry. Just before we go to Paul, can I just ask, there's one thing missing from there, or at least maybe -- maybe more than one, but one thing that I've seen, which is the NomCom. What's happening with the review of the Nominating Committee, which is -- which is finished but... >>PETER DENGATE THRUSH: Yeah. There is, again, a review of the Nominating Committee, and that has, so far, taken the form of hiring some consultants. What we do with each of these reviews is publish a terms of reference for that review, so everyone knows what it is that's being reviewed and what we hope to achieve. Interisle, a consulting firm, reportedly on that at the end of last year, and there were consider -- a number of meetings in Los Angeles as we explored with the consulting firm what exactly their report meant. They were questioned and so forth and that's where that has sat over the Christmas vacation period, but that's now under review in terms of going through the same process of the GNSO review. Turning that consultants report into a serious of recommendations. So the answer is watch the space. That will be coming up. >>CHRIS DISSPAIN: Thank you. Paul. >>PAUL TWOMEY: Thanks. I think I've got very little to add. Perhaps I just would make the following observation about the JPA review. We appreciate that many of you have been working on submissions or have been putting down in writing things that you have been saying in this fora and other fora previously, and we think that's excellent. We thank you very much for that, and I think you should take this opportunity to make the points that you think are important. While I agree -- I absolutely agree with Peter that this, you know, when do you get independent/liberty/free language is not particularly useful and it's sort of journalistic interpretations. You get these phone calls from journalists, "When are you going to be independent?" Well, it's a bit silly in terms of the way we actually work. I would make the observation that several of you have raised that part of the mix going forward is not just the JPA but other aspects of things in the environment. I know some of you, for instance, have mentioned that in the review of the transition or, you know, this final stage moving to that sort of environment, what's the -- what is the status of the IANA operations. I know that some of those -- you know, the root zone management issues are close to some of your hearts. I just want to say I think that's probably useful, at least it's a true expression of some of the concerns you have, and I think it's probably useful to the Department of Commerce and ourselves to the community generally for you to put your concerns or your issues firmly on the table at this moment. That's what's being called for, and I think now is the time to say that, so I just wanted to reinforce that as a message. I think apart from that, it's probably just best to move to questions. >>CHRIS DISSPAIN: Okay. So as usual, now is your opportunity to ask questions of Demi and Paul and Peter. Or go for early coffee. Olivier. >>OLIVIER GUILLARD: Hello. Thank you very much. That's a question, I think, to Demi. >>CHRIS DISSPAIN: Olivier, just for the benefit of the rest -- >>OLIVIER GUILLARD: Oh, sorry. Olivier Guillard from dot fr. Just a question to Demi, you mentioned a discussion about the nature of what a CC is would be interesting. I was wondering if you feel that this discussion would have an impact on the fast-track agenda for IDN, or is it linked or is it something else? >>DEMI GETSCHKO: No, I don't think that it has an impact directly on the fast-track agenda, but I suppose it would be useful if we can come with a good definition, because in my point of view it's very -- it's a very poor definition to say that we are just the mirror of Table 3166 dot, period. If we are just this. The concept of an IDN ccTLD can be viewed in different ways. And I suppose it is in the interest of the CC community to join both concepts, the IDN cc's and the traditional cc's in the table under one unique concept, one unique umbrella of ideas. Not to have the split between what was the old cc's and what is the new IDN cc's. These may have consequences that we don't want to face, maybe. >>OLIVIER GUILLARD: So it's a general discussion? >>DEMI GETSCHKO: Yes. >>CHRIS DISSPAIN: Roelof. >>ROELOF MEIJER: Roelof Meijer, dot nl. Peter, you refer to strong ties to -- between ICANN and the U.S. government that were not arranged through the JPA. Somehow I got the impression that you were not only referring to the IANA contract. Could you explain a bit further? >>PETER DENGATE THRUSH: Well, thanks for that. Yes, the -- well, the primary one is the IANA contract. The other one is the link that we have in a tripartite arrangement between the U.S. Department of Commerce, VeriSign, and ICANN. And that's a very complicated matter which goes back to the days when the contract to run dot com was not with ICANN but was with the U.S. Department of Commerce. So there's a relationship there which includes, for example, the requirement that we have to consult with the U.S. Department of Commerce in relation to pricing in dot com. So there are -- there are links. VeriSign is also -- plays a major role, if you like, as the manager of the root, and so changes, et cetera, go from us through that. So there's that. The other more fundamental ones which we touched on yesterday are things like the fact that we are incorporated in California. The way we're incorporated in California is as a not-for-profit which gives us a tax advantage in relation to U.S. federal law. So we've got obligations under the state corporation's law, obligations under the federal taxation system. Paul, have I -- are there others? And -- >>PAUL TWOMEY: Just in the detail, we are a 501(c) entity under the U.S. tax code which makes us formally a charity, which is the way in the nonprofit aspect is dealt with. And we also have obligations, you'll see in the transparency and accountability framework, being a not-for-profit public benefit corporation under California code gives the attorney general of California some reasonably vaguely described, but nevertheless supervisory, powers in the case of misbehavior. >>CHRIS DISSPAIN: So if you're a charity, then I can get a deduction for what I pay you, right? [Laughter] >>PAUL TWOMEY: You and I can deal with that later. >>CHRIS DISSPAIN: Young Eum. >>YOUNG EUM LEE: Yes, I have a question about the new gTLD process and Peter mentioned that there was going to be a great change in the number of domains and -- I mean, number of new gTLDs and IDNs being issued. Actually, my -- I was under the impression that their new gTLD process was maybe primarily geared towards the IDNs, but now I'm hearing that it's not. It's -- I mean, you're just considering a tremendously large number of new gTLDs. Can you explain that a little? Thanks. >>PETER DENGATE THRUSH: Yes. There are two different processes which come together. The urge to have a process for increasing the g space is deep in the history of ICANN. It's included as one of the obligations in the very first MOU signed in September of 1998 that -- that's one of the reasons for forming ICANN. There's been two rounds, the 2000 round and the 2004 round and it's always been fraught with difficulty partly because there's technical challenges but also the policy challenges. And just to paraphrase this very briefly and probably very badly, we have, on the one hand, for example, the intellectual property constituency and large businesses with famous brands who see every new gTLD as an enormous problem. That's where they have to go and fight another round of cybersquatters. So there's a tendency from that community to say "No, none at all," and a community of registrars who are enormously inventive, who make their business out of meeting customers and trying to sell them new gTLDs and new services in relation to gTLDs saying, "Yes, give us thousands because we can see a huge financial up." So there's been -- as I say, very badly paraphrased -- that kind of tension. But over two years, the GNSO has worked very diligently, including lots of -- or several intersessional meetings outside of the standard ICANN meetings and they have produced this huge set of policy recommendations saying, "Here's what we want" and the staff has been busy working on that since at least the Los Angeles meeting, going through and saying, "Well, if we adopt this policy, how would it work? Can we implement it? What's required?" And just by way of one example of how that's working in relation to the 20 different policy recommendations, there needs to be some kind of dispute resolution mechanism, so that if somebody applies for, for example, dot Chris and Chris thinks that's not very fair, you know, is there a way for Chris to oppose. And so we've had to go and explore what kind of disputes may arise, and then find dispute resolution providers who can help us write a mechanism, a process, for resolving that kind of dispute. Just a quick update on that. Of the 20 policy recommendations, the general feeling I have from the staff is that they don't think that any of them are unimplementable, but about four at the moment are looking as if they're going to raise considerable problems of implementation. So there's a process that we now have to go through where we may, in fact, go back -- the staff are going to go back to the GNSO and say, "Well, look, you said you wanted to do this. Here are the consequences. These are the difficulties. Would you like to think of -- have another look at this policy to see whether it's going to work?" So that's been going on, young Eum, completely independently of that other strand that you mentioned, which is driven largely by -- we call them the "foreign script community" saying, "We want TLDs in foreign scripts," work going on in the IETF to solve the technical problems, being able to put it in on the left-hand side of the dot in about 2003, and then eventually solving the technical problems for putting it to the right of the dot perhaps last year. As it happens, they will go through that new gTLD process as well. So two different processes come together when we look at introducing new gTLDs. >>DEMI GETSCHKO: Let me add something. This is not clear, and we have to wait for the definition of the policies and those are the definition of the requests for proposals that we will be working on in the next month. But as I see -- and this a little bit worries me -- is that the new wave of gTLDs does not preclude to have end users registering names at the root. This is quite different than what we have now because now we have registries at the root, they sell the domains to registrars that sells to the end user. The -- if you go to have end users at the root, then we don't have the equivalent registrar doing the service for the customer. I'm not sure how this will impact. Maybe this is a kind of solution between the pressures of the trademark people and the pressures from the registrar community, registrar/registry community, but in my view, this in some way dilutes and in some way is against the structure of DNS, the well-structured tree of transfer of authority, of starting off authority and transferring to the next level. Just a comment on this. I'm not sure if I am reading rightly the things. I'm not sure if this is a characteristic of the new phase of gTLDs, but of course this will affect the Internet as a whole. We are a support organization. We have to be aware of. >>PAUL TWOMEY: Perhaps I can follow on from that topic. I think it's a very important one. Part of the work that -- in Los Angeles, we discussed with quite a number of the registrars and which is part of the implementation work being undertaken by staff is we actually commissioned outside economists to look at the issue of benefits to consumers of the two-part structure of registries/registrars. It partly, frankly, comes down to some interpretations of the existing gTLD contracts, and potential interpretations that -- I want to be careful what I say here because of the lawyers. But one interpretation says that the contract says there must be a separation of registries and registrars, and another interpretation says that a registrar could not be a registrar in a market with the registry. So this is a legal definition. So everybody, rather than getting caught with "My lawyer says/your lawyer says" at this stage, what we've actually asked is for our outside economists to actually doing some work on this. It's not complete. I'd recommend everybody who wishes to have input to that to let us know because we'd be happy to have that -- to have the economists look at that. The perspective that I've asked the economists to look at is from the consumer perspective. You know, what is -- you know, in terms of the G market, we have had certain -- it strikes me certain competition benefits to the consumers of that two-part structure, and I want to get an economists' perspective about that and they have been comfortable to do that. >>CHRIS DISSPAIN: Can I -- thank you, Paul. Can I just go back a step on the new gTLD process? Can anyone -- any of you take a stab at -- no. Are the difficulties with the four policy points likely to see significant delays in launching -- if it's got to go back to the GNSO and go through a whole process again? Is that likely to be a significant delay. >>PAUL TWOMEY: The present timetable still envisages that there will be something by the end of the year in terms of some round being commenced. >>CHRIS DISSPAIN: Yeah. >>PAUL TWOMEY: But I suspect that timetable is very close to the end of the year, and there was talk -- there was talk -- there was talk 18 months ago that perhaps it would be earlier in the second half of the year. I'd have to say now it's more likely to be in the second half of the year. >>CHRIS DISSPAIN: Okay. Fine. To some extent it has an implication for us in respect to the fast-track, because some of the original intention was to try to dovetail if we could. I also have a question about the JPA. I think there may be some confusion about what the ICANN submission is actually asking. A number of people have interpreted it in conversations with me as ICANN saying, let's tear up the JPA and get on with it, get on with whatever it is we're going to do next. But in the conversations that I've had with staff, it seems to be more let's let it run to the end. And in the time that it is running to the end, figure out what it is we're doing next, which is it? >>PETER DENGATE THRUSH: I was the principal architect of the letter, and in that case I probably need to apologize for any confusion. But I think the position is the latter one. The point is this is a midterm review and we want to know where we are now, and if there is anything remaining between now and the time of its natural expire, we can deal with it. I don't think we've suggested, Paul, that we tear it up at this point. >>PAUL TWOMEY: We've never said we should finish straightaway. But I think it's probably worth expanding that question a bit further. If you read Peter's submission -- I should basically give you some context because it's worth you understanding this. When we negotiated the Joint Project Agreement in September of 2006, John Kneuer and I negotiated and we discussed the timeframe. And the initial discussion was 18 months. And then John expressed with me some concern if ICANN was not able to achieve certain things around the transparency and accountability, how would you manage that timewise. Because if it wasn't 18 months and instead it was 20 or 24 months, we were straight into the U.S. presidential election. So the decision was made to make it a three-year JPA with a midterm review. But the ICANN board was well briefed that it was -- and John sent some further messages. The ICANN board was well aware that there was stated intention by John to me early on, that if things were achieved the midterm review could be a situation where the JPA could come to a conclusion. Now John, of course, has left the administration and, therefore, he doesn't speak for the administration. But ICANN board nevertheless was very committed to that. And you know from our submission it was 1,900 pages of all the work that we've done to try to meet a l.ot of those obligations. And as Peter says, a lot of the ongoing obligations which we don't want to diminish and do, we want to strengthen. I think the key part on Peter's submission is it said, because if you look at the notice of inquiry, it has this list of these ten things that were board resolutions and says, "What else can you do? What else can ICANN do?" We've had nine years of "What else can ICANN do?" And I think, "What more can they do?" I think what Peter was expressing in his letter to the board, very sensibly, was saying, "That's not an invalid question, but that's a question for the community." The real question here is, he said at the end of his submission is: "Is this the organization that was originally envisaged in the white paper? Where are we on the white paper? What's transpired?" And you may have picked this up in the consultation process. What's transpired is as this mission says, we should bring the JPA to some conclusion. You're right, it doesn't say when. It's not our intention it should have been the next day. What has transpired, especially we found amongst American industry associations and others, and people like yourselves, people have said, well, they have sort of seen the JPA in symbolic terms rather than actually in the way in which the board to a degree is saying, which is a more contractual document than what the document itself says. There's been a lot of symbolism about it which is, well, what's next. If this is coming to some conclusion -- is this the conclusion, therefore, what's next. And we actually think, frankly, that similar to what Peter had said at the end of his letter, that's actually the right question. The real question implied from, is this the right organization envisaged from in the white paper process is: What does the final transition look like if the U.S. policy is, quote, transitioned to private sector management, what does that finally look like. So I think we are at that stage now. We're not calling for the final transition discussion to be determined in the next month, that's not feasible. But we are saying to people like yourselves, if that's what the question you're asking, then don't hesitate to put the things that you think are included in that in your submissions. And in response, because we will -- I think you heard Monday morning a number of people saying, what sort of processes do we have to think through some of these issues. >>PETER DENGATE THRUSH: Different topics. >>DR. EBERHARD LISSE: Dr. Eberhard Lisse from dot NA. I full support private sector management of the Internet. This is a change in policy as far as I see it. If you want to reduce U.S. government oversight over ICANN and the Internet, does that also mean you're going to reduce local governments' oversight over the domain names of the ccTLDs? I want this on record and I want an official answer. (Laughter) >>PAUL TWOMEY: The official answer is, it's not our business. >>PETER DENGATE THRUSH: We have no ability at the moment and we're not going to be seeking any. >>PAUL TWOMEY: We should just make quite clear that the phrase "private sector coordination," "private sector management" is -- it is phrase that makes sense in an American context and American political context. I think many people there interpreted it as being ICANN international nonprofit organization is a private sector coordinator. Of course it's a multistakeholder organization. So I don't think you should see when we say, "support for private sector coordination" that we, therefore, mean it should be run by publicly listed companies, that's not what's meant by that. Obviously governments and civil societies and others have a clear role at the table. We interpret that phrase "private sector coordination" as being -- and ICANN, as sort of a private sector body, it's not an intergovernmental body, for instance. >>DOTTY SPARKS DE BLANC: Dotty Sparks De Blanc, dot VI. Do you envision that the JPA review is going to be completed prior to November when there are elections, U.S. upcoming elections, and all the people are probably going to change in the Department of Commerce, so it would be another case of negotiating with somebody who then is gone. >>PETER DENGATE THRUSH: The answer is, yes. We do expect the review to be finished before the November elections. >>DOTTY SPARKS DE BLANC: Okay. >>PETER DENGATE THRUSH: Whether that expectation is realized or frustrated, who can tell. I would just would say, as I said perhaps rapidly before, we are working with the U.S. Department of Commerce in this review. We are consulting with them. We've discussed with them how this is going to go, and we will be reviewing comments with them. And we will be working with them on their report. So that's why I guess we have a reasonable expectation of driving this, helping them drive this through. >>CHRIS DISSPAIN: Roelof, did you still want to say something? >>ROELOF MEIJER: To say it politely, I have some difficulties in accepting that in your original submission you did not have the intention of ending the JPA somewhere half way. That's because of the phrasing and because of some of the correspondence I saw. Anyway, I think it's good that you now have a clear vision that you should fill out the whole contract. Our submission, like quite a few of the others, suggests that we take the remaining time to start the process to make that transition complete. And could you explain a bit more how you envisaged to run that process? >>PAUL TWOMEY: We haven't come to a conclusion yet. And we're taking consultations, listening to people this week and make some summations. I think one of the things that is -- personally, if I could, put it this way. I think it's very important that if we're moving towards finalizing what the arrangements are for transition, that that's a dialogue between the U.S. government, the U.S. Department of Commerce and ICANN. ICANN broadly defined. What will be important inside ICANN, then, is ICANN to be, through its community, engaging its community. Including, for instance, the governmental advisory committee being the mechanism whereby we can get the approach of governments, the ccNSO for country code operators, et cetera. The reason I say that, is that I don't think anyone has an intention of inadvertently opening up WSIS Mark II. Having now gaining to this stage of the final transition, nobody has an intention of unleashing some set of other forces or other forums, that would be appropriate, that would be discussing it. I think it is appropriate they be discussed between DOC and ICANN. And ICANN have its own process clearly, which engages others as a reinforcement of its body-stakeholder nature. The exact details of that we still are sort of -- this week we're going to be listening to people. And we'll have more of a sense, I think, by the end of the week. Or perhaps if not the end of the week, certainly after the public sessions on the 28th of February that the Department of Commerce is having. The other thing I've got to point out, clearly, that there's another party in this whole discussion, is the United States Department of Commerce, the U.S. government. And we can't speak for them. So we don't know what their position is yet. >>PETER DENGATE THRUSH: I would just like to change the subject if there are no other questions on that. I just wanted to tell you if you've been looking at some of the external things, some of the internal things that are going to be happening on the board. I've signaled to the board that I'm going to be looking at changing the committee structures. And the reason for that is not because I want to just come in and change the committee structures. I want to try and shift the way the board operates from a kind of management board to a governance board. The board still has the head-ups in some ways and the mindset and the support in some of the institutions from the very early days, when there was staff of one, in Louis Tuton. And we were using a personal credit card to fund things and a line from a couple of U.S. corporations. So, the board members were very hands on, and board members got involved in things and went out and did work in the community and so forth. We'd really have to, ten years on, move from that kind of management model to a governance model. So, at the retreat in Riga, I'm thinking of having quite a long session on that, perhaps bringing in some outside governance expertise on committees. We'll probably end up with the standard -- we'll have a committee to set up how we're going to do the committees, yeah. But we have to have an RFP first and we need a committee to write the RFP. No. So we'll probably end up with the same familiar committees to you, that will be audits and risk and governance. I think we may have to have a special one to deal with all the reviews that we're going through, and some other governance issues. But that leads me to the next topic, we have actually recently, I'm quite proud of this, we've actually killed off a committee, I like when committees have done their job, finishing them, otherwise they tend to hang about and make work for themselves. The committee that we've killed off is the meetings committee. Largely because it was actually doing sort of a management function, it was actually putting out RFPs to see who wants to run an ICANN meeting, then reviewing them. There was staff work involved but we had directors doing a whole lot of management staff work, analyzing bits for different things. What we haven't got -- this is really what I want your help with, we haven't really got much of a focus on what goes on at the meetings. We put a lot of time and effort into picking whether it was going to be Durbin or Cape Town or Wellington or Auckland or something. What I want to do is return the focus for awhile on why do we have a meeting. So I'd like some feedback on your thoughts. Why do you come to these meetings? Who do you have to persuade that it's a good thing and how do you do that? What do you say you're going to achieve when you get here? How do you know when you've had a good meeting or not? Who do you want to meet with when you're here? Paul made the comment, I think in public the other day, that looking at the agenda now, that at least a third of the time for specified meetings is actually one group reporting to another group at ICANN what it's doing. Which is kind of good, because we've broken down the kind of silo mentality as if one was in their own room. And I can remember being in this meeting in 2000, absolutely convinced that all of ICANN was in the room and this was the most important part of ICANN. I need to go out in the corridor and suddenly find a whole bunch of registrars who had exactly the same -- obviously completely wrong -- view about their role at ICANN. Now we've broken down that thing. So what are we trying to achieve with meetings? Perhaps we need to go back to an idea we tried a couple of times which is to form a community-based or community-representative program committee to actually look at the issues that we're talking about. So if you can include that, Chris, on your work for the next couple of days and just have a -- not necessarily terribly formally: Why do you come? When you go away from an ICANN meeting, how do you measure it? What makes you think you had a successful meeting? Paul? >>PAUL TWOMEY: Can I add a few more questions? >>CHRIS DISSPAIN: Sure. We've got nothing to do for the next couple of days. >>PAUL TWOMEY: How many meetings per year should we have? And what type of meetings? And one of the questions might also be, would you like to have intersessional meetings? >>PETER DENGATE THRUSH: Explain what you mean. >>PAUL TWOMEY: That you get to meet all by yourselves with nobody else around. Basically work on -- in other words, not spend a third of your time talking to everybody else, but spend time working on a particular topic that you feel you need to work on, in between ICANN meetings. >>CHRIS DISSPAIN: Well, assuming we can find -- I'm sure we'll be able to find some time to at least start a discussion on all of that. And, of course, we'll all reach consensus in about five minutes and be able to report back to you almost immediately. Are there any other questions or final things before we go have some coffee? No. Yeah, you can buttonhole them at coffee. Thank you, Peter. Thank you Paul. Thank you Demi. And we'll be gone for coffee. Can everybody please be back here at 11:15, which is half an hour plus five minutes? And we're going to be running the IANA updates at 11:15, thank you, sir. (Break) >>CHRIS DISSPAIN: Ladies and gentlemen, we'll be starting in a couple of minutes. Before we do, I have an apology from Steve Conte who would like you all to know that the network is down, it is not just the ccNSO room, the network is down everywhere. He is busily running around trying to fix it and will do it as quickly as possible. So we'll wait another couple of minutes and then we'll start. Thank you. Well, welcome back, everybody. It is quite a nice change to be at a ccNSO meeting than and able to actually go outside in the fresh air for coffee. The next session is our regular IANA session, so I will pass the chair to Olivier. >>OLIVIER GUILLARD: Thank you, Mr. Chair. Okay. This is the IANA working group and the IANA session. We have the chance today to have Ken Silva, CTO for VeriSign and Barbara Roseman who is the general manager of IANA operation. I will make short hopefully presentation about the activity in the IANA working group and then leave the floor to Ken for the root zone management from a VeriSign perspective -- sorry -- and then to Barbara. And at the end of this presentation, I will leave the floor -- the floor will be open to questions. So quickly about the IANA working group work and process, we had two conference calls since the Los Angeles meeting and one physical meeting. So notes are published on the Web site. We have regular exchanges on the mailing list between members include the IANA staff and now we have a useful support from the secretariat to publish things and organize calls. Major issues that were addressed in the working group, the IANA working group charter and work plan, I won't detail because we will have a session tomorrow to talk about it. The DNSsec paper, we had a session yesterday about DNSsec, about the activity of the IANA working group on this topic. As many people were not there, I will go through it very quickly to give you an input on where we are with this issue. And I will finish with a discussion on IANA operation from a ccTLD point of view and report on a couple of exchanges we had in the working group about it. We also had a different kind of other exchanging about different topics but stayed very superficial so I won't say much about it now. Quickly about DNSsec, I'm not going to rephrase what I've said yesterday. As you may recall, the councillors asked the IANA working group to provide input about the zone signing issue from a technical perspective, in as long as there were also a couple of presentations provided about it. We had also information about the IANA test bed from Richard and the result of a survey that was conducted by Gabriella throughout the members. So we started the discussion in the working group, and we felt that the general background discussion about DNSsec was necessary to at least understand what was the issue of signing the root. I mean, trying to understand it. So we created a drafting team to start to draft a paper and we focused at the beginning. If you look at the people in the drafting team, you will see that they are only people from the cc community and from IANA ICANN. So where we are, we started to draft a paper. It's now published on the ccNSO Web site at the home page. The paper is organized in two parts, the first one which is DNSsec general background, so general background about DNSsec. The second part will be focusing on a practical case including the root zone one, and it also includes a comprehensive reference section at the end. You have 18 pointers on different things that you may want to investigate and for each reference, you have a little abstract that gives you in two or three lines what the paper is about. So what's next about this paper? And I will close the DNSsec topic with this. So the first part of the paper is drafted and visible and accessible on the ccNSO Web site. There are still a couple of typos in it; so if you read it and you see any mistakes, please contact us so that we can improve it. But, yeah. To be done yesterday, I presented the first draft of a DNSsec checklist to help people that would like to get into it to have quickly figures of things that they may need to consider if they plan or they think about the deployment of DNSsec. So this checklist is really derived from the paper. It is just giving the topic "Do I have a big zone "and so on. The part II is not written yet. Some sections are written but it is not all written yet so we have to do that now. And you can also have a look to the IANA test bed. I remind the URL here, and you can contact Richard if you want to test this test bed. Let's move on to the IANA operations now. I will give just a brief background kind of the things that everybody knows, I think, but it's better to say it. So background about IANA operation from a cc perspective. So the root zone change process flow is known and documented. You have a high-level process flow which is visible on the IANA Web site. Also at the end of each request for DNS changes, we have a report at the end of the mail that we receive when IANA closed the ticket. And we all know as a fact that IANA transmits the request to U.S. DOC and VeriSign and waits for VeriSign notification of completion before posting its report and close the ticket. For us the end user, operations performed through the VeriSign DOC process is a bit of a black box. Another fact and another information because it is not reported in the report we receive at the end of the -- when closing our request, IANA has also indicated and has made a public consultation about technical checks and as advice that DNS technical checks were performed at both IANA and VeriSign sites. In this context, we also know that IANA is working on a software, root zone management software, that was developed by ICANN -- >>BARBARA ROSEMAN: The microphone is right behind your computer. >>OLIVIER GUILLARD: Oh, thank you. IANA is working on a software that was developed by ICANN and NASK, and this software is designed to improve the performance of the root zone change. And the basic idea behind this is to automate part of the process that is presently performed manually. But IANA has also advised us that the new software would not alter the current process flow, so it would still go through the VeriSign and D.O.C. black box, let's say. Jointly, IANA has also indicated that an EPP interface has been integrated between IANA and VeriSign to deal with interaction between them. This is just a quick for those that haven't seen it, a quick view of the root zone management interface. It's possible to have an account, and to test it, I must say that I looked at it very late so it's not an official report, it's just first observation after I've tested it. We haven't tested it formally in the working group, so it's not -- it is just a quick first observation. Nice interface, you have prefilled forms. You have access to your ticket reports and archives directly online. You have a process that allows for validation to be performed through acknowledgment by mail by the admin and tech contacts. It's secured by HTTPS and there is a password authentication to get into the interface. Again, first objection, it seems that a couple of bugs were detected. To be fair with IANA, I haven't report yet to the team so, yeah. In realtime DNS checks are performed, it is not clear if they are performed on the IANA side or the VeriSign side. The authentication is based on password rather than acknowledgment by mail. Is it better? It seemed that the process flow is a bit different than the one we have in the current situation but this also has to be checked. And one open question, that's not very clear how the requests are going from the root zone management software to the EPP server which is on the back hand. Open observations. That's about it for me. So I will leave the floor now to Ken Silva to say a word about root zone management from VeriSign. >>KEN SILVA: So there are actually several things that are going on with the root kind of at the same time. Last week many of the root servers actually went to IPv6 which was allowed to the root zone prior to that with quad A records but there were really no root servers running on IPv6 or you could not actually query most of the root servers via IPv6. Now our A and J root servers will actually serve up on IPv6 natively. We have also announced a trial for DNSsec as well which will be a process that's sort of key signing key agnostic. It doesn't matter to us who has the key signing key and then we'll generate a zone signing key. In the meantime, we'll manually place the DS records for the TLDs that have DNSsec today, we'll actually enter into the zone manually for now and make that zone available for people to download. And this is largely because we have to understand all of the components that have to go into the -- that have to go into the root database. While we know many of the components, this process -- and I will get to it in the minute about the root zone management -- has to include all of those components which will be new additions to the root zone today that don't currently exist in the root zone. Around the root zone management itself, today it is a very manual process, so Olivier referred to it as a black box, I guess, I can understand why that's sort of the view. Essentially what happens is that once the request is sent to IANA, then a message is simultaneously sent to VeriSign and D.O.C. It is actually sent to D.O.C. and we are cc'd on it. VeriSign doesn't take on it until that is authorized by D.O.C. at that time. The process to actually update the zone is a manual process now. It has to be manually entered in, and this is after VeriSign itself does checks to make sure that the name servers that are requested that go in actually exist and are up and answering queries. And then it's manually entered into the database and then the zone is cut. It's pushed, and then an e-mail notification is sent back to IANA and the D.O.C. informing them that that process has been completed. That's a very manual process. It's an old process that's been around quite awhile and everything is done with e-mail templates. By the time the item gets to us or the DOC and even to IANA, that's currently, even though we have a test-bed system. So we've worked very closely with IANA, that over the last 18 months or so to define a new process which is much more automated. We created a new registry just for the root that takes hold, just for the root that takes the EPP interface, which is directly to the template client. And that has actually been up and running in a test environment for IANA to test since May. Testing began in August, it is still ongoing and I think they're about a half dozen or so ccTLDs that are actually testing through the interface. That should go into what we'll call "shadow operation" for about six months beginning in Q2 of this year. So, what you'll see on the other end of this is much more of an automated process for those ccTLDs that have their own template generation, portals if you will, those will hopefully interface with the IANA templates. And then that will all be an automated process. And then even the DOC's portion of it is somewhat automated in that they need only send a response back, and then the process takes over from there. What that will hopefully do is today we have a turn-around time of -- an expected turn-around time, I should say, of five days from the time we receive approval to conduct change. So, the length of time it takes to receive that approval could vary from the time that IANA actually sends the notification to us in DOC. We cannot actually take any action until we receive authorization from DOC. So, this new Root Zone Management process, which we've worked very closely with IANA on over the last, almost, two years, is finally starting to get rolled out now. It's in testing with IANA and we expect that testing to go into shadow operation or parallel operation, if you will, for about six months starting in the second quarter of this year. I would expect that we'll have a fully-automated or semi-automated Root Zone Management process, which should be significantly better than what we have today, and reduce the potential for any possible errors. Today the system is pretty manual, it's manual in a number of phases. And so the opportunity for error is plentiful. The second phase of that Root Zone Management process will involve extensions to the registry to house the DNSsec information. That needs to be stored into the database. And then that will probably begin either later this year or the beginning of next year. And that's pretty much it for the update on that. I think that was about my ten minutes. >>OLIVIER GUILLARD: Thank you very much, Ken. I leave the floor to Barbara for the update on the IANA. >>BARBARA ROSEMAN: Good morning. This is just going to be an overview of some of the things that have been changing since we last updated things in San Juan. One of the biggest changes, as Ken mentioned, was that we've added IPv6 for six of the 13 root servers. There's been a small increase on load, it's about tenfold for IPv6 queries from the data that we've been given. But that still works out to something less than a rounding error for what you would have on IPv4 queries. There have been no reported problems at all. This is your standard processing trends chart where we show you the mean processing time, the median processing times and the standard deviation. You can see that it looks quite spiky. And it appears that during some months we seem to have more challenges than others. We've broken this out a little bit so that you can see that for name server changes, the upper chart, it's actually quite consistent. We had one blip in November having to do with a particular request. But other than that, the mean processing times take between 20 to 25 days on average for redelegations and delegations, which require much more effort. You can see that that is what lends the spikiness to the overall chart. Some of our longer-term trends are that routine requests are being done faster. The remaining areas on average are taking longer. There's redelegations, requiring more due diligence. Some of them are more contentious than others. And there's balancing a number of those due to outreach numbers in the community at large as people try to shift responsibility for who is going to manage the TLD. And that often leads to discussions in the local Internet community, which can take some time to resolve. We're studying the underlying causes, we'll report back if we think that there's any trend that could be addressed or any process that could be improved. There was a proposal to split the reporting in to regular versus error or exceptional cases. We'd need to work on a definition of what the latter included. And clearly redelegations or third parties impacting those are the glue records that involve multiple TLDs. Those are the ones that currently give us the longest processing times. A little bit more on processing trends. I'd like to just clarify something that Ken said. When you send your request, IANA validates that request as being both authentic and technically sound. It isn't until we've done that step that it goes to VeriSign and DOC. So, it's not that the five days starts when you send your request to us, it starts when we send it to them. And what you can see in this chart is that IANA has -- each of the gray bars here is a weekend. IANA takes a certain amount of time communicating with the requestor. The blue is DOC's time. The only time it stretches beyond a day is when it occurs over a weekend. Then we give it to VeriSign to implement. They have been very consistent in implementing the changes within five to seven days. That's what we've seen. The delay that has been talked about is in the post-implementation notification to IANA that the request was completed. And as you can tell from the data here, we think that these are just being batched at certain times. That certain number gets collected of completion notices and sent out to us all at the same time. So as far as we're concerned it's not something that's hindering actual processing of the name server changes, those are happening in a very routine and consistent way. The notifications are the areas where we've had some challenges. Service level targets have been talked about. We're working on compiling the historical data, which would include the earlier drafts, earlier graphs and drafting a set of service level targets for discussion with this community and others. We hope for more discussion at the regional ccTLD workshops over the next few months. Most of the testing has come from the testing group that pretty much signed up in San Juan. We would appreciate more volunteers who can spend some time using the system and providing feedback. We'd like to identify all the bugs as quickly as possible so that we can move into our next stage of implementation. David and Kim are meeting this week with the U.S. DOC to work on compliance testing for the production deployment, which would include security audit. And that's it. Thank you. >>OLIVIER GUILLARD: Thank you very much, Barbara. And I think that now we can open the floor to questions. Are there any questions? >> RICHARD WEIN: Hello. I'm Richard Wein from Austria. Let's say there's an MOU or Service Limited Agreement or any agreement in place between VeriSign and IANA and ICANN, how should they make that work, what timeframe? Are there any written or visible things in place? >>BARBARA ROSEMAN: There's actually no agreement between IANA or ICANN and VeriSign regarding the Root Zone Management at all. Our relationships are both through the U.S. and DOC. They have a contract with the U.S. DOC, we have a contract with the U.S. DOC. There's no contractual relationship regarding the Root Zone between ICANN and VeriSign. We have often talked about it. I mean talked about what the service level commitment should be. And as I say they have been very, very consistent in performing the function within the time that they have committed to, which is the five days, five business days. So we have not had any real difficulties with that. The only time that I can think of where there have been delays is, VeriSign performs a separate technical check from IANA's technical check. It covers somewhat more information than IANA require for complete technical competence. So they will often query us as to whether they found an exception, do we still want to proceed. And if it is not something that would fail our technical check then we just inform them to proceed. That can sometimes add a day or so to processing. >>KEN SILVA: I think that's as we understand it as well. There's not a formal agreement in place, but we've met on a number of occasions and have, I guess you'd call it, informally agreed to get these changes done within five days. There have been couple of cases, as Barbara correctly pointed out, that occasionally will conduct a check that doesn't look right or something seems suspect in it. For instance, someone assigns dot org instead of dot net, we'll inquire back as to whether or not we're all happy with the change before it's actually made. But by and large, we have committed, at least in principle we have committed to five days to IANA to get those turned around. >>OLIVIER GUILLARD: Just to follow up, Ken. I heard this morning, I think, or somebody referring to it, do you have a global contract for dot com and Root Zone Management or is it separate? Because you mentioned that you separate the technical infrastructure now and from the contract prospective with the DOC; is it a different thing? >>KEN SILVA: Well, I guess, I'm not real sure how that's relevant. It is separate. Dot com and root servers are in fact separate. Traditionally when the registry was originally built they shared a common database and we have since separated those databases out. That was just largely due to the fact that it takes a long time to cut a zone from com and much less time to cut zone from root. To separate the processes saved a lot of time on the root side. >> MATHIEU WEILL: Mathieu Weill from dot FR. I would like first to thank all the speakers and for a very comprehensive overview of everything that is of interest for us ccTLDs in the Root Zone Management. And I particularly applaud VeriSign's presence, and thank very warmly Ken for being here because it's extremely important for us to have all the stakeholders in this particular management process. And my question, this is notwithstanding any further ccNSO or working group decision, but would VeriSign be in favor -- how would you react if we suggested that the IANA working group might be of particular help for your automation process in VeriSign. And in specifically to provide users' input. Maybe think or discuss about metrics, performance metrics. And maybe provide experience that we could share in monitoring this type of thing. I think it would be very worthy for the community if the IANA working group, which is probably the most concerned working group inside ccNSO, was to be further involved in helping you with this process. >>KEN SILVA: Well, I guess at first blush I'm not exactly sure how that would interface. Because your real interfaces through IANA and our interface is to IANA as well. We've worked pretty closely with IANA themselves and wherever they chose to get their input from, which, I assume, is also from that constituency, has fed into that process. I suspect that over time that's going to change pretty dramatically based on feedback that we get from the community. But I don't really know how much visibility you would actually have in an automation prospective. That process actually has feedback into it, really. Because it's sort of deep into the process, and it's all handled by the machines at that point with some technical checks, and which also are being automated. I guess I'd be interested in hearing your views for sure, but not sure how much visibility you have in the process to actually provide feedback. >>OLIVIER GUILLARD: Just a word about IANA perspective, there is a session tomorrow about the work plan. So this kind of topic can be raised to try to reach a realistic approach in the work plan at the end. Sorry. Any more questions? Lesley? >>LESLEY COWLEY: Two points, first is a member of the IANA working group, I will reiterate my favorite point that I think this whole process needs some real fundamental review, the various bits to take five days is really not acceptable for a number of cc's who would like their changes processed much more quickly. Secondly, I think a number of us were quite surprised by the announcement on DNSsec by VeriSign the other day. Maybe it would be helpful if you can outline some of your thinking behind that and where that fits in the current discussions about signing the root within the community, please. >>KEN SILVA: Thank you for the question. First to address the first part about the five days, this automated process will turn that around quicker than five days. We're confident of that. So just to sort of address that point. In terms of the DNSsec, our thinking behind that was pretty straightforward, really, and that is that currently we cut the root zone and felt that whatever part of the process we were in, we needed to have some role in the DNSsec. Now, that role is a trial role now, okay, much the same as what IANA is doing, in fact. It's based on are -- largely on the work that has been done and published by at least two separate groups, the SSAC issued a paper on the subject, at least its chairman did, and the IANA working group has issued papers on the subject. So really we're in the process -- we're involved in the process, and our thinking really was we need to have a trial as well to make sure that all of the processes should DNSsec move forward, we're going to have to deal with signed zones. We have an automated process that we're building today that is going to have to have all of the bits of DNSsec in that registry. And so we need to be fully cognizant of all the parts today so that we can start building that into the system -- the automated system as we go. I don't think it was meant to be a surprise. I think we had worked quite a bit with a number of different groups in terms of what was involved in DNSsec, what the parts would be, what the components would be, and everything that we're doing around that can be changed along the way. We didn't build -- the trial we're building is not dependent on our keys or our signatures in any way down the road once this goes into a production mode, assuming it will go into a production mode. But we operate to the root servers. We generate the root zone and we currently house the database for that system, so we felt it was necessary to have a process that worked end-to-end all the way through the registration process -- or, excuse me, the update process and addition process all the way through cutting the zone and publishing the zone. So I think what we're doing is pretty consistent with what the rest of the community has advocated. >>OLIVIER GUILLARD: Just a word about this, Ken. As you know, there is a test bed that has been run by IANA about 1 1/2 years? >>BARBARA ROSEMAN: A while. >>OLIVIER GUILLARD: There are also a couple of DS records from ccTLDs that are introduced in, and I think you mentioned that you plan to provide an interface for cc's to introduce their keys. >>KEN SILVA: Yeah. >>OLIVIER GUILLARD: What about synchronization or -- >>KEN SILVA: So I think we're going to use the existing keys that the cc's already have, okay? So if they already have a key, then that's the key that we will put into the zone. You know, we view the work that IANA has done as excellent work and we just want to try to take this a different way. Our focus is going to be a lot on the actual process of doing the signing and lot on the process of how -- how you do that in a cryptographically secure fashion. What I mean by that is already we are involved in signing certificates today and around PKI. We have a lot of processes set up. So what we're concerned with and what we want to move forward with is to help define what are all the steps involved in that and how secure does each step need to be in terms of security in the facility to, you know, security of transferring the files around before they're signed, those sorts of things, which we have a lot of experience in and we think we bring a lot to the table for that discussion. But talking about it on the whiteboard is one thing and executing it in person is another. The other thing about the interface, to get back to the first part of your question, is that interface does not currently exist today. So whatever zone -- whatever DS records would have to go in would really be existing DS records which would be manually placed into the zone today. As we move forward and we understand the process better, part of this automated root zone management process that we're already working on for the existing root zone process will then incorporate all of the elements including the steps needed to sign, the steps needed to enter the records in and then ultimately publish the signed zone. >>BARBARA ROSEMAN: From an IANA perspective, we've included DS records in our test bed as well, also on just a publication basis that other TLDs are publishing their DS records and so we pick them up and put them in the zone. IANA -- ICANN's perspective on this is that adding a new field to the standard processing for updating TLDs in the root zone, DS records or some other things that might be added will require a change in the process. Will require some understanding of how the information is going to be transmitted, validated and then transmitted from IANA to the publisher of the zone. So I think that for us it looks like a somewhat longer process step than just simply creating an interface to accept those DS records. >>KEN SILVA: When I said "interface," I meant some way of getting them in without copying and pasting. >>OLIVIER GUILLARD: Any more questions? That's it. Thank you very much, Ken. >>KEN SILVA: Thank you. >>OLIVIER GUILLARD: Thank you very much, Barbara. >>CHRIS DISSPAIN: Thanks again. Okay. I'm going to use a little bit of the time that we've got, which we've got because our board members got lost this morning, to just do a couple of things and then we might break slightly early for lunch. I have an e-mail from Wolfgang Kleinwaëchter which I'd like -- he's asked me to read to you. He came to the last ccNSO meeting and talked about the summer school. He's not here because he's not been well but he is getting better. He was advised not to travel. He says, "I planned to keep the ccNSO updated about the project of the summer school on Internet Governance, which I presented during the last meeting in L.A. Could you spend two minutes to inform the ccNSO members about the key points I plan to raise if I was in Delhi." Yes, I can. "One, we have published the call for applications. It is attached to this e-mail and I will send it out to the lists and have opened the Web site, www.euro-ssig.eu for the 2008 summer school on Internet Governance early this week. The summer school takes place in Meissen, in Germany, from the 25th of July to the 31st of July, 2008. All the details, including the draft program for the 50 hours, one-week course can be found on the Web site. The members of the ccTLD community are cordially invited to use this for further training and to send in an application. Two, I wanted to thank in particular Denic, SIDN, Norrid and Eurid for their support of the summer school. I would be thankful if other ccTLD registries could consider joining the SSIG fellowship program to enable young experts from developing countries to participate in the summer school. The costs for one student is 1,000 Euro plus flight. Members of the SSIG fellowship program will get their logo listed on the SSIG Web site and on all printed materials. They also can select individually from the list of applicants based on the recommendations of the SSIGN program committee who they want to sponsor. Thanks very much and have a good meeting." So I will later on send out the details of that -- the Web site, et cetera. I've just noticed that despite his claims to have attached something, he hasn't. So I will get back to him and say, "Where is your attachment?" Those of you who are interested, either, A, in having someone attend the summer school or, B, in sponsoring someone should obviously contact Wolfgang. I think it's a great opportunity for the younger members of staff to go off and actually do some hands-on learning with a bunch of other people. So if you -- it would be great to think -- to think favorably about it. Patricio, was there going to be a similar thing in Latin America? Gabby, could you -- sorry. >>PATRICIO POBLETE: We just mentioned to Wolfgang, he was interested. But I don't know if there is anything else that has been done on that. I don't know if Margarita knows. >>MARGARITA VALDES: Not yet. That's the idea, at each location. >>CHRIS DISSPAIN: Yeah, okay, excellent. The other thing I wanted just to cover was the questions that Paul asked this morning about meetings and stuff like that. I'm curious, what do people think about the number of ICANN meetings? Perhaps, if I can just get a quick straw poll, do people think we should have -- let's assume we had the maximum we would have is four and the minimum we would have is one a year, what do people -- do people think we should have one meeting every year? Anyone? Two? (Raising hands). >>CHRIS DISSPAIN: Two, okay. Three? (Raising hands). >>CHRIS DISSPAIN: 12? [ Laughter ] Eberhard, basically, wants to move into ICANN and live here. Three would be the tops, yeah? Three would be the maximum. Nobody thinks four? Okay. Nigel thinks four. Nigel thinks none. >>NIGEL ROBERTS: Nigel wants to ask a question. >>CHRIS DISSPAIN: Go ahead, Nigel. >>NIGEL ROBERTS: I think before you can take the sense of the meeting, you have to be a bit more clear about what you mean by a "ICANN meeting ." Do you mean an ICANN meeting with everybody here with everything going on exactly as is? >>CHRIS DISSPAIN: Yes. >>NIGEL ROBERTS: Or do you mean the intersessionals? >>CHRIS DISSPAIN: Specifically these meetings. >>NIGEL ROBERTS: The question depends on whether you are having intersessionals or not. >>CHRIS DISSPAIN: I accept if there were intersessional meetings that would have an affect. So let's talk about the possibility of intersessional meetings. Do people think that the concept of having a ccNSO meeting separately from an ICANN meeting is, again, subject to numbers obviously -- so let's take an example. If the number of ICANN meetings, these type of meetings, was reduced to one or two -- and two seems to be the kind of general -- split between two and three. If it is reduced to two, would we then want to have intersessional -- one or two intersessional ccNSO meetings outside of ICANN? Who thinks we would want that? Nobody wants it? Okay. So everyone thinks it is not necessary? Yeah? Obviously the caveat to that is it might be necessary in an individual instance for something specific, but on a regular basis. Steven, did you have? No, you're okay? Okay. So that means that the idea of having intersessional meetings is not as important for us. I at least in part for some of us we have regional meetings and stuff like that. So can I ask a question to some of those who put their hands up and said two meetings to, perhaps, just to play devil's advocate to say why you think three -- I think that coming face-to-face is important. And I think that a lot of work does get done at these meetings and I wonder whether reducing the number of meetings to two would actually simply mean that we didn't get as much work done. When I say "work," I mean work within the ccNSO or the gTLD community. I am interested to hear why those who think two think two. Could somebody who thinks two could, perhaps, put their hand up and grab the microphone, Roelof and then Peter. >>ROELOF MEIJER: I had my hand up at two and at three because I'm not really sure. >>CHRIS DISSPAIN: You are not sure which one to choice. >>ROELOF MEIJER: I think it depends a bit on how much progress there is. What I have seen over the last three years that I have been attending ICANN meetings is with the speed at which things are developing within ICANN, I think we could have done with two. >>CHRIS DISSPAIN: I'm not -- you mean because it is so slow? >>ROELOF MEIJER: Yeah. [Laughter] >>ROELOF MEIJER: I didn't want to say "lack of speed." But, on the other hand -- and this is where my hesitation comes from, I think the context we have within the ccNSO and also in the network are very important. >>CHRIS DISSPAIN: Yes. Let me add to that by saying, you know, from a management point of view with things like the policy development process or the fast-track or any sort of consultation stuff that we do, we work really hard to try and make sure that at least a portion of that consultation time is at a face-to-face meeting because for some people that is the easiest way of actually grasping the issues and responding, which I assume would be tougher if we only had two meetings. Peter, did you want to say something? >> PETER VAN ROSTE: My name is Peter van Roste. I am the general manager from CENTR. I had a couple of reasons why my hand was up at two. One is there is a cost and participation working group, it turns out, that -- this is from many smaller registries, still an issue even with the ICANN fellowship program in place. For quite a lot of people, there is a travel time issue. Quite a few of us spend way too much time in airplanes and in hotels. And then probably the more fundamental reason is I'm convinced that much more efficient work could be done in between sessions in smaller groups, whether that's on conference calls or a couple of people from the same region meeting or meeting during other meetings. But that the smaller working groups might be a more efficient way of getting things done than to repeatedly discuss them in large groups such as these. >>CHRIS DISSPAIN: Okay. Thank you. Anyone else? Anybody want to say why they think there should be three? Calvin? >> You do maybe lose momentum if you keep the gaps too long. That would be my biggest concern about it. >>CHRIS DISSPAIN: Sure. Yeah, I'm not pushing this one way or the other, but I've noticed that because sometimes the meeting sort of move, this is a particularly early meeting and we've had a couple that have been particularly late in the year, so you have a longer gap than you normally had. I think we once had an almost six-month gap, and I do have some sympathy with that view. I do think you tend to -- people tend to start thinking about stuff at a fixed time before the meeting. I acknowledge your point, Peter, obviously if you had organizations -- the organizational stuff sorted out so working groups are working et cetera, et cetera, I agree. But on the basis -- the way we work is that -- the way that would work is that you have your small working group do the work. It then has to go to members. I wonder whether -- I wonder whether people would only start thinking about this particular stuff a couple of months before the meeting rather than thinking about it for the whole of the six months or whatever it would be, the gap between the two meetings. >> MATTHIEU WEILL: That's pretty much what everybody is saying. I had my hands up at two, but when I do that I am pretty sure that if there are two meetings a year, then the ways to work have to change and -- so that's a pretty significant move and I agree with you, Chris, if we take -- if we think on the basis of the way we work now, then three is best. But on the long range, probably two would be more stable and enable more participation and maybe better process management as well because there would be more time for secretariat to prepare the meetings, to put the documents forward in advance. >>CHRIS DISSPAIN: Yes. >> MATTHIEU WEILL: And that would be the challenge. >>CHRIS DISSPAIN: Absolutely. I think one of the outcomes of the council -- the council workshop on Sunday was to put in place all of these processes, et cetera, and to start -- we have kind of grown up now. We have gone through the childhood and the adolescence and it is time to start putting some practices in place that are consistent. And I suspect that if we do that, when we do that, and it has been running for a little while and it is shown that it can work, then I think I would be more comfortable in saying now I think we could consider moving to two. Just so that you know, what we're going to do is we're actually going to review -- the council will review what we have done in Africa. We will run all the working groups to work the processes out, run through Paris, and then when we get to the African meeting, we'll actually have a session on, "okay, how is it working"? Have we done what we said we were going to do? All of that sort of stuff. I'm assuming that everyone thinks that meetings should move around region to region? Or would people prefer a fixed -- one fixed -- everyone is happy with the regional, moving them around the world? Lesley? Yes, everything in Oxford. >>LESLEY COWLEY: No, actually, no, no, not in Oxford. I would just like to support Calvin's point actually. I think we need to recognize we actually have quite a large workload at the moment. >>CHRIS DISSPAIN: Yes, absolutely. >>LESLEY COWLEY: And I'm very much aware that the IDN work, in particular, is going to be a heavy workload for us, and I think we will lose momentum on that -- >>CHRIS DISSPAIN: Yes. >>LESLEY COWLEY: -- if we don't have the number of meetings. It may even require more to get through that particular issue. On the fixed point, whatever, I think one of the suggestions from Susan Crawford's meeting committee was that there be one fixed point and the other two meetings would vary, and I would support that suggestion. >>CHRIS DISSPAIN: You would support? >>LESLEY COWLEY: I would support that suggestion as long as it's not in Oxford. >>CHRIS DISSPAIN: Or Los Angeles. >>LESLEY COWLEY: Or Los Angeles airport, yes. [ Laughter ] >>CHRIS DISSPAIN: It would make sense -- Dotty and then Ann Beth. It would make sense for ICANN's general meeting, such as it is, to be a fixed place, a fixed time sort of meeting. Dotty? >>DOTTY SPARKS de BLANC: The things I would like to see about the meetings are announcements in advance of where they're going to be, much farther in advance than we're getting them now because you really need to plan your travel year in advance and it is very -- it is very irritating not to know. >>CHRIS DISSPAIN: It is also -- it is also pretty hard actually to get it work out. Civil war breaks out or something, it is tough. >>DOTTY SPARKS de BLANC: Yes, asides from civil war, they just need to start earlier. >>CHRIS DISSPAIN: Sure, I agree. >>DOTTY SPARKS de BLANC: The other thing is that it's very frustrating to have three days to book in the venue hotel because there aren't enough rooms to hold people -- you know, to hold the people that want to stay there. >>CHRIS DISSPAIN: I'm thinking of instituting a ccNSO room sharing policy. [ Laughter ] >> By region? >>CHRIS DISSPAIN: No, no. That's right, two people share the room, they have to be from different regions so that we can -- yeah. Gabby, Annebeth and then Nigel had his hand up. >>ANNEBETH LANGE: I said two and three. I agree with what's been said here that at the moment we stay at three meetings. But I remember then the first time I joined this, we had four. And I can't say that the work we did then was better or more efficient or that we contributed more than we do with three. So it is more like a way to make a working program, perhaps, one more day when we go, even if it is long, it is better to go two times a year and have a little longer meeting and more contingency in that. And also like Dotty said, we have to have some planning earlier. It's very difficult when you don't know where to go, the hotel is taken, you have to be on different places, and that's also some of the things you have to convey to ICANN, even if it's difficult. So when we have two meetings, they also would have longer time to plan so it would be a convenience then. Thank you. >>CHRIS DISSPAIN: Thanks, Annebeth. Nigel, I believe, had his hand up. >>NIGEL ROBERTS: Very quickly, if I can. I would like to support what Lesley said about having a fixed point for meetings, at least one. And that point should be chosen based on how easy it is for, should we say, many people from all over the world to get to it. It is actually probably not intuitive that, for example, somewhere like Miami is actually easier for many people from South America than getting to other places in South America. >>CHRIS DISSPAIN: What about Gurnsey? >>NIGEL ROBERTS: That's no convenient for anybody. >>CHRIS DISSPAIN: We've crossed off Oxford. We've crossed off Gurnsey. We're doing very well here. Yep, next one. >> VIKA MPISANE: Chris, I heard Lesley talking about -- I heard her talking about -- >>CHRIS DISSPAIN: Sorry could you just tell everyone who you are before we start. >> VIKA MPISANE: Yes, Chair. My name is Vika Mpisane from South Africa. Now, just to find out, the fixed venue, is there an explanation on what the one stage of that is and is not and what venue do people have in mind and what's the criteria for that? It is an important proposal but it is also quite concerning, which region and why that particular region. >>CHRIS DISSPAIN: Yes. Well, there is lots of ways of looking at it, Vika. One way is to say that most organizations, be they national organizations or international organizations or all organizations have a home, a home base and often the annual general meeting is -- has to be in a particular place. Now, that's probably not the case with ICANN or at least if it is they have been ignoring it for the last number of years. I'm not entirely sure why the idea of a fixed place is necessarily beneficial. Lesley, do you have some thoughts on that since you said you supported it? >>LESLEY COWLEY: I was following the discussions that Susan Crawford was facilitating so these aren't my points, these are the points I remember from that discussion. And the idea really was to identify a location that was very easy for a large number of people to get to. Some of the meetings we go to, particularly people from Africa often have to fly out of Africa in order to get back, et cetera. Always a location that's easier for some for visas. >>CHRIS DISSPAIN: Which rules out the U.S., in fact. >>LESLEY COWLEY: Absolutely. I think the other point that was being made was really about having a venue that could accommodate a large number of people and that, perhaps, deals could be done without venue to reduce costs -- >>CHRIS DISSPAIN: Because we're coming back again and again. >>LESLEY COWLEY: -- because you're coming back again. Again, from the participation group, people have concern about costs of hotels and meetings, and if there is any way of reducing that, then I think that would be welcomed by people. So those were some of the things around the fixed point notion. >>CHRIS DISSPAIN: Yeah, yeah. In the past when there's been a need to have -- when there's been a need to have some sort of intersessional meetings for various reasons -- and I can't remember what the reasons are about there have been a number. And there have been times when the board needed to get together quite quickly, they have always done it in Amsterdam because it is a hub and it's pretty -- you know, it is an easy place -- it is not an easy place for some. But it is easier than a whole heap of other places and it is a fun place and Bart lives there and, therefore, it makes it even more -- in fact, it is going to happened at Bart's house. It is going to be at Bart's house. So that -- something like that -- if a venue could be found that was workable, just not the airport, and so on, then that might be worth considering. It also reduces the strain on the regions to find -- you know, if you stick with three meetings a year, one of which is fixed, even if you went to two, one of which was fixed, it reduces the strain because it comes around pretty quickly. Latin America is back again before you know it and so on and so on. I do acknowledge, Dotty, the point about -- and Annebeth about the point that you know where you're going. My instinct is that it used to be better than it is now. It used to be -- I'm not entirely sure why. I mean, I know why -- I know why Africa isn't sorted yet, that's because of the issues in Kenya. But normally by now we'd kind of have an idea about next year and we don't yet. I mean, there are rumors, but -- as there always are. Anybody else want to say anything? Annebeth, yes. >>ANNABETH LANGE: Just a question about the economy because if I understand this right, now it is sponsored. When we have meetings all over the world they have to get some sponsors to pay for the meetings. >>CHRIS DISSPAIN: No -- yes and no. ICANN actually pays for a lot more now than it used to pay for. So my understanding is that they've changed the way that they do it so instead of the local host having to bear the major portion of the costs, I think ICANN bears more of the cost and then the local host goes and get responds sponsors to assist with their costs. >>ANNABETH LANGE: Then if it is a fixed place to have it, then the cost would be difficult. >>CHRIS DISSPAIN: No, but -- if it is a fixed -- yeah, if it is a fixed venue every year for the IGM, ICANN can pay for that and ICANN can go and find sponsors. The sponsors in L.A., I think Paul Levins went out and found those people to sponsor L.A. So that would be the way to do it. Anyone else? Okay. So it's lunchtime. >>GABRIELLA SCHITTEK: No, no, no. >>CHRIS DISSPAIN: I apologize. >>DON HOLLANDER: Don, from APTLD. I just want to point out that ICANN had four meetings last year because they had a regional meeting in Taipei. This year they are planning a regional meeting in Dubai so ICANN is up to four meetings. CENTR has about nine or some large number and APTLD has -- will have five this year so there is certainly no shortage of opportunities, at least in Europe. And in terms of just a convenient location, I think Sydney or Melbourne would work well for me. >>CHRIS DISSPAIN: Yeah, I agree. I agree. >> Walking distance. >>CHRIS DISSPAIN: It would have to be the right time of the year, Don, but I think you're right. Okay. We'll break for lunch now. I haven't actually had lunch since I have been here so I have no idea where lunch is. Does anybody know where lunch is? Outside in the courtyard. As long as people know where to go, that's fine. We're going to reconvene at 1:30. Gabby has something. Yes, Gabby. >>GABRIELLA SCHITTEK: There is an India I.T. meeting going on in the Durbar Hall and there are industry leaders there. You are very invited. Apparently, it is interesting. Those of you that are interested please go to the Durbar Hall. >>CHRIS DISSPAIN: Are people filling the form in? Is everything okay? >>GABRIELLA SCHITTEK: Yes. But those who haven't filled in these forms, please do so. I'm still lacking a few, so please fill in these forms. >>CHRIS DISSPAIN: How many did we have last time? Can you remember? >>GABRIELLA SCHITTEK: 70. >>CHRIS DISSPAIN: Sorry, just before we finish, we're back -- we're due back at 13:01:30 for an update from the Indian ccTLD for our hosts so it would be polite of us to be here for that and that's at 1:30 and then we're going into some other ccTLD updates. So everyone have a great lunch and see you in an hour or so. (Lunch break) >>CHRIS DISSPAIN: Well, good afternoon, everybody. Welcome back from lunch. Our first session this afternoon is an update on the Indian ccTLD dot IN. I would like to introduce Rajesh Aggarwal from the National Internet Exchange of India, which I believe is called NIXI, who is going to give this presentation. Thank you. >>RAJESH AGGARWAL: Thank you, Chris. (speaking non-English language) which means good day to everybody. >>CHRIS DISSPAIN: They can't hear you. >>RAJESH AGGARWAL: I will be speaking on Indian languages and the role of IDNs. We manage the dot IN industry. It is the ccTLD for us. And somebody from ICANN very nicely suggested putting a "D" in the presentation topic, so I have written I(D)N so we are looking forward to moving to IDNs. This slide is in our national language, Hindi, so it, basically, says your Internet (speaking non-English language), which means this Internet is telling us something, which is from the local community site that our time is coming, that we can now use local languages. The first picture you see, a lot of applications both online and offline we now have in our local languages. Second picture I particularly like a lot of Linux variants are now available in dozens of Indian languages. Commericial variants like (inaudible), they have about ten languages. Ad people have developed local flavors on (inaudible). And third picture is also very symbolic. Windows operating system is now available in about 14 Indian languages. So figuratively speaking, we can say that windows of opportunity for the excluded communities are opening up. So India, this chart I have picked up from Wikipedia. India is a country of 1.2 billion population billion spread over more than 300,000 square kilometers. Linguist guys try to count up with the languages. There is about 615 and then they lost interest. They said enough is enough. One count says we have 850 living languages which people are actually using and speaking which can be classified in 214 (inaudible) languages and trimming down further, we have 22 official languages. You know when we got independence in 1946 from the British, the country was ruled by about 800 princes. And in 1956, the country was reorganized, basically, on the basis of languages. So 22 official languages are now recognized, and people are extremely passionate about it. So, typically, we can say that we have 22 languages -- 22 official languages. Our national language, Hindi, is spoken is by about 400 million people, (inaudible) by about 70 million, (inaudible) by about 60 million people. And then we share languages on the subcontinent. Bengali we share with Bangladesh. That community is also quite active and spread around in a number of other countries. There are about 200 million Bengali-speaking people in the world. Then we Urdu share with Pakistan, and Urdu we use in India. About 100 million people use Urdu. That's quite different from Arabic and is predominantly in Indian culture. Before moving to IDNs, I will just cover quickly the scenario in Indian language tools. Operating systems, as I mentioned, all Linux variants now support a lot of Indian languages. And Microsoft also now supports 14 Indian languages. Microsoft typically works on (inaudible) commercial interests, and they will pick up bigger languages first. Linux communities, especially those working on (inaudible), very small linguistic groups, they have their own operating systems and fonts so that's very interesting. In keyboard drivers, a lot of keyboard drivers in various Indian languages are available. Fonts in Urdu has been quite chaotic. We have more than 5,000 fonts in the country in different languages and many of them don't follow a standard storage system. Now typically people are moving towards Unicode, while Indian system is ISCII 88 and then (inaudible) 91. So even ISCII Unicode, people don't follow those standards so moving from one font to another can be quite painful and it can take a bit of money, also. So font converters, it's a big issue with us, spell checkers, dictionaries, thesaurus, again in other languages there have been efforts. But in smaller languages of the country, we don't have these tools, and only recently there has been more movement toward this. With the development of Internet, it is very important to have search engines and browsers supporting your language. All the major search engines like MSN, Yahoo and Google, they are Unicode based. But the skins of only a few languages are available. Google gives about four or five languages, Hindi, Bengali, Tamil Telugu, Marathi. Browsers we have major issues with. IE7, thankfully, displays other languages quite well, if the Unicode representation is accurate. But Mozilla, FireFox, unfortunately, quite messes up our language display, if the unique storage is not very strictly followed. So when the content is typical in fonts, which don't convert very properly into Unicode we have a major display problem. In fact, if you go to .sn.news.google.in, it shows you very good summary headings in Hindi. When you click further in about 60, 70% cases, you have display problems because on the FireFox version it's not that good. The API and (inaudible) tools, again major Indian languages, yes, there is good movement towards it. For example, I have -- I was earlier election commissioner of India that I used maps of our election results that represent Google maps API, and we could very effectively use Indian language labels on the Google maps so that was very interesting and it got extremely good coverage in the media. But a lot of APIs, unfortunately, we are not able to use. So educational software is run. A lot of content has been developed by private countries and that's very encouraging. Now, an extremely critical area where we haven't been able to reach production stages, OCR, text-to-speech and speech-to-text. The government sector as well as a number of private companies, they have come up with tools for text-to-speech, speech-to-text and OCR, but I would say 80, 90% of the levels of accuracy which is not really at a comfort level where you can use them in practical terms. Just as an aside, I went to a blind school last week as part of a (inaudible) development chapter and we were talking to the kids and the teachers. Even the English text-to-speech they have is quite American kind of English accent. So even educated Indians find it difficult to understand that accent. So the blind kids, even if they pick up English, it is very difficult. So even English text-to-speech is very American kind of accent and Hindi text-to-speech, we have some tools like Doc Check made by (inaudible) company and one of the most well-known tools in Indian text-to-speeches you have almost all heard of Simputers. They, basically, develop 20 software which they put Opensource forward. Again, I would rate it as 60, 70% accuracy. It is, basically, experimental kind of thing. Again, in transliteration and translation, in these tools, there are a lot of debates. Now in transliteration, we have reached good levels. You can see it on labs.Google.co.in. The Google translation tools are in about three, four Indian languages that are absolutely fabulous, almost error-free. And translation is one thing we're -- we still have to cover a lot of ground. The happiest part of this slide is that user-created content in Indian languages, that is absolutely fabulous. We have thousands of blogs in our national language, Hindi, more than 1,000 blogs in Malayalam, thousands of blogs in Tamil, Telugu and Bengali and other languages are also catching up. Basically, it is a user community which is generating a lot of content so same as video, et cetera. You see a lot of videos on YouTube and video-sharing sites which are English-based. Now for me as one managing dot IN domain names, the IDNs are an important part but when you see it with the previous slide, it is a very smart part of the whole game. So we need to have operating systems, we need to have applications, we need to have content in local languages. And as an icing on the cake, if I must say it, if we can provide them IDNs, it will be like icing on the cake. It is not the whole thing, but it is important. And we have been internally debating whether to go forward -- within dot IN go for Indian languages first or wait for ICANN to open up the process of top-level domains and ccTLDs in local scripts. So (speaking non-English language) that means "example" in English. So example.in or example.in written in Indian languages. Personally, I am in favor of only the full version because half English, half Hindi kind of thing is quite a bit of a joke. Basically, IDNs are meant for those people who don't understand A,B,C, who don't understand English alphabet. If the person who doesn't understand A,B,C, he won't understand dot IN also written in English. So we would like to go for full-fledged IDNs and in all the Indian languages. The major issues in IDNs are -- first is, unfortunately, and it is the most important, it is absolute lack of community participation. Until now it has been a (inaudible) driven kind of a thing, and we would like to -- for the community to come forward and raise the issues and, in fact, decide on the time frame for various things. We would like to go for indigenous Open Source solutions on this rather than take solutions from anybody. Though we have a very old copyright law and trademark laws, there is a lot of fuzziness in trademarks in Indian languages. How to convert a trademark from normal English kind of trademark into Indian language trademark. For example, the word "Microsoft," in English, you can usually think of three, four variants in which people would normally misspell it. In Hindi, I can write it in 30, 40 different ways. So multiply it by 22. If Microsoft wants to save its trade name in Indian languages, maybe they should just register about 10,000 names. And if they want to have expanded versions like "Microsoft India," et cetera, maybe they should distribute 30,000 variants. Even my name, Rajesh, I can spell it in Hindi about 40 ways. Rajesh, I can spell it, store it in seven different ways and still make it look absolutely the same, not similar. I can write my name in a lot of Unicode variants and the display will be exactly the same. It is because of the way the consonants, et cetera, come together. So it is going to be a major issue with us. Unicode ASCII issues like that slightly. Across the country there seems to be movement toward Unicode and the community is, basically, supporting Unicode. But, again, within Unicode, we have some issues in Tamil, Bengali and Sanskrit that all the correctors are not present in the Unicode pages. The IDNs, we are a bit confused whether Unicode 3.2 is now supporting Unicode 5.0 because within this we lose two, three languages. Unicode 5.0 supports two languages which are not supported under Unicode 3.2. We have seen a lot of phishing problems with IDNs in dot com and dot net. Now, in dot com and dot net, et cetera, almost 200 languages are available as pure Unicode. But even the word "bank" which would be at the heart of any bank's name, "bank" I can spell in four, five different Unicode storages and make it look absolutely the same on 90% of the systems. So, basically, it's a recipe for disaster. If in the present, any bank registers a name on dot com or dot net in Hindi or any other Indian language, there are different scores of ways in which their name can be spelled in absolutely the same fashion by a cybersquatter. These are the issues we are trying to handle in dot IN or dot (inaudible) when we move toward IDNs. Then within the same Unicode page, which means, basically, one script, there are variants and then across different scripts. So the way we are trying to reduce these problems or potential problems is sticking to a very strict ABNF form (inaudible.) Again from ISCII labels, I will just show you one Unicode subset and how it operates. This is the Bengali script page of Unicode. For example, if you see this corrector, this is R with a small dot you see here. There are different ways you can get this corrector. Basically, we have -- we can move towards a smaller subset of Unicode page to reduce the potential problems of phishing and still get all the displays possible. So if I can get a corrector by conjoining two correctors, so we are trying to make a subset of the whole page without losing any one corrector also and still getting all the displays. So the way we are moving is like this. Then our digits, the Indian digits, zero to nine, within the country, there is a lot of debate whether to use Indian version of these digits or to use international digits zero to nine. We thought that probably using the international digits would reduce the potential conflict of variants. So for each language and for each script we are trying to make this kind of subsets. That is one issue. And second is -- and in the previous subset, I showed you, basically, our alphabets, almost all languages, are made up of consonants, vowels and dependent vowels. Dependent vowel is one which can get added on to a consonant. And, unfortunately, it can tag along on the top of the consonant, on the bottom of the consonant, on the left of the consonant, on the right of the consonant or it can get embedded inside of the consonant, so all possible ways. So that's what makes phishing and pharming problems a nightmare for us. But if we stick to a very scientific (inaudible) form of defining a dash digit, basically, IDH form, international digits zero to nine and various forms of making vowel syllables, consonant syllables and then constructing the Hindi IDN or Punjabi IDN or Tamil IDN. This reduces the potential problems quite a bit. I would say by about 80, 90%. I would like to throw these ideas open from the community and we welcome their feedback on these issues because we don't want to float IDNs and then say, "Oh, we made a mess of it so please protect your trademarks and do this and do that." We want to be very correct the first time to handle all these issues the first time correctly. Another issue with us is because there are variants within languages, there are variants within scripts. If we launch one language or one script first, it gives it a message over the others. Our country as I alluded to was reorganized in 1956 on the basis of languages. It was quite a bloody battle which in various provinces we lost thousands of lives at that time in the formation of the boundaries of the provinces. So people are passionate about their local languages and rightly so. So we can't make any linguistic group unhappy. So even in the fast-track, choosing one language -- if I say I will choose one language, I will be lynched tomorrow. Another linguistic group is going to lynch me, so it is very difficult for us. That's the point we have been making to ICANN community also, that India is a vast nation, very diverse nation, and each linguistic group is extremely passionate about its language. And so on the fast-track, also it will be very difficult for us to use one language so we must get multiple languages and multiple scripts and also we can't wait for years. We request ICANN and its community to really come up fast on the solutions. We don't want to break the Internet. We want to work with ICANN and we totally want to launch IDNs within the ICANN framework and all the RFSs made for this purpose and we'll go on the same path. But things have to move fast. Thank you. Questions are welcome. >>CHRIS DISSPAIN: Thank you. [ applause ] We'll take questions. You'll take questions. I have questions if someone else wants to put their hand up, Gabby will give you microphone. You said that launching one IDN would give a massive advantage, which I understand. Does that mean, then, that you will not launch any IDNs until they are all ready? All of your language tables have to be ready? You'll do all of the languages at the same time? Because, otherwise, presumably, you are doing exactly the same thing we would be doing if you give you any one; is that correct? >>RAJESH AGGARWAL: See, there are 22 official languages. >>CHRIS DISSPAIN: Yes. >>RAJESH AGGARWAL: Unicode tables at the moment carry about 16, 17. If we go to Unicode 3.2 version, they get to about a dozen. Even within that, now we have a scenario of one language that is represented by multiple scripts and one script that has multiple languages. We have both scenarios in the country. So one language, multiple script. We have officially decided on one language and one script. So the scenario dwindles down to one script does Unicode handling multiple languages, in which the table caters to about seven Indian languages. And two Indian languages we are not sure in which ultimately they would go, (inaudible), et cetera. (inaudible) there are multiple languages. We can easily handle five, six languages, including our national language, Hindi, and two, three major languages like Marathi in one script. >>CHRIS DISSPAIN: Right. >>RAJESH AGGARWAL: Then there are issues of -- there two issues. One is if you strictly go by the number of speakers, that is one kind of table. Another is if you see Internet penetration and the number of content and the number of bloggers, that title is slightly different because the southern parts typically like people in Tamil, (saying names), Marathi, Telugu, these are the people who basically -- most of them are -- the Silicon Valley guys mostly from south India. They are quite active in (inaudible) also. These four southern languages, though they are not covered by every script table, there is a lot of demand and content in these languages. So even though not in the language in the speakers, you are missing more community demand from the southern language from the number of speakers. These issues are very critical for us, both politically, officially as well as from the community point of view. So that's why we have been raising this debate that even under the fast-track, let's move towards some bigger chunks. We obviously understand that without a proper framework in place we can't get all the 22 languages or (inaudible) languages or whatever. >>CHRIS DISSPAIN: You are prepared to do that? >>RAJESH AGGARWAL: Maybe more than one, and we obviously have to make our priorities. We understand that. >>CHRIS DISSPAIN: Just so I understand, you're saying you would be prepared to launch IDNs -- an IDN ccTLD in fewer than your 22 languages on day one? >>RAJESH AGGARWAL: Yes. First because Unicode doesn't cater to all 22 languages. >>CHRIS DISSPAIN: If you take those out, how many are left? >>RAJESH AGGARWAL: About 15. Unicode 3.2, if you go back to, about a dozen left. So you can, basically -- >>CHRIS DISSPAIN: How many of those fit into one table? >>RAJESH AGGARWAL: The (inaudible) script could cater to about six or seven, I guess. >>CHRIS DISSPAIN: Say, you got six or seven in one table and then you got another seven or eight left which go into two or three tables, yeah? >>RAJESH AGGARWAL: Each one goes to a different table practically, all those languages. >>CHRIS DISSPAIN: Right. So what you're saying is that you would be prepared to launch IDNs, not all at the same time, so you would be prepared to not have all 15 launched at the same time? Is that correct? >>RAJESH AGGARWAL: It depends on the way that things, basically, evolve. It is a very dynamic world, so we're looking at it. We are participating in the discussions. >>CHRIS DISSPAIN: But you're not actually ready yet, are you? >>RAJESH AGGARWAL: We hope the basic fundamental principle that some countries need more than one thing or one script to begin with, it should be appreciated by the community. >>CHRIS DISSPAIN: Absolutely. I agree. >>RAJESH AGGARWAL: Obviously, we will be working with the community, ICANN community and within India in the Indic community language. >>CHRIS DISSPAIN: Don. >>DON HOLLANDER: Don Hollander from APTLD. I certainly don't envy you in your working to solve these issues, but there are other language communities that have addressed this, so there is the Arabic language community that has addressed these sorts of variances and nuances. And there is also the Chinese domain name consortium that have addressed it in the Chinese language. So I would certainly suggest that you talk to them and see how they went about it. And, also, my question is in terms of India working with others who are using the same language/scripts, so Tamil is used in Sri Lanka and Singapore as official languages and certainly well-established in Malaysia, are you working -- are you actively working with the Internet communities in those countries? And if not, then we can certainly -- I'm quite happy to provide introductions because they're also quite keen to move forward. >>RAJESH AGGARWAL: Thank you for the question also and also for offering a solution to us. We'll welcome all that contact details you can provide. However, Linux communities working in these languages are quite active with their counterparts in other parts of the world. For example, Tamil guys I know, the Singapore guys, the Sri Lankan guys, the Telugu guys, they are working together. Within dot IN, within ccTLD, it's a different issue. When we go gTLDs in Bengali, we know we share thing language with Bangladesh. We have to talk to them and develop a common framework with them. Urdu we share with Pakistan. Nepali we share with Nepal. Tamil with share with three, four other countries. Obviously when we go to gTLDs, whether it is dot com in Tamil, it has to be more than one territory left for it. >>CHRIS DISSPAIN: Thank you. Gabby, could you get the microphone back, please. >>HARALD TVEIT ALVESTRAND: My name is Harald Alvestrand. Question about scripts. When you have a top-level domain name in one script, are you planning to limit registrations under that top-level domain to that script or will you permit mixed labels? >>RAJESH AGGARWAL: See, where we are looking at this is one level made of only one script and within that also sticking to a proper language framework. Within the same script, also, we have multiple languages. For example, within (inaudible) I have Hindi and Marathi. Marathi has two correctors, which are not present in Hindi. So two or three parts of the label, basically, let's say example.test, we will go a step further than script and make sure it is the same language which goes into "example" and "test." Though, some people feel that "example" could be of different script and "test" could be a different script without causing any phishing. We believe it does not add any value to the name. When people want to work in one language, they would like the whole label to be in one language, what comes in the first part of the label and second part of the label. So we will make sure it is in the same language, which is stricter than the script. Thank you. >>CHRIS DISSPAIN: Thank you. I don't think we have any more questions. So, Rajesh, thank you very much indeed. Thank you. >>RAJESH AGGARWAL: Thank you. [ applause ] >>CHRIS DISSPAIN: We're going to move on now to ccTLD updates, and I have -- as they say in this world in no particular order, dot NL, dot UK, dot KR, dot JP and dot RS. We have an hour. So one, two, three, four, five. Do you want to start, Bart? Okay. So we'll start with dot NL. dot UK will follow dot NL. dot KR, dot JP, dot RS. There will now be a small technical hiatus. >>BART VASTENBURG: If we have an hour, I guess we have about 45 minutes. Okay. I would like to give you a short update on the recent developments in the dot NL name space. And in my presentation, I will focus on the development of our services, not much detail on the operational side of things. I'll run quickly through the following slides. I will give you a short introduction for those that don't know the dot NL name space nor the organization that I work for. I will get to phasing out the third-level domains, which we are currently involved in sunrise of numeric domains, ENUM, dispute resolution and changes in the way we position our naming policy toward our customers and some technical and operational stuff. So short introduction of the organization. We have about 2.7 million domains in the dot NL. We grow at a rate of around 25% per year. If you look at unique registrants, we actually have 1.6 million subscribers, customers. So I work for SIDN. It is a private independent company. The legal form is actually a foundation, but we consider it a company like any other company in Dutch industry. And we've been the registry for dot NL since '96. We are based in Holland, obviously. And we perform activities through, around 2,100 registrars. That number has been growing very dramatically over the last couple of years. Nowadays, say over the last year, we see a steady steadilization more or less of the number of registrars, so that number isn't growing any more as fast as it used to. If you look at our service specifications, you can say our naming policy, you could qualify dot NL as quite a liberal zone. We have very few restrictions. We have no restrictions of numbers of domains that people can register. We have no territorial restrictions. We have no age restrictions. Private parties can register, companies can register, anyone in the world can register dot NL domain. So please do if you don't have one. They're great. As a main rule, we provide services directly at a second level directly on the dot NL. However, there is one exception. We have in Holland -- sorry, we have in the dot NL domain a remanence, we have a second level under which -- a third level we've been handing out domains as well. This is an example of the way a dot NL third-level domain would look like. So we use a purely numeric label to distinguish the domain. Now, this is a legacy structure from past times when private individuals still couldn't register domains directly on the dot NL. Only companies could. But we opened that up, so now since, I would say, five years, private people can register directly in the dot NL. You saw an immediate shift. You saw that everyone immediately opted for the dot NL domain at a second level. And a third level was just not interesting, it was considered as a lesser domain. We had created a zone with private individuals in mind. So it's restricted to only private people. And it's restricted to exclusively private use. Well, as you probably all know running registries, this is a very difficult limitation to enforce, because how the hell do we enforce the private use of a domain. And just looking at the demand and use, we saw that we had around 465 domains by the beginning of 2007. So, we saw this wasn't working and we also saw that these second -- these third-level domains using purely numeric space at second level were occupying space. Which we could use in a different way. So in 2006 we consulted the public, and the outcome of the public consultation was basically that we should phase out these third-level domains. So, we started preparation of the phasing out. We did that in the first half of 2007. And mid-2007 we actually announced publicly to registrars and registrants that we would be phasing out these 460-something contracts and offering a financial compensation for all private parties who would be willing to sign a termination agreement stating that by the end of the year 2007 they would actually terminate their contract and their services. We gave some possibility for extension of this term, the term of phasing out by the end of 2007, to those parties who could show significant interest. And we -- on a case-to-case basis we gave some extensions. So, by the end of this previous year we actually deleted -- yeah, almost all domains, except for the final 12 parties who got an extension from us. And they have until the end of this quarter to migrate to a different place within the dot NL name space. So that's great. Now we got rid of this remanence. And the good thing is that it makes the numeric space, which was previously used, available for other use. Back then in 2006, we also asked the public, how would you think about us introducing purely numeric domains. So, for example, one, two, three dot NL. It was basically agreed that it would be a good idea to introduce that. We also asked which would be the best way to actually introduce this name space. Our suggestion was through a big bank, just open up the doors and first come, first serve. Anyone could register dot NL. Numeric dot NL. To our surprise actually the public said, "Well, we would prefer sunrise." So we respected that, we organized a sunrise. And in order to avoid what this picture shows, I don't know whether you can see that at the back, we were trying to avoid what could be perceived as a sunrise, but once it comes up it's actually a monster at the horizon which offers tremendous challenges in terms of policy and handling of the entire process. So what we actually did, we developed a process, a sunrise. Having in mind that people with due interest should be able to go through this process, but we didn't want thousands and thousands of applications. So what we did in October-November, we publicly announced the sunrise. There was a preregistration process during the first two weeks of December, and we had only 150-somewhat, preregistrations. Which was good. Because we more or less met the initial target. With respect to the purely numeric domains for whom more than one party had inscribed we had a lottery, which was organized and done by a notary, an independent third party. And currently all registrations are being validated as we speak. And that process will end by the end of this week. And soon after all parties can actually register their numeric domains. The grounds for registration was also limited. People could only register if they could show or prove trademark or brand. The cost we used as a threshold to select parties, only those parties who had a significant interest. So we had 50 euro preregistration fee. A 250 euro validation fee and we had no appeals, so that's good. Coming to ENUM, a completely different topic. Within the Netherlands we're currently setting up ENUM. And it's the registry of dot NL, which is also responsible for launching ENUM services in the Netherlands. In the course of 2006, we negotiated with government, who back then had a delegation for ENUM. By the end of 2006 we reached agreement and the delegation was handed over to us, which was formalized in the beginning of 2007. We started organizing a public debate, which ran in the second half of 2007. And we organized like an independent platform in which we got many people together. This is a screen shot of the Web site you can visit. We had three consultations and an ongoing online debate, obviously, in which we just tried to get the layout of the rules of the game, if you will, to get those clear. And that in the final session at the end of December, and currently we're working on the final report, so that process is done. Meanwhile, at the registry office we're working hard to set up the registry operation itself. We're starting in a very rudimental form, because we are aiming at going live operational before the end of this quarter, so that gives us only another, say, month, month and a half to go. And we'll start in the very rudimentary form. So parties in the market can start playing with this technology and can get a feel to it. For this, we've set up this Web site, which shows our second line of business, basically. Completely different side looking at the services SIDN offers. As part of our naming policy for the dot NL name space, we have an ADR procedure. Like most of you have as well. Back in 2005 we had an arbitration structure which came into place. And it was used not very frequently, but it has been used in quite some cases. A couple of years later we thought it was a good idea to evaluate the use, and to see how our customers were actually perceiving this. They said it was okay, it was stable, it was well organized. But it was a bit too formal. Arbitration is also based in Dutch law, so once you get into an arbitration procedure your way towards the courts is cut off, that's it, you're stuck to arbitration. You can't go to court. That was considered too limiting. So, looking at everything we decided to move towards a UDRP-related procedure. So, in the last couple of, I would say three months, we have been rewriting our original arbitration policy into a UDRP, which is legally of less binding nature. It doesn't cut off the avenue towards the judicial system in the Netherlands. But obviously as we will be enforcing the outcome of these UDRP procedures we guess it's equally valid and useful. We have been trying to make this as large as possible, as allowing for e-mail transactions and stuff like that. In addition to our UDRP procedure, we will also be developing and introducing before the mid 2008 a mediation service. Which we will be keeping very light and very much customer focused. Obviously we understand mediation isn't a solution for all types of disputes. But we want to give it a go. At the end of 2008 we want to have a proper evaluation to see whether this meets the customer demand. I think this is one of the final slides I have. If you would go to our Web site and you would look for information about our organization, and, in particular, our regulations, you will find -- I don't know exactly, I think 12 documents. If you would print them out and you would actually count the pages, you would get to a naming policy written out in 86 pages. We thought that was a bit too much. And as we're trying to position our company more and more as a customer-focused company, we came to the conclusion that that's not what you want. That's not how you want to explain your naming policy to your customers. So we have been rewriting our regulations structure into general terms and conditions, like any other company, service company would have. We came to actually two sides of a "for" paper. The rest is just procedural detail you should post on your Web site, I guess. So that is -- that process of redrafting has finished. If you look at the content, we didn't radically change things. What we did do is we radically changed the aspect, form, of what we had. We went from 86 pages to two pages. Small letters, of course, but that's what you always see in general terms and conditions. What we also did is we accentuated how we see our customers and our registrars. So we actually use -- in Dutch term we use -- we refer to our customers as subscribers basically, rather than registrants. And in Dutch we actually refer to registrars as intermediaries, really give them the place in the value chain. And finally our own services, we call them services, as is. And we try to avoid any doubt in our local Internet community as to the legal status and nature of the domain. We try to be as clear as we can about this, making it a service contract. For our intermediaries we will be opening up worldwide. So right now you can only be a registrar for dot NL if you are based in the European Union. We'll be opening that up before -- not before the end of this year, actually by the mid of this year, half of this year. And that's basically it. No dramatic changes in the content itself. Then there's some technical and operational stuff. I won't get into too much of the detail here, simply because I really don't understand this part of our business. But just to share this with you. We did do a lot of changes in our central domain registration system. There were quite a few releases, which really took quite an effort. We really focused on stability, scalability and functional features which we added. We added over the last year, we invested a great deal in a good professional testing function within the organization. Our support side of the business, our service units have been trained. We have installed and invested quite a great deal in call routing and incident monitoring. And I think three month, four months ago we introduced any costs as well. That's more or less what happened, say, over the last, say, half a year within the dot NL name space. Are there any questions? Excellent. >> PATRICIO POBLETE: When you rewrote these terms and conditions, did they go into affect immediately for everybody? Or is there a process for that to change? I say that, because if we were to do that in Chile, consumer protection law would not allow us to change those terms and conditions unilaterally. And what we do when we made some changes is wait for the next renewal cycle for customers to accept these new terms and conditions. >>BART BOSWINKEL: We have contracts, unlimited contracts in terms of time. And your question actually relates to two things. It changes in general terms and conditions. And changes in the ADR as well, right? Because that's part of the general terms and conditions. In both cases, we looked at that very, very closely. And our conditions and jurisprudence and law actually allows us to do this. The good thing is that in both instances, both in changes of the general terms and conditions as well as in the changes of the dispute resolution policy, we believe and we're convinced that we have been facilitating our subscribers. So in relation to the previous position they will be getting into better position with better protection. Making it even easier to introduce something new. But this is something which really had our attention as well, because, obviously it's an issue. Yeah. One nice thing to say is, perhaps just to share with the audience. One of the things we did when we finished writing the rules and procedures into general terms and conditions is, we actually sent the legal documentation to a translator. Not to have it translated into another language, but to have it translated into proper Dutch so my mother can understand it. And that worked really well for us. And we've been doing that with all other legal documentation now as well. >>CHRIS DISSPAIN: We need to start moving on. Yes, Margarita? >>MARGARITA VALDES: When you offer mediation for your customers, do you ask any fee for that services or is it inside of the registry or is it an outside service? How it works, the mediation. >>BART BOSWINKEL: We're currently working -- elaborating that service. So, I don't know in detail yet, because we're working on it. But the general idea is to have it done within the registry. To give the function, the authority probably to require us to have a good mediation going on. We understand that in order for mediation to be a success you will have to have very low financial threshold. I don't know whether it will be for free or whether we will be asking some contribution. But if we would be asking a contribution, it wouldn't be very high probably. So it's not something you can earn money on. It's a complimentary service you do for your customers. >>CHRIS DISSPAIN: Thank you, Bart. Thanks, Bart, that's great. We are going to move on to Lesley now, if the slides can be made to work. Thanks, Lesley. >>LESLEY COWLEY: Okay. I've got lots of things I could talk about Nominet, but I'm just going to talk about three things this afternoon that I thought might be of interest to other CC managers. I'm going to talk about a report that we've done on dot UK. The U.K. Internet Governance Forum and the creation of a Nominet foundation. Firstly the U.K. report, glossy copy is here. I've also brought about 20 copies with me, which are on the desk if you want a real printed copy. Otherwise it's available at the Nominet Web site. We were impressed by the reports that other CCs have produced, and decided that it was about time that as a registry we also produce our own report. Because, of course, we have a lot of information that is only known to us and that other people are often very interested in. And this is our very first report. The report looks at global domain name statistics, U.K. statistics and trends, and the U.K. registrar market. There's lots and lots of information in there, but just I've chosen a few things that I think are particularly interesting to other CCs. This may sound very obvious, but for many countries the number of registrations in your country code matters very closely the country gross domestic product, i.e., the economy of the company -- >> PATRICIO POBLETE: Total domain? Generic plus. >>LESLEY COWLEY: I have the report, darling. Total CC domains versus GDP, yeah -- and, in fact, actually the Netherlands is one of the cc's that actually has more registrations than its GDP would suggest. We also, of course, looked at how many people have dot UKs compared with other countries. And in dot UK, there is about 100 names per thousand population. Worldwide there are 23 names per thousand population, so there's clearly much more room for growth in many countries as we're aware. .co.uk is by far the most popular suffix under dot UK and our personal dough name use is really quite low by comparison which isn't surprising because most countries, the personal use of domain names is really only just at its infancy. We also found that over 20% of names have been on our register for five years, and we found that once a domain has been used, it's much more likely to renew and stay on the register. So one of the things we've been doing linked to that is talking to our registrars about how they can make it much more easier for registrants to use a name to get a Web site up and going and e-mail up and going which can be quite hard. We also found, if you don't renew a name under dot UK, if can go very quickly, in fact, 7% of cancellations go within 10 seconds of the names being canceled. And this is where you're seeing the growth of particularly people who are getting names for traffic in the U.K. coming into play. We have quite many high profile organizations in the U.K. use dot UKs and, therefore, it is not surprising that the U.K. users are much more likely to choose a dot UK address rather than a dot com when they're looking at search engine results. So even if a whole range of dot coms and dot UKs come up, they are much more likely to trust the country code. Like Bart, we have a rather large number of registrars, too. We currently have over 3,000. You are welcome to some of mine, Bart. It is quite interesting the changes in the registrar community in the U.K. We're seeing many more mergers and takeovers. It's actually much more economical for registrars to gain a customer base by buying another registrar than it is for them to advertise for new business and that's something we're seeing in our market which does mean that the top 20 registrars have an increased amount of power and our top 20 registrars manage almost 70% of U.K. names which is interesting. Moving on quickly, the U.K. Internet Governance forum, as I'm sure many of you are aware, one of my staff is a member of the IGF advisory group. And as a member of that group, we felt it was very important to get national input into the IGF process and to raise awareness of this, we started what we called a best practice challenge last year. And that was around the IGF themes of access, security, openness and diversity, and we gave prizes to the people who gave us the best examples of their practices in each category. We also had a meeting in the U.K. before Rio to identify the themes that were most important to the U.K. community to take to Rio. The three that we came with -- which are protection, security and access were most important to us. We presented on that work in Rio and Rio was also attended by several U.K. members of our government of parliament which is quite unusual, particularly as our parliament was partway through its parliamentary year. And in 2008, we will be building on that work. We will do another best practice challenge. We found that was very beneficial to the community and to Nominet. But we are also trying to create a national IGF process, which is where we're bringing together businesses, civil society, members of government, the registry and ISPs to talk about some of the issues in the U.K. context in order that we can then take our themes and our priorities to the meeting that was originally going to be in Delhi, but I hear it is not going to be in Delhi apparently now. But wherever we are later on this year, we very much want to take the U.K. themes to that. Finally, just talk to you a bit about the Nominet foundation. Like many of you, Nominet is a not-for-profit organization and we are not able to share our profits with anyone, not our members and not our registrars. And it's very difficult within the Nominet structure actually to change our prices to change the price for dot UK. I actually need a member vote, all of those 3,000 people to vote for that price change. And it is quite interesting that now there is no agreement in the U.K. community on pricing. We took our prices down several times. The most recent time was in 1999 and we now charge 5 pounds for two years. I have members that would like that price to go up. I have members who would like that price to go down. I have other people who would rather we just give them the money. >>CHRIS DISSPAIN: That would be the registrars, then. >>LESLEY COWLEY: That would be the registrars. We're not able to do that. We're prevented from doing that by our Constitution. So the effect of all of this is that there is currently no price change in the U.K. But Nominet was in a situation where we have made changes to processes and we have automated many things, which means we're making a profit. We also have good staffing levels and enough money to invest in systems and infrastructure. So that sounds like a really great problem to have and, particularly, I know that some of you manage a much more difficult resource circumstance system than my registry does. But, actually I can assure you that's a bad problem to have in practice because what happens is that registrars would like the money or politicians would like the money and it's very difficult to encourage efficiency in a registry if your staff knows that actually there is no shortage of resources. And it puts the registry under quite a lot of political and other pressure. In response to that, we decided as the Nominet board to create a charity which we're calling the Nominet Foundation. And, actually, we are really excited about this because it is a major commitment for us and we're just starting the creation now, but we have already made a commitment to donate 5 million pounds to the charity for its first year and we very much hope that in the future years we will be able to make an equivalent donation so this is an ongoing commitment, not a one-time thing. And the charity is there primarily to benefit the U.K. Internet community, and we do that by giving money to fund user education, research, projects that maybe help users such as child safety or security, sharing and best practices, et cetera. It will also be able to fund some international projects, and I know that many colleagues will be interested in the element of the work; but that is not its prime purpose, I'm afraid. But I do think as dot UK, we also have some responsibility to the international community and we'll be hoping to put something back to that community through this work as well. We're just about to launch -- and I'm busy when I get back to the U.K. hopefully appointing the people who will be on the board of this charity. It is a very positive step for us and, I think, takes running a not-for-profit registry into a sort of different function as well. Thank you. >>CHRIS DISSPAIN: Thanks, Lesley. Any quick questions? I have Nashua and Roelof. >> NASHUA ABDEL-BAKI: Just a quick question. I just would like to know about the structure of the organization. You have mentioned not-for-profit. Is this non-governmental organization, society or what and whether it is a representative of government or commercial sector. Just a little bit about it. Thanks. >>LESLEY COWLEY: We are a not-for-profit private company. There are no links to our government, but we have very good relationships with our government and have done for a number of years. A member of government is on our policy body but not on our main board. The main board of Nominet is the same as any private company. We have no agreements with our government, no contracts but very good relationships. >>CHRIS DISSPAIN: Thank you. Roelof? >>ROELOF MEIJER: I don't recognize your problem at all. [ Laughter ] Now, Lesley, a question, maybe you don't want to answer it, but I'm interested anyway. If you had your way, if you could have your way, what would your proposal be for your prices? >>LESLEY COWLEY: For? >>ROELOF MEIJER: For your prices. >>LESLEY COWLEY: For my prices? >>ROELOF MEIJER: If you could lower them or raise them. Well, if you could change them, what would you propose? >>LESLEY COWLEY: I think the price is about right actually, and I think we see an increasing number of people selling names. A dot UK sold the other day 500,000 pounds, half a million pounds. So I think the registry getting five pounds of that is sort of okay. I think if they were any cheaper and for whatever reason registration rates slowed down, then you could, of course, get into a real problem that it would be very difficult to then take the prices back up. And 5 pounds is enough that it is not a huge sum of money in the U.K. >>CHRIS DISSPAIN: One more question, Calvin, because we do need to move on. Thanks, Calvin. >>CALVIN BROWNE: Sorry. It is not really a question. >>CHRIS DISSPAIN: In that case -- >>CALVIN BROWNE: It is more a comment. You really want to keep the amount that you charge slightly higher than what it costs to collect the money in the most expensive form. >>LESLEY COWLEY: Good point, Calvin. We -- it doesn't cost 5 pounds to collect the money at all. We have a lot of -- our registrars pay by direct debit, et cetera, so collection is not a huge element of cost for us. >>CHRIS DISSPAIN: Okay. Thank you very much, Lesley. We're going to go now to Korea for a presentation. We are going to be -- we are going to run out of time with this unless we can speed it up a bit, so if I could ask -- and what we may do depending on the timing is -- because after a coffee break, we are going straight to the GAC. So what we may do, if the timing runs away with us, we might push one or two over, perhaps, to tomorrow morning, but let's see how we go. Good afternoon. >> HANSANG LEE: Good afternoon. >>CHRIS DISSPAIN: Go ahead. >> HANSANG LEE: Good afternoon, everyone. My name is Han Sang Lee from dot KR. We don't have a lot of time, so I will try to make it short and quick. Today I would like to introduce you to two services that recently dot KR has developed. One is the dynamic update and the other one is the WHOIS API -- WHOIS openAPI. The dynamic update was developed because of the complaints from the customers. Mostly I think the Koreans are the speediest peoples in the world and they really want everything to be done quickly as possible. And when they register their dot KR domains, they really want it to be -- to use it right away. And, of course, when -- so that's the main reason why we developed dynamic update services. So actually, this is not a theoretically -- the meanings of dynamic update, but this is what we are trying to do. Before the dynamic update, we updated our dot KR -- total dot KR zone data three times a day, 8:00, 12:00 and 18:00 hours. After then we developed this dynamic update system and it was update -- actually the zone data was updated less than five minutes, minimum was, like, 100 seconds -- less than 100 seconds. This is a system diagram we developed. This is before dynamic update. We used to -- we had the registrars using their EPP protocols to register to our database and we aggregate those data three times a day and put our zone files to our master servers. And after that the hidden master name server did an all zone transfer to our slave DNSs. After that, this is the diagram after we developed the dynamic update. The main things are the same as before, but one thing is we built up the update program to actually update the zone data to our dot KR DNS directly and so this update program actually, what it does, is it initiates an all-zone transfer once a day for synchronization and it checks for any other updated zone data every one to five minutes. There were some pretasks to be done before we implemented dynamic update. One was the hardware upgraded for every dot KR DNSs for BIND9. And the hardwares were -- some of the hardwares were more than ten years so we have some problems with the performers, and we didn't want -- we didn't want the service to be slow so we updated most of the hardware since the year 2006 and, of course, we wanted to get all the monitoring to be done for the protections and security reasons. And that's why we upgraded all the monitoring systems as well. The other one was the IDN servers. In Korea, most of the IDNs were -- I mean, most of the browsers were used -- customers were using browsers Microsoft Internet Explorer 6, so we had to implement some calls for the IDN service in India BIND software. This took a little bit of time, also. Finally, we upgraded all of our namer server software to BIND9. This is a diagram of South Korea in the middle and all the locations around the world we have dot KR DNS installed in. Over here, you can see that did dot KR is located in western part of America, Railroad City. It used to be -- we install this in August 2007 and this one was the oldest one to be upgraded. So we did it -- finally, we upgraded it in India in year 2007. After that, most of the queries are -- this is a diagram of our monitoring system. This part you can see all the traffic coming in and queries per second, CPU resources left or something like that. And as you can see, the dot KR DNS has top queries like 3,000 queries QPS, queries per second. Another thing that we changed was the sequence of the serial number in the SOA record. We used to use the sequence in the data and time -- ordered by date and time. We changed it to -- when you use dynamic update, you need to update it more than 10,000, I guess. So we changed the seconds to year, month, date to year, month -- year and month and date. And we put out the time section. Instead we just counted how many times it's going to be updated. This is a graph that shows since we launched the dynamic update service, it was implemented in the year December of 2007. The maximum update counts were, like, 9,000 times a day. A little bit closer look at the updated times. We have all the dot KR zones including the second level and the IDN and our right side. Mostly, co.kr which is used for commercial uses has the rapid updates. And, secondly, we opened up the second-level domain for dot KR and that's the second one. Next is the WHOIS OpenAPI. We are trying to satisfy our customers who want the queries -- want to know the actual information about their domain names. So we kind of developed a service for -- actually, the service for the customers who wants to check out their domain names. So services are like this, but it is not open yet. It should be open by March, and we are trying to issue the user key to only the registrants first and then spread it to public uses in the near future. This is parsing data that shows when you use the OpenAPI. It indicates the domain names and all the information of the user who registers that domain name. Thank you. Thank you very much. >>CHRIS DISSPAIN: Are there any questions? Olivier? >>OLIVIER GUILLARD: Thank you, Han Sang. Just one quick question about the dynamic update. You said that you sent a DNS packet to update the zone every five minutes now? >> HAN SANG LEE: Less than five minutes. Minimum is like 100 seconds. So when a user registers a domain name, they can use it less than 100 seconds. >>OLIVIER GUILLARD: Okay. And I suspect that you choose the time to send this packet for updating the zone in function of the number of registration you have in entrants. What's the size of the packet? I mean, how many registration per five minutes do you have and do you send on average? >> HAN SANG LEE: It depends. The sequence depends on the time and the amount of -- no, it is, basically, on the time. So every 100 seconds, the update program actually checks how many zone data are being updated. And then it doesn't matter how big it is, it just sends it out. for every 100 seconds. >>CHRIS DISSPAIN: And if I understand it correctly -- and I am as almost everyone in this room knows I am no technical expert. If I understand it what you have actually done going to dynamic updates, you currently cannot use DNSsec because DNSsec doesn't work with dynamic updates? It's changed now? It's fixed? Because it used to not work. Can you give the microphone to Olivier? Thank you. >>OLIVIER GUILLARD: I am not the best one to talk about it, probably. >> It works. >>CHRIS DISSPAIN: It does work. >>OLIVIER GUILLARD: The thing is with -- with dynamic updates, the signing process has to be included in the dynamic update's operation which changes a bit the way you put this process, but it works. >>CHRIS DISSPAIN: It does work, cool, as I've just displayed how completely non-technical I am. >> HAN SANG LEE: That was one of our considerations, too. When we were talking deployment DNSsec, the sizes were much larger. Without dynamic update, I think it will be having some problems. >>CHRIS DISSPAIN: Okay. I understand. Any other questions? Okay. Thank you. I think given the time we will roll dot JP and dot RS presentations to the first thing tomorrow morning. We have a little time available so I'll get to Hiro, Slobodan to make their presentations in the morning, and our next session is at 3:30 with the GAC in the tent outside near to where the lunch place is. It's called -- I think there is a sign on the door that says Jaipur, yeah? I have no idea whether they will go for coffee and be ready at 3:30? But we need to be ready at 3:30 and then we have an hour with them and then we come back here for the regional organization updates, which Margarita has very kindly agreed to chair. Well, actually, was forced to agree to chair. So if we can take whatever you want to take with you to go to the GAC and we'll be there at 3:30. Thank you all very much. Will the room be safe and locked? No idea, Bill. My suggestion would be that you stay here for the whole time. (Break) >>CHRIS DISSPAIN: Ladies and gentlemen, our last session this afternoon is on update from the regional organizations. I have to go to a meeting, so my apologies. But I have asked Margarita to chair this session. If I could just remind everyone that we start tomorrow morning at 9:00 o'clock. We have a fairly busy day, although it may finish at lunchtime, depending how much we get done. But we have members meeting and then the council meeting tomorrow. So if we could try to be here for 9:00, that would be great. We are going to start with the presentations that we missed from dot JP and dot RS. And then we'll move into IDNs, which will be in two sessions. There will be a discussion of the initial draft document that we had the workshop on yesterday. And we'll also then have a discussion, of course, on the joint meeting between the ccNSO council and the GNSO council yesterday. I can hardly wait. So, I'm sorry I can't stay for this, but I will see you all in the morning. Thank you. >>MARGARITA VALDES: Okay. Is Vika here? I don't see him. All right, okay. So, continuing this afternoon's session, we will have the update from the regional organizations. Instead of Vika I will start with Don Hollander, APTLD. >>DON HOLLANDER: Thank you very much. I will go quickly because it's just us between you and the bar. So this is APTLD. For those of you who don't know, we cover ccTLDs in the Pacific, in Asia and the Middle East. Our cultural diversity is huge. Our language diversity is huge. And our geography is huge. Our plans, I'll go -- not focus so much on 2007 but what we're doing in 2008. We've got at least four meetings intended. One is our AGM at the end of this month in conjunction with Apricot. We'll have a meeting in May in conjunction with the WCIT. We'll go to the Cook Islands in September in conjunction with PacInet. And the current plan is to have the meeting in conjunction with the IGF, which we thought was in Delhi, but Lesley tells us we're going somewhere else. That's okay, we're relaxed, we're very flexible, nimble. >>PATRICIO POBLETE: When do you guys work? (Laughter) >>DON HOLLANDER: So the key issues for APTLD are IDNs. But after tomorrow, that will be well and truly sorted. So, thank you very much for your support there. Just in terms of the APTLD catchment area represents more than 50% of the world's population. And most of the world's people who can't recognize ASCII characters, or a few others in Europe and Northern Africa, but by and large that's in the Asia-Pacific region. The second key issue for us is surety and security. We think that DDOS is the number one issue facing ccTLDs. And we have a program planned for this year, which we are quite happy for anyone to participate in, to look at it from three aspects. The first is a training program in disaster and attack planning programs. So the larger ccTLDs will all have disaster recovery plans that hopefully are in a very dusty cupboard and taken out just once a year just to make sure that they work. But not all the ccTLDs will have that. We're also working on a technical training workshop so the geeks in the ccTLDs will be able to learn how to build robust networks, and also build attack networks and have them go at each other in teams. And a third area we're working on is to engage with the various Anycast providers to facilitate those services for the ccTLDs. The fourth area for APTLD members is commercial success. And the third area and fourth area is creating and building on partnerships. The three of us here, and Vika when he shows, is another partnership that's gaining further momentum, started last year and gaining good ground so that the RTLDOs or ROs, whatever, so we're all working together and taking the best ideas from one another. So, our plans 2008 engage with international governmental organizations. Again, this is where CENTR has been quite engaged with the E.U. APTLD will engage with comparable organizations, plural, in our region. We'll support one another's technical training programs, so when one of our members is having some technical -- domestic technical training. They usually leave one or two spaces available for other APTLD members to come and attend. Provision of best practice surveys, benchmarking on customer satisfaction. Again, building on the work that CENTR has done. The DDOS planning and mitigation, Anycast facilitation. And the end of this month we'll be celebrating our 10th anniversary, so if anybody wants to have a fantastic party in Taiwan, you are more than welcome to come. The Taiwanese are fantastic hosts and a good time will be had by all. And my board is very keen to make sure that our membership continues to grow. Our training program in May will have a full day workshop on policy development programs. Also in May we'll have a full day program in marketing of a ccTLD. In our December meeting we'll have a one or two-day program in nontechnical training. We ran one last year in Bali, another one in Dubai last year. And they were very, very well received. Quite appropriate for new management members, new board members, new advisory council members. We'll have the ADRP and TBA and the DDOS Technical Association at some point as well. So there are more acronyms for people. I talked about the DDOS issue. We're looking to run that in partnership with ICANN with APNIC and members and others. Our meeting in Taiwan will focus on IDNs, on security, DNSsec. That will be quite an interesting session. One of the top presenters has their topic. DNSsec journey not destination. And commercial topics and our AGM. I'm quite delighted that we're currently going through our elections at the moment and for the four board positions where I think in the past we usually got four nominations. We have six this time so we have quite keen interest for people to get involved or else there's loot of people who think we're not doing it right and want to do it better. That's APTLD. If you have any questions, please let us know, just send me an e-mail or see our Web site. So, thank you very much, Margarita. >>MARGARITA VALDES: Thank you, Dan. Any questions? No? Okay. Let's continue with Peter van Roste from CENTR. >>PETER VAN ROSTE: Thank you so much, Margarita. Good afternoon, everyone. My name is Peter Van Roste, I'm the CENTR general manager. I'll keep this presentation to a minimum. My goal for this presentation is that if there are any issues that you're interested in, you know that we're working on them and you can contact me for further information or to cooperate. I'll even signal when I think the most relevant points show up to make your life as comfortable as possible. What is CENTR? I guess the majority of this audience is familiar with what CENTR is doing. We're a regional organization, we're focused on Europe. We have 51 country codes, top-level domain members. We have four generic TLDs as an associate member. In total we're just under 14 million country code top-level domains. And obviously we are hoping that the next time I'm presenting to you we will have reached the 14 million mark. Our meeting themes for 2008. And let me underline that everyone is welcome, not just the CENTR members. There are even sponsorships for those who would otherwise have difficulties to travel to CENTR meetings. But our meeting themes for 2008, the first one coming up is in Brussels the beginning of March. The broader team is registry organization. We will be focusing on outsourcing. But also on lot of practical issues. We are in a fortunate position where we have two of our largest members who just moved their registry and that's pretty interesting topic to share with the other members. Another topic that will be high on the list in Brussels is the European electronic communications framework directive. What does this mean? The European union is obliged according to its own rules to review the existing legislative packages every four years, it depends, sometimes five or six. In the case of the electronic communications directive, the package that was approved and agreed in 2003 is now up for review. In that review process, in the redraft the commission added naming and numbering among -- in the scope of the directive. Which basically means that under the current plans but let me underline that these are not finalized yet that under the current plans registries would fall under the authority and scope of the regulatory authorities in Europe. Which would mean a world of difference, of course, to all our European members. The next general assembly will take place in Crete in June, and the team there will be new service marketing, will be particularly looking at the different factors that influence the registration of the domain names in a specific ccTLD. We also have administrative, legal and regulatory and technical workshops, administrative workshops will focus on EPP, registry/registrar relation and system migration. And the legal and regulatory workshop will be focusing on the Internet fraud, again the E.U. regulation for obvious reasons. And in particular case where we are fighting fraudsters that are acting as registries in order to trick people into false renewals. So that's the D.A.D. case. If anybody else from anywhere else in the world has similar issues it would be great if you can contact me because we're still long way from solving this issue. The next item I would like to bring to your attention, this is one where I would like to get your feedback after the session is on IGF in Rio, together with the other regional organizations, we organized two very successful workshops on relevant themes for the ccTLD community. We also had a booth that represented not only the regional organizations but also the individual country codes top-level domains that did not have the resources to have booth at IGF. We're planning similar initiatives for the upcoming meeting whether it's New Delhi or anywhere else in the world F. you are interested, feel free to contact us we can make sure that you get support. Projects for 2008. We finally have our domain counter going live to the main counter, it's an automated tool that gets the domain statistics from our members' Web site and only for full members. Puts them in an interesting table that allows comparison, that shows trends compared to the BNP population, e-commerce and I think broadband penetration, these are all things that are coming up in the next few weeks or months. But the test phase went well, and so it's finally working. Based on a study that APTLD organized, we have contacted Zucnic to look into those factors that influence the uptake of domain names that it's coming up in the next two months. Our secondment project finished. Very briefly, a secondment project is where members send an employee to the center secretariat. And that employee will be working on a CENTR issue. And the issue for this one was Internet infrastructure, because it ties in very nicely with the discussions on security: What is critical infrastructure, what is the role of registries. So we have some substance to add to the debate. A couple of legal projects, that I'm not going to go into any detail, but feel free to contact me on that. It has already been mentioned we're running again our A-level survey, which is a big-level survey, about 90 questions, ranging from their relations with the government to statistics, to processes, to the interface that they have, whether they're registrars or they're registrants. There is a wealth of information to be drawn from that A-level survey. I will make sure that, if there is interest, I will present the summary of that during our next meeting. And this was an exercise that took much longer than I was hoping for, and succeeded in filing an NTIA response to the NOI. Summarized, we think, ICANN is doing a better job, there is still room for improvement. And there are two things that need to be addressed immediately. That is the name server changes delays and the IDN introduction to the fast-track process. A brief reminder that it's already four months old, but I still consider this is a new Web site. I have -- I'm sure that you will find plenty of information that might be relevant to your daily business. Also for nonmembers, by the way. I've listed our next meetings, next week we have two workshops in Vienna. And then we have our General Assembly in Brussels and a technical workshop in Cologne, in Germany. That's it for CENTR. Thank you. >>MARGARITA VALDES: Peter, so are you ready? Okay. So now I will let you -- to AfTLD, Vika Mpisane. >>VIKA MPISANE: Thank you, Margarita. My name is Vika Mpisane. I am the secretary and treasurer of the African top-level domains, the original ccTLD association for Africa. Also, the general manager for the dot ZA domain name authority. I had a brief presentation really, but it's just a couple of points. We do not have as much detailed projects to an achievement as CENTR AP gTLD. We have been developing particularly over the past few months with a lot of groundwork for AfTLD, since in particular ICANN L.A. in November last year. I think the key things for us that we've had to sort out has been a couple of things surrounding the AfTLD constitution. We've been working also with a lawyer in Mauritius to try to clean that up, to empower AfTLD to be able to run as an organization that is supposed to run. That process is coming toward a close now. We are quite happy with that it defines our terms of reference. It defines issues of membership much better than it was before. Parallel to that process, we also started formalizing membership with ccTLDs in the region. There were some concerns among the ccTLDs mainly in the region that there was sort of a presumptuous structure to AfTLD that all African ccTLDs listed in the IANA database become members to AfTLD. And people are not really that comfortable with that approach. So we have been working on that one. We have been sending out membership forms, defining what "membership" means, free membership and also contributions. And that process on its it own, (inaudible), if I can take it from the top of my head, we probably have 12 ccTLDs now that are from our members of AfTLD. Dot ZA being one of them, that is now a member of AfTLD. We are also a member of the ccNSO, finally. So there has been some movement there. I think -- other than that over the past few months since ICANN L.A., we've participated at the IGF in Rio de Janeiro. As Peter alluded here, we participated in a couple of panels at CENTR and other ones that the present of AfTLD made presentations on, Mawaki Chango from Kenya. So that's been some movement. Other than that, you probably know about some submissions as AfTLD we have made to ICANN on the issues of IDN fast-tracking and also on the issue of regions even before that. For all these issues where we do submissions, obviously, we send something out to the ccTLDs. We propose propositions. On the IDNs, it was even easier because APTLD came up with a position they had taken and it was easy for us to send it out and see what ccTLDs thought about it; and there was a common possibility. We managed to have a common position on that. There has been some movement. We were supposed to employ somebody full-time as a manager. We delayed that a bit. We sat as a executive committee and we looked at the timing of things and we thought were there resources to manage -- or accumulate resources well enough to employ somebody with fairly good experience probably on a two-year contract or so. We needed to probably time that better. So we've delayed that. But in the next few months, we hope -- particularly when we go to ICANN Paris, we should be coming there having a full-time staff member to run AfTLD's activities, to attend other regional fora like APTLD, like CENTR invites us. But because we are all having our own daytime jobs and full-time jobs elsewhere, we could not come to those meetings. That's one important development. The final one that I will hint to is the unlimitting of AfTLD. Last year we had one in Cairo, generously hosted and sponsored by the Egyptian government. This year meeting we are meeting in South Africa from the 7th to the 11th of April in Johannesburg. Again, we are also generously hosted there by the Department of Communications in South Africa. We will be sending out this week a lot of updated information. We first sent out something to the mailing list last year saying that it was going to be Capetown. Initially, we thought we were going to go to Capetown; but afterwards, due to venue complications in Capetown, we had to look at Johannesburg at a place called Sandton. We will be sending updated information on our Web site later this week. A couple of ExCom members are here. We waited until you can sit down for two hours or so to flesh out a couple of things, logistics, travel arrangements and then the (inaudible) problem itself. You will hear about the original organizations that we mainly work with, that will be updated and we will put it on our mailing list. We believe also through Gabriella you will see it, the agenda and other things. That is, basically, what has been happening on AfTLD and what will happen in the short-term. We hope that this African meeting in particular will help us to come up with a fully-fleshed strategy plan for the next two or three years or so. We are also going to appoint a new executive -- a committee for AfTLD in South Africa. It will be a new board in terms of our constitution and what the Mauritian company (inaudible) calls a "board." So we are going to have a new board. We've been for the past few years in interim transitional structure now to spearhead the AfTLD and to revive it, basically. So we hope that you will give us some good leadership. I don't know if a couple of faces from the current board will be there or whether Mawaki or Mohammed is there. Hopefully, there will be a team to take us forward for the next few years. I thank you. >>MARGARITA VALDES: Any questions? Okay. Thank you, Vika. Okay. Now -- sorry. It's working? Whoops. I see. Okay. Well, about LACTLD, a brief report of activities that we had. Since the L.A. LACTLD meeting in November, we held a Caribbean-Latin American meeting. The first approach with non-Spanish and non-Portuguese ccTLD speakers that were present there. And we tried to continue this approach and something very interesting for us was that after that we received an application from Trinidad and Tobago to be part of LACTLD. So we are trying to find a way to work together in the particular and very sensitive matter that is the language because we work all our mailing lists and meetings in Spanish and Portuguese and we can understand each other, all the members in these two languages. But the circumstance that we use in international meetings is English, like a flat language. Sometimes it's not well--- or very well understandable for all the associates. So we need to deal with that. But we are optimistic about it. Another thing that we did at the end of the year, 2007, was the IGF participation that we had with CENTR that Peter said recently. And we were glad to be invited, and we are available to do anything else that could help in the IGF in 2008. >>PETER van ROSTE: Excellent. >>MARGARITA VALDES: We will have our dinner and assembly in May between 26th to 30th 2008 in Salvador de Bahia in Brazil in conjunction with LACNIC meeting -- the annual LACNIC meeting. And the activities that I can see because I didn't met Michael since November, we have to do the work to review the strategic plan that we had in Sao Paulo and Isla Margarita last year. We had a very successful training seminar in October about DNS, and we are planning to have another one probably without -- with other people from the community or the second step of these contents. And we are trying to figure out to make another seminar about business models between our community. And we note that one of the seats from the region in the ccNSO Council was renewed with Patrick Hosein from the Trinidad Tobago, dot TT. He has been elected. And there was a change that, it's interesting for us because it's the first participant from the Caribbean region. And the point is that we are on summer season and summer season in Latin America is holy days, so there is not many people that answer e-mails or things like that. Also, we are just -- many of us still working in this meeting, for example, and we have dot CL, dot MX, dot BR and dot BE. That's it. And if we need more information our Web site is www.lactld.org and there is my e-mail, mvaldes@lactld.org. Any questions? I think we are done. Thank you for your attention and patience. On behalf of this journey, this is the end of this meeting. So thank you very much. And we'll see you 9:00, as Chris said. Thank you. [ applause ]