ICANN Brussels ccNSO Members Meeting Tuesday, 22 June 2010 >>CHRIS DISSPAIN: Ladies and gentlemen, there will not be more than about 150 people in this room this morning. If you are sitting in the back, that is not a wise idea. Would you please come and sit in the front section of the seats, so that I can see you, you can see me, and we can all love each other. >> Also, everyone should know the back section, there will be no power back in the back section. It's being turned off today, so you must sit in the front. Thank you. >>CHRIS DISSPAIN: There will be power if I stand there. >> Absolutely. [Laughter] >>CHRIS DISSPAIN: I'm just testing. Is it working? Great. Thanks. >>CHRIS DISSPAIN: Ladies and gentlemen, the sharp-eyed amongst you will have noticed that it has gone 9:00 and we have not started yet. We will be starting shortly. Actually our first session is on money and Kevin is on his way, so we'll be starting in a little while. >>CHRIS DISSPAIN: Okay. Good morning, everybody. We're going to start in about a minute's time, so if you could please grab your seats, grab your coat, get your hat, leave your worries on the doorstep, and we'll get going. I'd like to start with a thanks to ICANN for giving us the big room again, and also great thanks to Nancy for organizing for there not to be a brass band playing outside this morning. Nairobi was fun for, oh, so many reasons, that being one of them. So we are -- welcome, and it looks like there's about four people in the room because it's so huge, but Gabby, we're missing Kevin. Missing in the sense of he's not here. We're not missing him. Sorry? Quarter past. Okay. Cool. Excellent. So welcome, everybody, to the ccNSO members meeting. We've got a busy two days, and we did -- we did actually have a session on the IDN policy development process which some of you were at, and that was useful from many respects, but not the least of which we finally figured out that the technical community was waiting for us to come and talk to them about something, and we were waiting for them to come and talk to us about something, and so probably if we just talked to each other, we might actually be able to sort it out. So that was a win. This morning we're going to talk about money. The -- Kevin, when he gets here, will be doing a brief overview, but Byron, you can start. >>BYRON HOLLAND: All right. Good morning. As Chris says, this morning we're going to talk about money, and this is on behalf of the strategic and operational plan working group. As you know, we have -- our primary goal has been to stimulate interest and participation in ICANN's operating plan and strategic planning process, and right now we're in the final stages of the operating plan. So it's money morning to kick off the ccNSO meeting and I think one of the interesting things here is always the notion of "follow the money." And if you follow the money, you will see where the priorities of an organization lie, and I think from that perspective it behooves all of us to pay close attention and get a real sense of what ICANN is saying the priorities are. And then secondarily, to have a conversation are those the priorities we believe in and is that the right course and path, and are the monies that are being spent appropriate for the output. So what we want to do is -- really is sort of a two-phase discussion this morning. One is, Kevin is going to give us a fairly detailed run-through of the operating plan, where it's at right now. Also, one of the elements that he's really going to bring to bear is a more detailed expense analysis, and I think that that is something that the community has really been asking for for quite some time, and in working with Kevin, our working group I'd say is fairly pleased with the progress that's being made there in terms of the level of detail. I don't think it's helpful for ICANN to, you know, open the GL codes, per se. I don't think that that's going to be helpful to the debate. But there's another level of detail that's going to give us a lot more granularity and clarity in terms of the allocation and, hence, the priorities that ICANN is stating. So we should take a good close look at those. That's going to be probably the bulk of the discussion this morning, but also that leads to something that we probably all know is coming, and that's a conversation about the contributions made by the cc community to ICANN. That piece of ICANN's revenue. And as we probably all know, there is some discussion about is the level appropriate, how is it actually paid, by who. So Chris is going to give us a retrospective on cc contributions, as I'm sure only Chris can do, and then we'll initiate a bit of a discussion about cc contributions, where we're at and where we should be headed. So I think given that Kevin isn't here yet and now I'm basically stalling for time, short of telling you stories about money I think maybe what we'll do is flip it around and hand it over to Chris and he can start with some of the history of cc contributions. >>CHRIS DISSPAIN: Okay. Yeah. And when Kevin -- when Kevin gets here -- and he should be here any second -- we'll let him do his bit. The council -- ccNSO council at its council meeting in Nairobi passed a resolution which basically said that we appreciated all the work that ICANN had done, we recognized that there is a gap between what the ccTLD community pays to ICANN and the amount of money that ICANN thinks should be paid, and we reaffirmed -- as a starting point, we reaffirmed the current guidelines that we use to assess payment. So I thought given that time has moved on since we did the guidelines, it might be an idea to briefly go through how we got to those and what they mean. Now, I am notoriously bad at dates, so if I get the dates wrong, even by years, don't be surprised. But once the ccNSO was formed, which I believe was this century, once the ccNSO was formed we talked about how we would deal with paying money to ICANN, and we set up two working groups. We set up one working group to look at a methodology for making payments, and we set up another working group that was actually looking at the finances. How much does ICANN spend. And in those days -- 2005, I guess -- the ICANN accounting system was opaque, to say the least, and we were still saying what we had been saying for many years, which is, "Can you please tell us how much you spend and why?" In the end, those two working groups really effectively came together, and what we decided to do was to draw up a guideline on payment. And in summary, that guideline says that you should pay. Payments are voluntary, obviously, but you should pay. And that, "Here is a list of what your colleagues in the ccTLD community paid last year and you should look at that list and say which one of these TLDs that is paying am I closest to from the point of view of structure or number of names, or whatever, and pay roughly the same amount of money as them." And the example we used at the time and we continue to use is the Canada and Australia roughly similar structures, roughly similar number of names, you know, so therefore, were we to be looking at the list, Australia would look at what Canada pays and say, "Well, that sounds about right." Now, that has worked to a degree, because the amount of money that ccTLDs pay ICANN has (a) gone up and (b) the number of contributors has gone up. But we currently -- in this financial year, Bart, is it 1.8 million, we think, roughly? Yes. So we think in this -- at the end of -- coming up to the end of June, the contributions from ccTLDs for this year will be about 1.8 million. Now, we're getting now all of the detail from ICANN. I'm not suggesting that it's complete yet, and that there aren't other bits to find out, and hopefully when Kevin eventually arrives, he'll take us through his slide on a breakdown of what ICANN says is ccTLD responsibility. But irrespective of that, I think it's clear that we do need to try and find a way of dealing with cc's contributing to ICANN. If we were able -- there are a real number of "if's" in this, okay? If we were able to agree a figure that we as the ccTLD community generally thought sounded about right -- just say that we looked at the numbers and we said, "Well, you know, yeah, IANA, meetings, a few other things, not a problem." Let's say we agreed a number. The question is how do we pay that number. Understanding that the principle of being voluntary is absolutely set in stone, but nonetheless even if it's voluntary, if you're in the game, if you want to support this model, the ICANN model, you really need to contribute and to pay. So one way of doing it, for example, would be to say it's -- there are 250 ccTLDs, I think -- say 250 -- Aha, Kevin. Try not to fall over. Like yesterday. There are 250 ccTLDs. If everybody paid $10,000 U.S., that would be $2.5 million. And it's not our job to collect it; it's ICANN's job to collect it. It's up to them. So we just pay what we pay. So you could just say why make a distinction. With any ccTLD, just say "This is the number" and you divide it amongst them. That's one way of doing it. There are a whole heap of other ways, which we'll talk about, but we wanted you to star now and take us through your presentation. Would you like to do that? >>KEVIN WILSON: I would love to. >>CHRIS DISSPAIN: Okay. >>KEVIN WILSON: Thank you for your patience. >>CHRIS DISSPAIN: You'll need to turn the microphone on. So do you need to say anything or do you want to just -- >>BYRON HOLLAND: So just to quickly reintroduce Kevin Wilson, who is the CFO of ICANN. He's the person that our working group, the SOP has been working very closely with, and Kevin has provided considerably more detail over the course of the last year and been very helpful to the working group, so today he's going to talk us through where the operating plan for the coming year is, and then also he's added a slide that -- okay. He's going to speak specifically to some of the more detail -- some more detail in terms of expenses. So as I -- as I started the morning with, you know, this is a tale of money and priorities, and I think it behooves us all as a community to pay close attention and follow the money to get a sense of what ICANN's priorities are and then make sure that they align with our priorities. So with that, Kevin. >>KEVIN WILSON: Great. Thank you, Byron. Thank you, Chris. Can everybody hear me okay? I'm going to assume yes. Good. Thank you. As you know, I'm Kevin Wilson, the chief financial officer for ICANN, and I'm excited to present our budget, which will be submitted to the board for adoption on -- at their Friday board meeting. So today's purpose is to just do this very important process at ICANN, which is encourage community feedback. And I think we've -- we've received more community feedback than ever this year, in the last couple of years. It's grown and we want to just continue to encourage that. We'll provide some highlights of the operating plan and budget, and then highlight some of the changes that were made, in particular, in response to community feedback, and then just highlight the next step which is to submit to the board for adoption. So we wouldn't be ICANN if we didn't emphasize the process, so this is really just a one-slide description of the process. So I think most of you are familiar, but just to recap for those who might not, the strategic plan is attacked and developed, and this year it was simplified, largely from input from -- and feedback from the community to -- I call it the one-pager. Very simple strategic plan with four focus areas. And that was adopted and posted in February. Shortly thereafter, we posted the framework for the fiscal year '11 operating plan and budget before Nairobi. We had a number of community calls, the meetings in Nairobi, as well as community calls after the Nairobi meeting. We synthesized all that feedback and then we posted the draft budget which is longer and more detailed than ever before and hopefully didn't put too many of you to sleep. But I think it really reflects a lot of effort of the community and staff and the board on providing the level of detail that the community needs to approve a budget. And then we've also had several community calls since that posting, and then obviously these meetings this week in the Brussels meeting, and we'll submit to the final budget. So that's the process and then it starts all over next year. So just to recap, I know community feedback is really important. This is just to give you a feel for what kind of feedback we received. There were about 20 conference calls and meetings. There was about 70 pages of online postings. There were several board briefings. The GNSO resolution for a specific request. That's -- at least in my time at ICANN, that's the first time where they had requested a $400,000 set-aside for fact-based studies to help on WHOIS policy development. And we also provided 19 pages of analysis of those comments and those included a need for more detailed information, so we -- that seems to be a common request, and like to hopefully count it -- responded well to that one. That one's -- so we provided more information than ever before, and more views. There were also some specific requests for more resources in specific areas. Revenue management, there is requests to make sure that we're really buttoning down our revenue, and there were some operations suggestions and always there's cost reduction suggestions as well. So our responses were captured, and in particular the -- sort of the highlight of the responses, there were more details. We provided that. The request for more fact-based studies, we provided that both in the SSAC arena on scaling and other areas as well as, as I mentioned, the WHOIS study arena. There was more at-large support requested, and we felt that we increased -- there's incremental staffing increases there. The -- there's requests for fee/cost adjustments in various areas, and I think that's being considered, and I think when I walked in, I heard Chris talking about that, so that's obviously an area, as ICANN's activities become -- the requests become stronger and stronger for more and more activities, with he need to make sure that we're fiscally responsible and not overspend our revenue model. We also, this year, queried all the sources of revenue -- the RIRs, each registry, each registrar -- and provided them the details in the document and said, "Are these assumptions valid? Are these the number of transactions you're expecting next year? Are these the numbers of renewals?" Et cetera. And so we're hopeful to continue to make progress on that. So it's an "our" budget, not just a staff budget. Real briefly, on the budget background, the substance of the budget, that -- many of you know that mostly as a result of the contracts, particularly the VeriSign.com contract, revenues increased significantly over the last four years. But the FY '11, the next year's fiscal budget, shows a fairly slow revenue growth of about 3%. Over those same years, the operating expenses have grown, so that it matches that, so there's really a challenge for us, as we prioritize. As new activities came in, we had to find places to save, similar to many other organizations. So that discipline is getting stronger and stronger at ICANN as we identify costs that we need to save, whenever a decision to increase an activity comes forward. As far as contributions to the reserve fund, some have asked about that, and I just wanted to make confident that even though we had -- in our midyear review we identified and we continue to identify that we'll spend more than our operating budget for FY '10, there still be contributions to the reserve fund, just at a lower amount than we had originally anticipated. And so the -- as far as the reserve fund itself, it's at about 45 million now, so even with the turbulent market, it has a fairly conservative investment policy, mostly in bonds, and so fixed-income instruments, and that's -- so that's -- the message there is ICANN's finances are still strong. This is a one-page capture of the budget, showing the FY '10 budget in the green and then moving across the forecast, the FY '11 framework and then the FY '11 budget as proposed. So we have a $65 million revenue line item. The operating expenses, which includes a million and a half of contingency, of 60.8, and drives to the bottom line of contribution reserve of $2.1 million, and then we conservatively estimated a million dollars of investment income from the $45 million base to still have a positive change in net assets, so that's the plan there. As many of you know, we've committed to show in the budget, as well as on the dashboard, on a monthly basis, two new views of ICANN's finances. So this is the -- we call it the functional view of ICANN's finances, operating expenses. So this has the 15 organizational activities, the 15 emphases points and activities that we encounter. So new gTLDs, contractual compliance, security, stability, and resiliency along those functional areas. And sort of the strong message there is there's still allowed growth for internal security, SSR activities, some growth in policy development support. I mentioned the fact-based studies and some staffing, and then obviously the DNSSEC has a growth area identified as a critical area for ICANN. There's a reduction in the new gTLD program. That's a year-over-year reduction. It's still a significant number of over $8 million for this current budget. In addition, we'll show you a couple of slides, there's a separate new gTLD budget just briefly described in the budget document itself, and then there's actually a document posted now available for community feedback on that separate new gTLD budget. So I'll cover that in a minute. Okay. The next one -- do I have a couple more minutes, Chris? Great. So the next one is the budget development process. We'd like to have community feedback on this, but it's been proposed that our current process probably could use some altering and made some suggestions. So real briefly -- I mean, this is described in more detail in the documents, but real briefly, the current process is the first six months of the fiscal year -- so in other words, from the period now until roughly December -- the three-year strategic plan gets updated. As I mentioned, this year there was a pretty significant change in the format, and the simplicity -- I call it the one-pager -- of the strat plan, and that was posted this year, so that's the first six months of the year is the update to that. The second six months is the development of the annual fiscal year operating plan and budget process, with the steps, the framework and then the draft, including lots of community feedback and consultation, formal and informal. So the alternative process that's being discussed is that we would shorten the strat plan, the update of the strat plan, strategic plan, to, say, four months or a few months of some kind, and then insert a process of large -- I call it large-dial adjustments on the budget resources. So instead of just talking about operating plan and what activities the ICANN community wants ICANN to do -- ICANN staff, community, and board to do -- it would be -- you'd start to attach dollars and resources to that, and I think that's a common experience that we all have in whatever organization we have. It's one thing to say you're going to do something; it's another thing to say how much resources are you applying to that. And so I think the thought being that we would expand that period of time and allow more -- more input, and then close similarly to what we do now and post a draft for fine-tuning those budget resources. The other big change is the thought being that we would have more SO and AC -- supporting organizations and advisory committees -- councils to provide more direct input into the budget. So instead of being treated as just a member, a community member, that can post an online comment -- although we always want to encourage that -- there would be a more direct outreach and communication with the SOs and AC chairs, and their respective groups, community groups. So I -- this will take some time and some discussion before we change this process, but I think our -- we had a meeting with the finance committee earlier and I think the board's going to talk about it more as well. I think the plan is that we will go ahead and start this in this next cycle, the FY '12 development, and reach out in September/October time frame to the SO/AC chairs and ask for their direct input, not just wait until something's posted and provide feedback. So I think that will be an improvement, from my understanding. The last thing I wanted to highlight is that there is a new gTLD separate budget amendment planned. There is a paper, a separate paper, in addition to briefly being described in -- I think it's Section 7 of the draft that's posted, there's a separate paper as part of the new gTLD comment period in which we're asking for feedback on the separate new gTLD budget. And real briefly, this separate budget describes three phases: Development, deployment, and application processing. So the development is what you already have seen in each year's annual budget, including the fiscal year '11, $8 million. Deployment and application processing would be a separate budget in which we would go to the community and board and actually separately request that. And then deployment would cover those things we would need to do to be operationally ready in time for the launch. So the thought being that we would need -- currently estimated at $2.6 million. We would need certain costs and advanced spending. Otherwise there might be delays due to operational reasons. So we need to, you know, secure the real estate facility, hire some people, and then obviously prepare the software. Things that take a long lead time, we need to make sure that we get approval for that in time, so that we don't cause more unnecessary delays in the new gTLD program, if and when the final applicant guidebook is approved. Then the other part of the separate budget would be the application processing budget, and that would be I think still the plan is something like 90 days before launch in which we would request approval for the panelists' costs and other costs in order to process applications all the way up to pre-delegation. So -- so continue that -- that amount, and then obviously that would also include the revenue, large amount of revenue that would come in from the new gTLD program, including the amount that would be used to replenish the reserve fund. So that might be a little bit too much detail but I wanted to point you to that, that we'd like to get feedback on that separate budget. The other thing I wanted to highlight, I had prepared for this meeting and I wanted to meet with a smaller group of the cc leaders and other leaders as well to go over some more details in the EAG budget. So if you look at the slides, you'll see -- I think it's $9.8 million is associated -- on the EAG report associated with the ccTLD, and so we've been asked and requested -- we had a couple of phone calls just a week or two ago, I believe, asking for more details. So we're prepared to go through that, and the idea is that we want to show, of that amount, which ones -- which items are really easily identifiable as pure benefit to the ccNSO and ccTLD community. So Bart's time, Gabby's time, the meeting room time -- meeting room space, the actual support just for you, including those who get travel support, and then there's obviously a shared resource aspect to it. So there's professional services and staff time that are shared amongst all the SOs and ACs. So there's an allocation of that. And then there's obviously just overhead. Generally finance and human resources and real estate. Those are generally allocated across all -- all the EAG categories. So the plan is, just to be clear, that we'll show that, we'll work through that, we'll make sure that you're comfortable and then the intention is that we'll go ahead and post that, so that you can see that in more detail, okay? Any questions? Comments? Thank you. >>BYRON HOLLAND: Lesley has a comment. Do we have a mic? A standing mic? >>LESLEY COWLEY: Thank you. Lesley Cowley, dot UK. Kevin, I've just got two quick cost-related questions. On the gTLD budget, you mentioned that there was quite a reduction in costs, and we could see that on the slide. Is that a real reduction in costs or is that just a shifting time line into the next financial year? >>KEVIN WILSON: So the -- there is a reduction year-over-year, but it has -- I think the answer is: Yes, it has to do with the shift in time frame. So many of the activities planned in the implementation of the GNSO policy are complete, and we've tried to communicate that we don't need to keep spending the money on things that are already complete, and so there's just a focused effort on the remaining, you know, overarching issues to do that. So that's the intention there. In addition, the reduction is coming from we want to be responsible and wait until we absolutely need it, and so that's why we've pushed some of those costs that were originally part of the -- that weren't part of the separate budget, we've pushed those in so that we have that deployment, $2.6 million. >>LESLEY COWLEY: Sure. But there's some quite significant gTLD costs coming in a yet-to-be determined future financial year? >>KEVIN WILSON: Yes, from -- yeah. That we would be separately requesting, from -- >>LESLEY COWLEY: Yeah, okay. >>KEVIN WILSON: -- that aren't part of this budget being submitted on Friday but would be part of that separate budget. >>LESLEY COWLEY: Thank you. My second question is about cost- cutting. We've heard about what appeared to be some very short-term cost-cutting measures. I'm not sure if you've lost biscuits yet, but I understand staff travel and other things have been cut. Which to me are very short-term and maybe even counterproductive cost cuts, but are there any longer-term cost reduction initiatives as yet in place? >>KEVIN WILSON: I missed one word. Are there still cost reduction efforts... >>LESLEY COWLEY: Are there any longer-term cost reduction initiatives as opposed to short-term? >>KEVIN WILSON: I think the short answer is: Yes. But let me -- can I give a longer answer. So for those of you who might not be familiar, when we adopted -- a year ago in Sydney when we adopted the budget, we -- the finance committee, Ramaraj made the commitment that we would do a midyear review. Specifically because of the financial conditions of the world markets and ICANN as well, and so we did that midyear review October/November, and that's when we identified the -- I think I said 2.7 million estimate of -- that we would overrun our operating expense line item. So at that point, we kind of had a choice: Do we go back to the community and the board and ask for an increase to our budget and, therefore, a further reduction to the reserve fund? Or do we tighten the screws and, you know, pull a couple notches on our belts, or three maybe notches on our belts, and do that? So we, basically, did kind of -- we decided not to go back. We just didn't think it was fiscally responsible to go back. The finance committee explicitly said what your point was, which is don't cut essential activities. So we looked up and down -- I think it was actually a really good exercise for ICANN to get more responsible on -- I will give you one example that was just blatant where we had four or five people going to the same Internet Governance or IETF-type meeting and they didn't know they were going separately. Just working in a silo and different department heads were sending the same people to the same meeting and kind of covering the same thing. So we made an effort to at least let's come up with a common log so that we only send one person, maybe add that person's slides to attend that. And then some things were tough. I mean, more economy class, less business class even during the year. We've had that for the ICANN meeting since Delhi, that all staff travel economy to the ICANN meetings. I guess you would call it short-term, but they're pretty institutionalized now. And there is a lot of other efforts we did. Negotiations on contracts and things like that. >>LESLEY COWLEY: I guess my point is a more major one. If one has a mismatch between income and expenditure, you can do some short-term expenditure cuts but longer term, you will need to look at priorities, et cetera, or increase income obviously. And particularly, in the context of cc's being asked to increase our funding yet again, even though it has gone up 150% in recent years, the alternative is to longer term cut expenditure is my point. Thank you. >>KEVIN WILSON: Point well-taken. >>BYRON HOLLAND: Thank you, Lesley. I believe Chris has a question. >>CHRIS DISSPAIN: I guess it is a question. We'll see. I agree with -- I absolutely agree with Lesley. And I accept, Kevin, that, for example, doing a midterm review and discovering that five people are going to the same meeting unnecessarily is an extraordinary valuable exercise and, of course, changes should be made to deal with that. But it seems to me, I'm genuinely perplexed that what -- leaving those things aside that a budget overrun that seems to be almost exclusively due to extraordinary items, quote-unquote, such as the legal fees for dot XXX and so on. The reaction to that is to go into the business and cut rather than to say, "These are extraordinary items and we should deal with them as extraordinary items and pay them from our contingency." It is generally perplexing to me that you would do that. Extraordinary items are extraordinary items. They happen in every business. There is no question that there's money. There's no question that ICANN is stable. So why would you fiddle around with how many paper clips people are allowed to use -- I'm speaking figuratively, of course, unless you actually have done that, in which case -- instead of actually just acknowledging that you had a budget overrun for whatever reason and getting on with it? >>KEVIN WILSON: Yes. I guess I will get a little defensive actually on that, Chris. We actually did all three. So we went to the board and said we would like to release the -- you know, because of the ICM matter, we spent some funds there because of the nature of the double CEOs that we had for six months. That wasn't budgeted a year ago when we were in Sydney. And, you know, things that happen more recently like the extra Nairobi security costs that we had. So those are all extraordinary items, I understand. We did then go back to the board and say, We would like to have approval to release the $1.5 million in contingency. We worked with the finance committee and toyed with the idea of actually requesting an additional budget increase, formalize that process in the midyear. We decided that it was appropriate for ICANN given the environment to actually look at every line item, short-term, long-term, salaries, negotiated rates with attorneys and professional services. I looked at all of that, phone costs. There were literally -- I think we had a punch list of 85 items from a couple of executive brainstorming sessions, and we followed up on each of those. So we really did do that. I feel like -- the reason I'm pushing back is I feel like we did communicate that in October/November. >>CHRIS DISSPAIN: (Speaker off microphone). >>KEVIN WILSON: Okay, good. Thanks. >>BYRON HOLLAND: Thanks, Kevin. I just have a comment and question myself. I just want to let you know that the ccNSO Council will be providing some comments. You'll have them very shortly. But in addition, there had been some questions asked previously, as far back as Nairobi, in the earlier part of the operating planning process. And I'm just wondering when we might expect some of the answers to those questions. >>KEVIN WILSON: We talked about how to communicate that. It didn't -- we didn't have enough time to actually put it in this document all of them explicitly directly. Many of the comments or questions were addressed in this indirectly. So I have drafted a blog -- I will be blunt about that. I have drafted a blog, and we are expecting to post that. We didn't feel it was appropriate given the amount of material that the community is digesting. So after -- you know, sometime in the next week or so, we'll post the blog and you'll see the answers to your questions. >>BYRON HOLLAND: Are there any other questions? Because I'm sure Chris has one. >>CHRIS DISSPAIN: Kevin, in the genuine spirit of openness and transparency and understanding that this is your job and it is a tough job -- I'm not blaming you, and there is nothing personal in this. What I expect is a simple answer to my question. That report does not give me a simple answer to my question. What I expect is for you to tell me that one of the reasons why you are over budget is because you built a TV studio. I actually expect you to tell me that. So I understand you are doing what you have to do; but when I've asked a series of direct questions as chair of the ccNSO, I actually expect an answer. And giving me an answer after the close of the comment period, when the budget has already been approved by the board, and all of the discussion is over is not really all that helpful because what do I do? It's done now, right? So I can't stand up in the public comment period on Thursday on behalf of this community and say, "We are annoyed and upset about something" -- we may not be, but if we were, which is what we are actually supposed to do in the sense of being a bottom-up organization, is we're supposed to tell people when we are delighted with something they've done and we are supposed to tell them when we're not. We don't have the information. I want to just say again this is not about you, and I acknowledge it is not your fault. I'm just trying to make the point, read into the record. And we have got Rod and Peter on their way shortly so maybe we can say it again. >>KEVIN WILSON: I mean, Rod and Peter can answer those more directly, I think. But as far as I know, I hope I'm not speaking out of turn, but there was a studio discussed and contemplated but we haven't spent money on a studio. That's a specific question that you're addressing. And you asked -- you are talking about the letter that you sent after Nairobi where you actually asked specific questions, and we will answer each of those questions. >>BYRON HOLLAND: Thanks, Kevin. Are there any more questions from the floor? Dotty, is your hand up? >>CHRIS DISSPAIN: Dotty, you will have to use the microphone. Can you pass the microphone to Dotty? Thank you. >>DOTTY SPARKS de BLANC: I have a question. At the risk of embarrassing myself and having you tell me it's on page so and son, can you identify the total amount of legal fees in last year's budget? >>KEVIN WILSON: It's about 2 1/2 to $3 million we spend with the lawyers. Now, when you say "legal fees," that includes lots of work on new gTLDs. >>DOTTY SPARKS de BLANC: I know it's a total. >>KEVIN WILSON: If you say how much do we spend on lawyers, that's on the 990 and it is in the budget. Actually, there is a line item that shows how much we spend for attorneys. And then that's broken out further between estimated litigation or, you know, actions -- defensive actions as well as costs spent on preparing for, say, the new gTLD or robustness. >>DOTTY SPARKS de BLANC: Well, I didn't -- I don't know the answer because I didn't see that page. But what percentage is defensive litigation of total legal fees? >>KEVIN WILSON: I don't want to speak out of turn. >>DOTTY SPARKS de BLANC: Oh, I'm sure it changes all the time. >>KEVIN WILSON: Yeah, but the budget assumption is, you know, roughly half to 2/3 of that. >>DOTTY SPARKS de BLANC: Okay. Thank you. >>BYRON HOLLAND: Thanks, Dotty. I have -- are there any other questions from the floor at the moment? I'll let you think for a second. I have a question in that clearly the budget is affected primarily by three things: Revenue, expenses. The other element is the reserve fund, and we've had some discussion -- you know, there is a very significant reserve fund. From my perspective, there seems to be a lack of clarity on what is the policy around that and when enough is enough because that is the buffer that affects a number of other elements. Can you give us some clarity? I know there has been discussion on benchmarking work, et cetera, that there would be a clear policy around that specific subject? Can you give us a sense of where you're at with that? >>KEVIN WILSON: Sure. Thanks, Byron. So we've asked the question to the community, "What are your thoughts on what's the right amount?" And that's one of the pointed questions. My memory is we didn't get a lot of response on specifics, although we got support as, I think, CIRA provided to -- to study that, analyze that. We've had lots of discussions on what's the model to use rather than just pick a number out of the air or pick a percentage or what is currently described as one year of operating expenses. So the intention is to make progress on that, pick a number for the reserve fund, have a reason for that amount, the sizing of that is explicit and known. That's the intention. So what's the action? We talked about that with the finance committee this week. They have a requirement in our investment policy to review each year the investment policy itself to see if it's appropriate. And one of the questions that we're asking the outside consultants -- we'll get a third-party consultant this summer and report back in September. One question is sizing, and we'll talk about benchmarking and how to do the appropriate size of it as well as is it the right risk class? Are we investing properly? That sort of thing to do a normal fiscal review. Did I answer your question well enough? >>BYRON HOLLAND: It is a complex subject. There are certainly a number of models you can choose. One challenge is if you say one year, in ICANN's case in a constantly increasing budget, you never actually get there. It is continuously on the horizon. So at some point, you have to say what is reasonable? What are we trying to achieve? What's actually the end goal other than just a year of operating expenses? It's good news that there will actually be further work on it. Just to be clear, so September you are going to be reporting on that with a conclusion or suggestion or what? What are we going to get in September? >>KEVIN WILSON: Just to be clear, so the intention is to come up with a more elegant way to describe the size. For example, identify what kind of risks -- rather than calling it a rainy day fund, say what kind of risks would we actually pull from that? What black swan events could you do? It is impossible to come up with all of them but at least start to put a groundwork around that. >>CHRIS DISSPAIN: But not before you have cut all -- but not before you have cut all the costs to zero. Don't use your reserve fund until you have actually cut everything. [Laughter] >>KEVIN WILSON: So that's -- just to be clear, that's my deliverable to the finance committee. And one of my recommendations in the finance committee is how do we communicate that. Is that part of the -- a separate communication or part of just a -- posted as minutes of the meeting? It is probably not appropriate for me to determine how it gets communicated to the community. But I don't think there is any intention to do anything but be open and transparent on that. >>BYRON HOLLAND: Thanks. I know it is the first session in the morning. But I think that where ICANN allocates the money is a very important topic. Are there any further questions while we have the person at the center of that conversation? No other questions? Has everybody had coffee yet? >>KEVIN WILSON: Thank you very much. Appreciate the dialogue. And we have a session on Thursday morning. I especially invite those of you interested in it. It is especially helpful because the different SO and AC leaders and community members are all in one room and so you get a chance to hear some of the different questions. The registrars this morning asked very different questions than you all did. I think it is helpful for you all to hear what the other groups are asking. Thank you. >>BYRON HOLLAND: I want to say thanks to Kevin. Clearly coming in here and being on the pointy end of the questions can be a tough job. And I just want to say working with the SOP committee, Kevin has been very helpful in providing better and better information over the past year and half that we have been doing this. So thank you for being here first thing. >>KEVIN WILSON: Thank you. [Applause] >>CHRIS DISSPAIN: Couple of things. The next bit we're going to do is the Peter and Rod show. We put a call for questions, things that people wanted to talk to them about, and I had a couple of people respond but many -- but not a lot. Can I just make the point to you that this session -- we received -- the council received a letter from Peter the other day questioning whether these sessions -- this session and the council's breakfast with the board on Wednesday morning is worthwhile and is it something we want to continue. And the council went back very clearly and said "yes, absolutely." So we really -- we've asked for this session, so please come to the microphone when they get here and talk about anything at all that you want to talk about -- well, perhaps not what you had for breakfast but, you know... Please do that. I just wanted to finish off real briefly having gone through the history stuff with the finances, there's clearly a gap. There's clearly an issue. We can't just bury our heads in the sand forever. We have to try and deal with this. I have no clue what the answer is, but we have to try and deal with it. So what I would like to suggest is that if I get the feeling from the room that it's okay, that tomorrow the council actually formally sets up a ccTLD contributions working group, of course, volunteers, and start to do some work on this and where we get to. And we can have a session in Colombia in December perhaps where that working group can come and say "you know what we have looked at it and there are five possible things we can think of -- models that we can think of that might work" or something. Does anyone object to us doing that given that it's only a working group and we would be looking at -- nothing would be off the table, nothing would be on the table except the clear understanding that it is all voluntary anyways? Does anyone have a problem with that? Okay. Well, in that case, I will take that, that we can tomorrow on the council pass a necessary resolution. And I would encourage you to, no matter what your stance is, if you are a "under no circumstances whatsoever will I ever pay ICANN any money" person, or you are a person who pays what you would consider to be a substantial amount of money, please if you have the time put yourself on to the -- volunteer for the working group. The size will need to be manageable, so depending how many volunteers we get, we may not be able to say yes to everybody. But, please, I would encourage you to put your names forward. >>BYRON HOLLAND: Okay. Thank you very much. I think we're at about that point to wind this session down. I will do just a bit of a marketing pitch. The SOP is running a session tomorrow afternoon on the strategic priorities for ICANN from the ccNSO perspective. So this is where we start to focus on what we as a community believe are the core strategic priorities. This is where we get to have a say as a community, so I encourage you please come out for that. We need the input. And if you are happy with what ICANN's doing or if you're not happy, this is the place to help start channeling that discussion in that direction. The other element that I will say just to give people some time to think about it is the SOP committee in terms of its mandate, terms are up for folks at this meeting. So we will be making a call for members for the next term, so I would also encourage people to think about that. And with that, thank you very much. >>CHRIS DISSPAIN: Thank you, Byron. And thank you to the SOP for all the work that they do and thank you to all of them who prepare to carry on doing it. That's fantastic. Okay. Our next session with meeting with the two -- our two board members, Michael and Peter and Rod Beckstrom, ICANN CEO. You will have noticed that currently the only member of that triumvirate with us is Michael -- (audio cut out) -- I will just hand the microphone over to (no audio) -- >>MIKE SILBER: Thanks, Peter. Chris, sorry. Until the more formal engagement with the chair and the CEO because I suppose the ccNSO has the disadvantage of having the ICANN chair coming from its numbers which is sometimes an advantage and sometimes a disadvantage, but I think until such time as they're here and we can engage the more formal session, it might be worthwhile just to -- seeing as it's always good to be back within my community both formally and informally and particularly socially just to try and engage because obviously there has been a fair amount of tension and issue of late, something that people -- I know we're in a reasonably open session over here given that we're in the main hall but something that people may want to discuss and engage with. And if we want to do it in a slightly more closed environment, we can look at doing that as well. What I wanted to mention, seeing as this is now my third meeting having been appointed to the board by the ccNSO, just a little bit of feedback on the past year. I suppose the first thing that I wanted to mention is the board spends most of its time dealing with either generic issues or gTLD issues. I know that I use the same term for both or a term which in this industry is used for both. But when I talk about "generic issues" I'm talking about issues relating to security, stability, finances, risk, security, those sorts of issues which are generic across the sectors except that within our community we're generally not driven by a profit motive. I know some of us are, and there is no judgment in that statement. But we tend to look after our community's interests first, namely, the local community in your country rather than the community as in all the cc's of the world. That being said, I think that the ccNSO does a very good job of it. And I think that part of the reason why the board spends so much time on gTLD and generic issues is because the ccs tend to look after their own house particularly well. There is far less effort required in terms of board governance and involvement as compared to gTLDs, and lot of that has to do with the launch of the new gTLD program but equally because the gTLD space is relatively open commercial space. And you have to accept the consequences of that. There's been a couple of issues in the last year, and I think it's worthwhile dealing with them and engaging with them just simply because I don't believe that there's any benefit to corridor talk because we're all talking about some of those issues. So maybe let's jump into one of the first of those, which is the statements around security and stability made in Nairobi which caused a fair degree of upset in the cc community given where they're coming from, given also where they were made and the particular language that was used in terms of those statements. I think what I can say is as we saw from the panel yesterday, security and stability concerns definitely do exist. Nobody is naive enough to believe that they don't exist. Whether they exist in the manner in which they were portrayed I think is largely irrelevant. Let's move beyond that. Different people sell concepts and ideas in different ways. What appeals to you may not appeal to me and vice versa. I think the reality is that security and stability is a concern. (Garbled audio). The ICANN board should really be a policy approval process once the community is happy that the policy has been finalized and is in a form which is acceptable to that community. Sometimes the ICANN board will take a role as prioritizing policies and pushing back down to the SOs and the ACs to say we don't actually care what you think of the importance of X versus Y. Because of other issues, concerns which hang on the outcome of this process, we're telling you this is more important, not in the overall scheme of things but just in terms of please lift it up your priority list and get this done urgently. Now, we tried to do that in Nairobi with the question of vertical integration of registries and registrars. And what we did is we set a baseline of 0% and we pushed it down to the GNSO and said, "this is your policy, you go and make it, don't force us to make it and then complain about what we do." And we thought by setting a 0% threshold -- and this is my personal view here, I'm not expressing a board view -- that by setting a 0% threshold, we would certainly indicate the urgency of the issue and provide substantial encouragement to the community to come up with a set of policies that could work. Knowing the gTLD space, as you may or may not do, we then spent the first three months answering questions from the working group about what we meant by our resolution. People obviously were trying to work out advantageous or disadvantageous the position as stated in our resolution could be or could not be for their particular company or other commercial interests. And the board made a decision not to answer that, not because we're not open and transparent but because it would be counterproductive. They need to make policy. We should not be making policy. Now, that's a refrain that I want the ccNSOs to pick up because with regard country codes as well as regard to generic issues like stability and security, the policy-making body is the ccNSO. Sometimes on its own and sometimes in conjunction with other bodies. And instead of the rather more fractious ASO I have been talking about, it would be a huge advantage if the ccNSO would put its hand up and say "fine, we accept the policy responsibility," and they certainly have been. And I have been particularly impressed in terms of the work that has been done around the delegation/redelegation and retirement. And I think the time is right for the ccNSO to set an example to the rest of the organization to say, "this is how policy is made at our level and we push it up for the board to have a look at, review, make sure that it's cohesive across the organization" and then approve it but that you don't need the board to get involved in any internal disputes and resolve any debates that you may have happening. You can do it yourselves. You are more mature than certainly many in this organization. You are less fractious. And I really hope that the ccNSO can be an example of policy making. Now, I understand that making policy takes time, but you should also understand that people expect policies to be made over such a slow period or such a long period that they then try and push the board to get involved to come up with interim measures, because of the length of time involved in making policy, and I would encourage you to set an example to this organization of how policy can be made quickly and efficiently, and where it does take time, that you can put reasonable interim measures in place so that the board doesn't have to do that for you. >>CHRIS DISSPAIN: Michael, can I -- sorry. If anybody wants to say something, obviously just walk to a microphone. Can I pick up on what you've just said? And I agree with you. I think that there are a couple of caveats or issues. The first is that as you know, the ccNSO is very careful to make sure that it doesn't set policy on things that are not, you know, global issues, because we're all very precious about the fact that we're sovereign ccTLDs and we make our own policy. But I think as we're maturing, we're learning that there are issues out there that are not necessarily specifically ccTLD issues, but they're issues that we are involved in and concerned with and that, therefore, we should be involved in that policy. What I think we've got very good at is one of the things that the items report, the review of the ccNSO says, is that the policy development process is very complicated and heavy and difficult. It is, and it's actually intended to be that way -- well, perhaps that's the wrong word "intended." It was written that way because it was the only way that we could get consensus amongst the cc's, as you'll remember, because you were there, to allow the organization to have any policymaking right at all. What I think we've been very clever at is actually doing stuff outside of that that still carries weight and still carries import, and, you know, the fast track is an example of that. And I think we've been very good also at bringing the other SOs and ACs together to discuss things. On the issue of security and stability and the suggestion of a possible DNS CERT, I can tell you that subject only to the GNSO formally approving this tomorrow, the ccNSO, the GNSO, the ALAC, the SSAC, and -- I think that's it, at the moment -- have all agreed to set up a small group of people to draft a charter for a joint working group across all of the relevant SOs and ACs, including inviting the GAC to look at the security and stability question and ask the questions about DNS CERT. If you go to -- if the board goes to the letter that went from Chuck Gomes to Cheryl Langdon-Orr and me as comment, there are a series of bullet points in that letter about what we think the process should be for answering -- for looking at the security and stability questions, and that is roughly what the charter is likely to look like. In other words, that is what the working group will probably be tasked to do. So I think that's a really -- I think that fits quite well with what you've been -- with what you've been suggesting. Rod has arrived, which is great. Rod, do join us, please. Does anyone -- Donna, do we know where Peter is? Okay. No problem. Good morning. How are you? >>ROD BECKSTROM: Good. Thank you. >>CHRIS DISSPAIN: No, no, no. That's just the thingy. Don't worry about it. So Michael, do you want to just pick up on that and then we can go to Rod? >>MIKE SILBER: Sure. I think just to allow Rod time to settle and get where he's at, that to me is the way that policy needs to be developed within this organization. You know, one of the reasons we employed Rod was his history of engagement in leadership, but what we didn't do is employ somebody to make policy bottom-up. We employed somebody to lead from the front, but at the end of the day the engine room still sits within the SOs and the ACs. And so Rod raised an issue. If you like the way how he raised it or not is a different concern. It has been addressed, I believe. But the truth of the matter is that it's something that needs to be looked at, and I think that bottom-up organizations forming themselves to do the work is an absolutely fantastic initiative. It shows you're serious about it, instead of waiting to be led. It's something that came out of the board discussions with the affirmation review team regarding accountability and transparency, and one of the issues that was raised was why does the board not give reasons for some of its decisions. And it's certainly a comment that I took to heart, because I thought we did give reasons. Certainly those of us when we vote against a resolution or abstain put our reasons on record, but I was under the general impression that those torturously crafted whereas clauses before every resolution gave the reasons for the resolution, and there seems to be an impression in the community that it doesn't do a good enough job so it's something we need to take on board. But the example that was given to us was of regulators and other administrative law functionaries in various countries, and the comment that I made to the affirmation review team -- and it's the same comment that I make to you -- is that ICANN is not a regulator. If you want us to be, then we need to change the nature of this organization. ICANN is here to be a facilitator of decisions that the community makes, and then tasked with implementing some of them or partnering with other relevant organizations to help implement those. What ICANN is not here to do is to sit and make decisions on who is right and who is wrong, and write regulation. So we can do better around exposing our reasons and some of our thinking, and it's something we need to take on board and think about a little more. But what you need to do is put up your hand, whether it's to the affirmation review team or anybody else, and say, "Hey, don't start telling the board how to do certain things in a manner which will actually abrogate policy responsibility from the SOs, where it actually rests." >>CHRIS DISSPAIN: Thanks, Michael. Rod, welcome. >>ROD BECKSTROM: Thank you. >>CHRIS DISSPAIN: You have the microphone. >>ROD BECKSTROM: Well, thank you. I'm really here to more listen than to say anything. I'd understood that DNS CERT was one topic that some people here would like to speak about, and I'd like to hear your views or answer any questions you have on that topic. And also just, you know, briefly note again we would appreciate any help with data gathering in terms of what's going on in security and stability. We sent a short letter to the ccNSO a couple of months ago and any help on that side would be much appreciated. So all I want to say is thank you to the good work that you're doing to move the ball down the field in multiple areas on the policy side. And really, Chris, I'd like to maybe just turn this around and take questions from the audience. >>CHRIS DISSPAIN: Sure. Not a problem. Can I ask that anybody -- if anybody has a comment or question that they'd like to make, to consider at some point wandering over to a microphone. Rod, just for your benefit because you weren't here, on the DNS CERT thing, security and stability, subject -- I'll be brief. Subject to -- no. Actually, back a step. You'll recall that part of the comments that went in, there was a letter from the chair of the GNSO, ccNSO, and ALAC, and subject to the GNSO actually passing a resolution tomorrow, we will, on Thursday, be able to announce that the GNSO, ccNSO, ALAC, and security and stability advisory committee are setting up a charter drafting group to spend a little time drafting a charter for a cross-ICANN working group to actually look at the security and stability issues, and that is effectively what our feedback comment was, plus other people made the same comment. So we're going to just go ahead and do that, and we'll have that -- hopefully that -- if the charter manages to get a consensus -- and this is not necessarily going to work, but assuming it does -- then we would -- the next step would be to actually set that working group up. And we anticipate that happening, if it's going to happen, relatively quickly. So if you -- that's where we are with that. >>ROD BECKSTROM: Okay. >>CHRIS DISSPAIN: Does anybody have anything -- Rod versus rushed here from talking to some important government people can now leave or... Lesley. >>LESLEY COWLEY: Good morning, Rod. >>ROD BECKSTROM: Good morning. >>LESLEY COWLEY: We've had a money start to our day this morning, so -- >>ROD BECKSTROM: I'm sorry. A what start? >>LESLEY COWLEY: A money. Talking about money. >>ROD BECKSTROM: Oh, okay. >>LESLEY COWLEY: So that's quite high on our agenda, just at the moment. I'd like to explore an issue with you which, as a CEO as well, I know how difficult this is, but we've had some short-term cost reduction measures outlined to us by Kevin, and we're also interested in whether there are some longer-term cost reduction initiatives in ICANN. Because obviously there are some budget crunch points coming up for ICANN, and we're also keenly aware that cc's are being asked to contribute more. >>ROD BECKSTROM: I'm so happy to hear that. >>LESLEY COWLEY: What? That we're aware or that we're -- >>ROD BECKSTROM: No. That the ccNSO wants to contribute more. >>LESLEY COWLEY: No, no, no. I didn't say that. >>ROD BECKSTROM: Oh, you didn't. I'm sorry. I guess that was a Freudian slip. >>LESLEY COWLEY: No. I said we are aware that there are initiatives to suggest cc's contribute more. >>ROD BECKSTROM: So a couple things. First, in terms of the ICANN budgeting process, I mean, you know, it's going through the normal annual cycle right now and moving towards approval at this meeting, and there's no change in long-term budget processes because the specification that basically we go through the strategic plan and the operating plan, into the budget every year. So that cycle is unchanged. Clearly, I mean, if you look at the -- just the growth in the different programs and activities that are underway at ICANN, I'd say the growth in those programs that we seek to do outstrips the growth in the revenues, which comes mostly from the other side of the house. And so I think overall there's an awareness of the difficulty in making tradeoffs, and an awareness of trying to look for cost controls or places that we can save, and I think that Doug's view and my view have been very much similar since I've been here, which is that we've done tightening in a number of areas and we don't see much more slack or a lot of fat. So tough -- tough tradeoff comes, and one example being the area of even ccTLD -- you know, some of the training things that we have out there in the field where there's cut-backs that, you know, is not what we want to do, but if you look at all the other programs underway, whether it's DNSSEC, et cetera -- So anyway, I think the -- on the process side, the process is going to continue as it's been created. There's some discussions of changing that process a little bit within the one-year cycle and having more time for some of the budgeting discussions in particular at the tail end of the cycle, but it will still be an annual cycle and I don't see that changing. >>LESLEY COWLEY: Okay. So I think you said there aren't any longer- term cost reduction initiatives. >>ROD BECKSTROM: No, I didn't say there's no longer-term cost reduction initiatives. I said there's -- that the budget planning cycle overall is not moving off a one-year to like a three- or five- year planning. It's an interesting question for us to consider in the future, but -- yeah. >>LESLEY COWLEY: So in my simple mind, you either increase revenue or you reduce costs or you re-prioritize or maybe drop some priorities. >>ROD BECKSTROM: Exactly, yeah. >>LESLEY COWLEY: Yeah. >>ROD BECKSTROM: Which is something, you know, that we're doing. I mean, some programs we're not investing as much in as we might like, and overall, I mean, look, it's a fixed resource base. I mean however many dollars is approved by the community can get spent, and not more, substantially, unless approved by the board, as we had a couple of things approved by the board this year for deviation. So, look, it's a -- I think ICANN is very tightly run overall financially, is my sense. A huge amount of services and activities for a roughly $60 million a year budget. And it's a -- it's quite a challenge. >>LESLEY COWLEY: Absolutely. I recognize that, too. I guess the point is about at what stage do we cut our cloth to -- to suit, because we may actually have to acknowledge there are not the resources to deliver in full some of the longer-term strategies that are in the strategic plan. >>ROD BECKSTROM: Sure. Well, I think that that's the operating plan part of the process. Right. The strategic plan is kind of like what the community's wish list is or what we all agree upon the community does and it's approved and reviewed by the board. Not all of that gets in. Not all of that gets into the plan. I mean, for example in the strategic plan -- I don't have the one-pager in front of right now, but, you know, advocating the IPv6 adoption, you know, we don't do a lot in that area, okay? Because we haven't chosen to create a major program or initiative. So we advocate a bit, but we don't have a program, we don't have dedicated staff. One could go spend a lot of money on something like that. So that would be an example of a line item in the strategic plan that's approved, but it's not approved in the budgeting side. So there's -- so those sort of tradeoffs will occur. I guess I'm trying to understand the -- I guess because -- I mean, if you look at the overall pie chart, I mean, I'm not sure what -- what amount of revenue is coming from the ccTLD space, but I think it was around -- was it a million and a half dollars last year? 1.8? Good. You know, it's moving up. There's some effort I think to estimate what the costs are associated with supporting each of the houses and without making remarks on it, I mean, obviously from a strategic planning process, any organization would want to balance those things over time. >>LESLEY COWLEY: Sorry. I won't carry on much longer but my point was, I thought the strategic plan was the plan as opposed to a wish list, and then the operating plan was the implementation of that strategy. >>ROD BECKSTROM: No. The strategic plan is a wish list. >>LESLEY COWLEY: Okay. >>ROD BECKSTROM: I mean, it's a strategic wish list. It's not funded. I mean, if you look at the process with the community, we vote on something before we decide whether to put money to those items. So the strategic plan are those things we wish to work on and focus on, so if things are not on there, they're not a candidate, but not everything on the strategic plan is fully funded. I mean, you could take IPv6 advocacy alone and say it could be a 1-, a 5-, a $10 million a year program, you know, in a lot of contexts. So not every -- the strategic plan gets whittled down to the set of priorities that can fit into the budget that the community's going to approve. >>CHRIS DISSPAIN: I understand -- >>LESLEY COWLEY: That's helpful clarification. Thank you. >>CHRIS DISSPAIN: Yeah. I understand that, Rod but I just need to get clear of something. If there was money, everything on the strategic plan would get done. Is that -- is that right? >>ROD BECKSTROM: Yeah, if there were enough money to fund every initiative -- again, we can take any line item and you could choose how big that line item becomes. I mean -- >>CHRIS DISSPAIN: Sure. Of course. >>ROD BECKSTROM: -- advocating IPv6 could be a one person initiative, could be a 500 person initiative, right? >>CHRIS DISSPAIN: Of course. >>ROD BECKSTROM: So anyway, I think it's an interesting -- a good process we go through. >>CHRIS DISSPAIN: Yeah. >>ROD BECKSTROM: Get a line on strategies and then go make the tough tradeoffs, like every business has to, of how many dollars and cents are there, and Euros, to -- >>CHRIS DISSPAIN: Sure. >>ROD BECKSTROM: -- to turn the screws down to see on what can fit. And right now we're at full capacity. I mean, historically ICANN was criticized for underspending, you know, for underspending and having too much reserves. Well, if you look at the significant expansion in programs and complex activities that we're undertaking, we're definitely full up on spending the funds right now with a lot of pressure to do more. An example would be the affirmation review teams. A certain amount was budgeted for those programs, but the wishes of the teams might be different, might be considerably more, and puts additional pressure on other existing projects. >>CHRIS DISSPAIN: Okay. Let me -- Hilde, if you give me a minute, let me just -- just so that you know -- tell you where we are in respect to the money discussion. We've had a -- Kevin has provided very useful detailed information, and we've really appreciated the work that he's done. He's working on some additional information which he's going to provide. At the last ccNSO meeting in Nairobi, the council passed a resolution that said -- I'm paraphrasing, but said, "We really appreciate the work that's been done to tell us what's being spent in respect to the cc's. We recognize that there is a gap between what we -- what the cc's voluntarily contribute and what ICANN may be saying is a right amount of money. We endorse the current way we do this, which is to provide a set of guidelines, but we recognize that we need to move on from there." So this morning, I have -- the room basically has consensus that the council tomorrow will actually set up a working -- formal working group to consider the finance. But let me give you a really simple explanation of why it is so challenging. The starting point for all of this is it's voluntary. In the cc world, it is voluntary. So that raises all sorts of fascinating questions, like: So who's in charge of collecting? Because you could simply say 250 ccTLDs, $10,000 each, $2.5 million. And that's -- if that was the number. And it's not up to us to collect it. You've got to collect it, right? ICANN can send out invoices and -- and I personally would be very happy on that basis because I could pay significantly fewer dollars than I currently am. So that's how challenge -- so that is -- do you do that or do you say it's $5 million and you, the cc's, figure out how to pay it. Well, you know, no. We're happy to talk, but -- and it's certainly not our job to collect it. So when -- it's a very complicated issue, but I think we've made what may seem like a little step is actually a very big step, which is that we've -- you know, we've acknowledged as a community that we need to try and do something. >>ROD BECKSTROM: I just want to say: Absolutely. You know, Chris, thank you very much. And that's where it has to start, you know, is with the -- discussing the topic, acknowledging that there is an issue there and figuring out, you know, creative ways to bridge. So thank you to all of you for looking at that important issue. >>CHRIS DISSPAIN: Peter, and then Hilde, I promise we'll get to you. >>PETER DENGATE THRUSH: I guess I'm -- I guess I must be much simpler than you guys, because it seems to me relatively straightforward, and I go back to what I think of as the Poblete resolution from Bucharest in 2003. Patricio chaired a working group. We all went away and said, "Yes, we recognize that we have to pay our share of direct costs and we're also prepared to pay, as ccTLD managers, to pay a share of the running -- of the general overhead of ICANN because we appreciate that we get a lot of benefit from belonging to an organization that is keeping the Internet safe and stable, and yes, we know there's a whole lot of money that gets raised by the Gs and gets spent on the Gs, but we should pay for a share of, you know, having to have a GAC and having to have" -- You know, that was the sense of the resolution. The difficulty since then has been a genuine one from the cc's, saying, "Well, we don't know what that cost is," and now I understand that the finance team has given us the cc's a list of expenditure of about 9.6 million on what it says -- what the staff say the cc's cost. This is a very routine exercise in a corporate structure. Divisional managers get together with the boss and say I'm not going to pay for that, I'm not going to pay for that or I'll -- you know, this is a relatively straightforward bargaining exercise, if you like. You've got the facts. I can't -- why can't we just get a group of you together in a room with the information, work out what those costs are, challenge them, and then accept the decision of that and that should give us a number that we've been asking for since 2003 on what is it that the cc's are currently costing ICANN. And then set about paying for it. I don't know why we -- why is -- >>CHRIS DISSPAIN: But that's the point. Let's assume we could get to that point where we agree a number. Let's assume that we could agree it was $5 million, just say. Then what do you suggest we do? How do you suggest we pay that money? >>PETER DENGATE THRUSH: Well, what I'm critical of, I suppose, is that you haven't been solving that decision, knowing that the number is coming. You've done nothing and say we don't know the number, we don't know the number, we don't know the number since 2003, when what you could have been doing is saying we know there's a number coming, we better get a collection and distribution mechanism ready. So what it looks like from the ICANN staff side is that the reason -- the argument that there's no number has frozen all of the rest of the process. And that seems to me to be sort of unfair, I suppose, or -- or at the very least naive. >>CHRIS DISSPAIN: Well -- >>PETER DENGATE THRUSH: You know the number is coming. So my recommendation would be get on with the mechanism, even if you don't know what the actual number is because it's coming. >>CHRIS DISSPAIN: How can we create a mechanism unless we know what we're talking about. If the number was a million dollars, basically six of us or seven of us could get together and say, "This is all too hard. Between us, we'll give you a million dollars and we'll work out -- you know, we'll support the community." Right? If the number's $10 million, then it's a completely different quantum that means that we need to come up with a completely different methodology. >>PETER DENGATE THRUSH: Well, I think that's a -- I think you can always raise difficulties. That's a kind of simple scenario planning solution that you can deal with. You've got a range of options. You know it's not going to be a million. You know it's not going to be more than 10 million. Get together as a group and say, "What will we do if it's two, what will we do if it's five, and what will we do if it's seven?" But don't do nothing and keep using the excuse that you haven't got the amount for doing nothing, because that doesn't look good. >>CHRIS DISSPAIN: Okay. We're going to -- this is going to carry on, I know, because I can -- Hilde? >>HILDE THUNEM: Hello. Hilde Thunem from the Norwegian registry, dot NO. I was actually going to be positive. >>CHRIS DISSPAIN: Oh, no. Don't do that. >>HILDE THUNEM: Unless you were starting to talk about strategy as a wish list and how we should make processes for a number that we have been asking for in six years time without getting. I personally, at least, did not know that we would ever get a number until they suddenly appeared, because I've been dealing with an organization that didn't know how much money it spent on the ccTLDs. Now, on to the positive thing. I'm going to talk about geographic names. Big surprise. And not surprisingly, I hope, we were very, very, very pleased to see that in DAG 4, country and territory names were taken out of the gTLD process. The Norwegian government were also very, very pleased to see that significant effort had been made in dealing with the post-delegation issues of geographical names, how to deal with it if first approval is given and then the operator goes away and turns it into a commercial gTLD instead of a geographic TLD. So thank you for that. I'm very, very pleased about it. >>PETER DENGATE THRUSH: You're welcome. >>HILDE THUNEM: I see that it's taken out for the first round, or for this round, but from the footnote, I see that it's noted that it's going to be left to the ccTLDs to make policy, as Mike was saying that we ought to do, so I would assume that even should ICANN manage to launch a second round before the ccPDP is finished, we would still have the country and territory names within our policy remit until we actually finished the process, or... >>PETER DENGATE THRUSH: The answer is: I don't know. There's been quite a lot of work gone into establishing the position that you just are grateful for. I don't know that it -- it's going to last, so while it might be logical, don't count on that as being the reason. >>MIKE SILBER: Hilde, if I can suggest as I was saying earlier, I think that certainly for the first round, it applies. The idea is, having launched a first round, is that the sausage machine is now running, and I know that two things that you should never look at if you want to keep respect for them is the making of laws or sausages. That being said, once the machine is running, you want to just keep feeding it, so it shouldn't stop. >>HILDE THUNEM: No, but -- >>MIKE SILBER: And so at some stage, there's going to come a point in time where if the ccNSO has not made a decision, there's going to be a decision from the board which says, "We've tried to push you to make a decision. We've given you the space to make that decision. You're not getting anywhere. Now if we really need to incentivize it, then we'll give you a fixed date before we turn that live." I'm just explaining how the board's thinking. I'm not saying that's something that's currently on our agenda, but at some stage policymaking and navel gazing has to end and decisions need to be forwarded up to the board. And as the ccNSO appointee to the board, I can try and keep that data as long as possible, but at some stage when I'm hearing my colleagues pushing other organizations to make a decision or move on, I'm going to have to say the same to the ccNSO and I can't tell you exactly what that date is going to be. >>CHRIS DISSPAIN: Hilde, can I just pick up on that for a second? Michael, I think you're right and I think, Hilde, that we -- as we discussed yesterday, I think we're pretty clear that if we're -- if we're serious about what we -- about the country name situation, we actually need to do something about that and simply writing a letter saying we don't like it isn't going to cut it. It will get us some time but it's not going to complete the issue. So I think we're clear on that, aren't we, Hilde, that we need to take some action. >>HILDE THUNEM: Yeah. I mean, this is not to suggest that we would, you know, wait and just hope the issue goes away. We're already in the process of dealing with it. But I wasn't aware that the SO advice or GAC advice came with a "sell before this date." Sausages might, but I think, you know, that when GAC has given advice that leave the country names alone until the policy for them is finished and the ccNSO has given that advice, that we actually should, you know, be given the time to finish the process we already have running. >>CHRIS DISSPAIN: Hilde, thank you. I'm conscious that we have questions online and Matthieu behind you and we don't have much time left, so thanks, Hilde. >>MATTHIEU CREDON: Thanks, Chris. Matthieu Credon, manager of dot fr. Thank you for all the clarifications. Chris, you called for a follow-up on the cost, though it wasn't my intention. I would just like to probably say -- and just reply to Peter's comment that I think a lot of energy within the ccNSO is dedicated to getting to that figure, especially through the SOP group chaired by Byron and with tremendous support by Kevin Wilson, who's spending a lot of time -- we have all spent a lot of time with him here between meetings, on the phone as well to make sure we understand what's behind this figure. And that's really an ongoing work, and I don't think it is fair to say that the ccNSO is not delegating enough energy to this particular item. We are taking it very seriously. That was just my comment. The question I had is actually directed to probably Peter or at least it's about how the board sees one of the latest developments, in our opinion, and slight concern that we may have from the management point of view. I think ICANN is very dedicated to stability. And so, I guess, the board has a view on the different departures from the ICANN management team that have occurred since about a year. I think, of course, the most prominent event was Rod's arrival and the change of CEO, which was planned. But this occurred at a time where another -- a set of vice presidents, if I'm not mistaken, have also left in the recent months. And as a manager, I know that successive departures of a top management team, within the top management team, of an organization is a key risk management item for any board. So my question would be: How does the board assess the situation with regards to these departures? And are there any contingency plans in place to make sure that continuity of operations is ensured and that no memory loss occurs? Are there any specific actions undertaken? >>PETER DENGATE THRUSH: Thanks, Matthieu. Can I just pick up on your first point, and then I will come to your second one. I am delighted the work has gone on, as you say, and I'm not criticizing that. The next question really is now that we've got that number, by when do you think there will be agreement by the ccTLDs with the finance team on what the fair allocation to the cc's is? Can I ask that be as soon as possible? And if there is anything I can do to help the cc's get to the point where it is agreed that the divisional costs of the corporation -- this should be a relatively straightforward exercise -- costs are either fairly allocated or not. And there are rather objective standards by which that could be measured. I don't want to dismiss the exercise that has gone on to get those numbers. The reason why that number was produced is now promptly actioned. So if you can tell me what's the plan for getting together with the finance team, having what might be, you know, an interesting debate about the fairness of the allocation. But, as I say, it should be a readily straightforward objective. When do you think that will be done? >>MATTHIEU CREDON: I initially thought it would be pretty straightforward. But I understand even from Kevin that given ICANN's organization and the way the accounting is performed, it is much more difficult than anticipated. For instance, there is no vice president for ccTLDs or for gTLDs. And, therefore, accounting for different (inaudible) provides a lot of generic spendings that have to be spread out. And this gives a lot of room for discussions. So I think from my understanding, from the different discussions I've had with Kevin -- and probably Byron will provide further response later on -- is it is not as easy as that, even for the financial team to provide responses to our requests. So we're moving forward. Byron has a better view than me on the agenda, but that's not as straightforward as even I would have thought initially. I regret this as well. >>PETER DENGATE THRUSH: I will look forward to hearing from Byron. Like I say, if I can help with that in any way. Let me come to the second question. There are some staff departures. That is something, of course, the board is aware of and monitors. We've had a discussion with the CEO about the human resourcing plan. And I'll let Rod explain anything that he wants to about that. I think I can say in general the board is satisfied that the processes are being stably managed. We're aware of the -- when Doug goes, what happens. But the test is really, is there a replacement available? Perhaps it is really a question for Rod. I think we've probably -- as far as the board is concerned, we have one of the lowest voluntary turnovers of any organization of our size. So at a statistical level, I don't think there is any sense of risk. Rod? >>ROD BECKSTROM: Yeah. In part, we looked at the data last month and the data year-to-date. From July 1st of last year to the present, including all turnovers, was well below 7%, which I was just really surprised by coming out of technology firms in California. That's an absolutely abnormally low number, possibly in part due to the economy, but the lowest turnover number actually in the last four years of ICANN. And so, on the other hand, I look at the organization, there always is transitions, particularly when you bring in a new CEO. You will typically see management team transitions of both types, and that's just part of the process. I feel very good about the quality of people we've brought in. If you look at one of the reasons that, you know -- at least I was told that I was sought to help ICANN with the international background in managing organizations and also because there were a lot of concerns about the relationship of the organization with contacts in the United States government and in D.C. And as a point in case, we had a very good guy in D.C. but he wasn't the right guy. And we needed the right guy because we've got the IANA contract coming up, and we'd like to -- that will be up to D.O.C. to make their determination in how it gets handled. But finding someone in D.C. who is an insider, who has experience with the FCC, with the Department of Commerce, with all the inner agencies was the single most key important management step for the overall organization in my view. Because if we want ICANN to become more global, it has to have a trusted relationship with the United States government so it can be keep moving away and becoming more global. That's how it works. So with a strong risk management background myself, if I look at the risks of ICANN, that risk has been so well-managed in some ways with having an excellent person in D.C., it is not even a concern of discussion or topic with the board. But at the same time, there are risks that come with change and it's something that we're attentive to, particularly in a challenging environment like this where ICANN is very much at full utilization at my level. There is no obviously slack in the system that anyone can see on the inside. That means everything's fully allocated. Get back to the strategic planning process, we have to move from a strategic planning set of things everyone would like to do to, that which the community is willing to pay. And as you struggle with your issues here in moving from 1.8 million to some other number, we have to struggle with a huge range of services to your community and others with a fixed budget. So thank you. >>CHRIS DISSPAIN: Thanks, Rod. I'm going to close the line now because we are going to run out of time. Gabi has got some online stuff. Can I ask you to keep your questions and comments short and responses also. Gabi? >>GABRIELLA SCHITTEK: I'm reading a center from Peter Van Roste from CENTR. He is asking to Rod: What is ICANN's plan with regard to its non-U.S. offices? >>ROD BECKSTROM: The first thing is when you have got a budget that's changing only a very low number, percentage points per year, you're not going to go through huge changes in your offices typically unless you can downgrade your services for a point of time or your people are so geographically flexible you can move them around the world. Usually, you can make the significant rebalancing moves when you have got growth at a level we don't have much of right now. In my own background, and in companies I have worked with, I have typically worked on globally balancing the organizations. It is something I very much want to see happen here. Being in a slow-growth environment is not particularly conducive to doing that in terms of a short-term move. We are looking at this at the board level. I initiated the first comprehensive -- discussion we've had, starting to gather the data, what's out there in terms of what other players are doing in this space? How do they look at geographies? How do they organize? How do they develop processes? Where do we deliver our services around the world? We are actually -- the offices in some way is a -- it is only one measure of being global. Other ways of looking at it is the background of your staff. I mean, our current staff holds passports from 30 different countries. If you look at how many of them are actually born in foreign countries and how many different foreign countries, it is a much larger number than that. It is more than 30 people than 30 different countries. And the language skills much broader than that. You look at the board, if you look at where we have people working in the world, I think it is between 10 and 15 countries because we have people spread out there, regional liaisons and others. To get to offices -- it depends how you define "office." Someone could say we have an office in Cairo because Bahar has an office there and we have a technology office. And others would say that's not a big office, there is not a lot of people. There is not some critical mass. And so -- but we are looking at this. We have got a process going on with the board to take a look at this issue. I personally want to see ICANN globalize its operations as much as possible. The challenge from my CEO standpoint is there's no slack in the system. We're piling on more things right now and the budget's tiny. So there's not pieces that are sort of getting cut out where we can say let's shut this down. But there are no areas, and I'm asking people, for example, to look at the new gTLD program and say, "Where should that really be?" I mean, before I came, it was started in the L.A. area and that's where the primary staffing is at present. But I'm asking the question why? Should that really be in L.A.? Or should that be in Asia? Or should that be in Europe? I mean, I don't know why that should necessarily be in L.A. And that's a new program that might have significant head count hires in the future. So I'm posing those kind of questions as a manager. So I don't have an answer as to which offices where and when. I guess what I'm reflecting is the thinking process that we're going through. I can certainly say in the short-term no big plans on changes. I mean, Brussels is an important office for us. We have some people here. We have a lot of people who work through here as a hub, but no other significant office openings are contemplated because there's not the financial resources to support it. >>CHRIS DISSPAIN: Thanks, Rod. Peter has a couple quick points. Then I'm going to Byron and then to you. >>PETER DENGATE THRUSH: Just to confirm, there is a very strong sense on the board for the need to explore regionalizing to improve efficiency, making services accessible to people in their own time zones and in their own languages. Very strong sense for the requirement of that. We're also very much aware of the recommendations of the President's Strategy Committee for the need of improving institutional confidence by including very specifically having a more multi-national structure. One of the findings of the President's Strategy Committee is that a California not-for-profit corporation does not expand legally or institutionally. It is not a structure that you can take and turn into a global body. There's a huge problems, and Rod has mentioned some of them in relation to passports, et cetera. That recommendation hasn't gone away. We are just exploring it. Finally, in terms of what do we do about that, we have asked Rod to do a presentation. We had a very good presentation at the Kenya, at the Nairobi meeting. So, I guess, you know, this is -- this is on our plate, but it is a major exercise. Thanks. >>CHRIS DISSPAIN: Yes, Michael, quick, if you wouldn't mind. >>MIKE SILBER: I don't want to get into the substance of the discussion because there are some issues and concerns over there. The only point I wanted to make to the cc community is these are issues that are being raised on the board, but I'm not hearing them coming from the community. So if you want me to raise them or Peter to raise them, then you need to feed that through to us. At the moment, the gentleman in the front, Jean-Jacques Subrenat, is the person who's leading the charge on that, and Peter and I are backing down because it's not something our community has expressed itself as being a particular issue. Without your feedback, we're only half effective. >>CHRIS DISSPAIN: Understood. Byron? >>BYRON HOLLAND: Okay, thanks. Couple questions and comment. Probably won't be any surprise that my questions are about money and operating plans. First, just a comment on the staff, though. You know, as a CEO, I certainly recognize -- as a CEO myself who has made some significant staffing changes, that is part of the process and you need to do that and that's certainly your prerogative. That said, for those of us in the community, a certain level of stability is also important. Doug Brent and Kevin are folks I've worked with very closely and have a lot of respect for both of them. Certainly on the financial side, continuity is helpful for the discussion that we're trying to have right now. And I just want to say that we've been very happy with the work that Kevin has done to date. So that said, I would like to actually post this question to both of you -- sorry, to Rod or Peter, one on the expense side and one on the revenue side. As you know, we are engaging in the discussion on the revenue side. Unlike contracted parties, which Peter you were sort of indicating we would be like, you said it is $9.8 million allocated and, therefore, figure out a way to divvy it up. I would argue somewhere between the GAC who pays nothing and somewhere between the GNSO community who pays the full ride based on contract, we lie somewhere in the middle. We have countries that are much more able to pay and some that are much less or aren't able to pay. And, therefore, our situation is quite different in terms of allocating it. I just want to get your sense, your personal opinions right now, on whether or not you think it is fair that ICANN can just say it's $10 million for cc's and, therefore, pay $10 million or you recognize that given the different circumstance, a different solution and, hence, a different number is going to be the likely outcome. So that's on the revenue side. On the expense side, if you are going to go down the side of "pay the full freight," it comes with that the notion if we are paying the full ride or something much closer to it, do we have a Chinese menu on the expenses? I like this. I don't like that. If I'm paying, therefore, I don't want this number of things or activities? And is that really where, from a philosophical point, we want to take this? And I would argue that perhaps that may be just an endless loop discussion that will be very difficult to achieve consensus on internally for sure and perhaps even in the broader audience. So I would just like to get your actual -- both of your personal opinions on those two. >>PETER DENGATE THRUSH: Thanks, Byron. Good questions. The first question was if we come up with a number and it costs 10 million, you should pay 10 million. The first point is we would like to get to the stage where we agreed what the costs are, and I'm wanting to make sure we do that. Personally, if we got to the state of saying the cc's accept it costs 6.2 million to run the cc side -- and this would be our share of the it, I don't have any difficulty with a community-developed program to say, "And we are going to pay 75% of that." So I don't want to argue about the number. But as a matter of principle, I can accept a discussion which says, "But we are not going to pay the entire amount for some reason." But my criticism is there has been no development of that as an argument and no development of that as a theory. The problem of allocation keeps being thrown out. So my challenge is to go through that process that. First, set the number and, second, come up with -- start a process for saying, "Once we got the number, what is a fair allocation method?" Your second question is, Is it fair that you just get delivered with a whole lot of stuff and told that you have to pay for 1/10th share of a marketing manager when you may not like the idea of a marketing manager? I think that is an institutional gap that we have to bridge. I want to see much closer integration between the organs, and I do want to see on occasion a much more divisional concept of the corporation. I think you people -- I think the individual constituencies each should be much more closely involved in the budgeting and preparing process. I think there is still a sense that there is a staff over there that does things and community of volunteers over here, and I would like to see a way of bridging that much more closely. So you will never get complete harmony but much more a sense of -- that the staff are your staff, that you have selected them, that you have negotiated with the CEO for the kind of services that you want and that they're being provided. So I want to see that coming together so that it's not just being presented with a list over which you feel you have very little control. >>MIKE SILBER: Sorry to interrupt you, Peter. If I can suggest that the GNSO is pretty much working along that ala carte model. I think that's maybe a more appropriate -- where there is a list of services and you tick the various boxes of which service you want from which box and certain ones you can decide not to take and entirely others you can just have at different levels. It may be something worth exploring with them. I also would have thought given the commonality on the ccNSO and the GAC on certain issues that while not specifically agreeing to pick up and sponsor some of the costs of the GAC, it would be one of those overall institutional costs that the ccNSO would recognize. At least a part of those costs would also be part of the ccNSO costs. >>PETER DENGATE THRUSH: Can I just pick up on my own point, that discussion that you had that there is amount of X you get but we are only going to pay a proportion of X, that's a discussion you have to have with the GAC and the gTLDs. The gTLD community cannot understand why you don't pay the share and they are paying 160, 170% of the costs. That is an absolutely classic cross-community discussion. Take it up with the GAC. Should the GAC be completely funded by other domain name registrants? >>CHRIS DISSPAIN: Rod, just quickly. >>ROD BECKSTROM: Quickly. Byron, thank you very much. One thing that would really help me better understand the dimensions of this problem is better understanding the ccTLD business models and revenue model. I mean, I know there's roughly, what, 100 million names out there in ccTLD land? I don't know the exact number. Some of those are free. Some of those are one renminbi. Some are 150 cents a year. The question I have for this community that would help me understand: What is the average revenue? What does that model look like? If it is four Euros, for example, or $5 per name, it is roughly a $500 million a year revenue source just on names and not on other services. And I would look at that and think the most simple model for getting something done is a percentage model, which is done in other areas. And so if you took -- let's say it is 500 million, well, then 2 or 3% gets you to the number. But I think you're asking for more services. So 3% gets to 15 million. But it would help me to understand -- I don't know what the average charges are. Has this community calculated that or estimated that? >>CHRIS DISSPAIN: We pretty much know. We know roughly speaking what each other charge and how many names there are. It is a vast array of different models, a vast array of different numbers; and you can't actually apply a straight percentage. If you take -- I will give you just one quick example. .auDA has 1.8 million names in dot au. We are the policy body, the ccTLD manager, but we don't actually run the registry. We contract the registry to .NZ registry. I manage the registry, but it is a separate company. And so how do you work out what that revenue is? Our revenue is $3 a name every two years. The registry's revenue is different. So that's just one example of -- if you go down that path, of trying to work out the numbers, it gets incredibly complicated. I'm really conscious of time. I'm sorry to do this to you, Byron. Did you -- >>BYRON HOLLAND: No, that's fine. >>CHRIS DISSPAIN: That's Jörg, isn't it? >>JÖRG SCHWEIGER: This is Jörg from denic. Just returning to budget issues, probably just (inaudible) -- I just do not understand some things over here. I personally asked myself, why are we calling for more budget to be paid by the ccTLDs? Of course, I understood that the strategic plan is a wish list. And that budget is associated or allocated to certain issues and point on this wish list according to whether it is accessible or not. So if I just to have a budget of, let's say, X, I would spend exactly X and not Y. So if we do know we have a certain budget, then, just, well, operate and work with that budget. Why are we calling for more? >>CHRIS DISSPAIN: Jörg, thanks. I don't want to get sort of back into a discussion, but I think the comment is well made and well taken. >>JÖRG SCHWEIGER: Okay. >>CHRIS DISSPAIN: You're okay if we move -- Yeah. >>JÖRG SCHWEIGER: It was more of a comment. >>CHRIS DISSPAIN: Steven. Real quick. >> STEPHEN DEERHAKE: Question, Rod. What I heard this morning it appears that the ccTLD cost gap is about $8 million. And I think we can all agree that that's a rather substantial sum. Within the gTLD space, the core metric to measure gTLD payments to ICANN is a per- domain fee due to ICANN per registry. If this methodology is applied to ccTLD registries, what we would see are some with a per-domain contribution of zero because some registries obviously are not contributing and others are with a per-domain contribution that's far in excess of what you're seeing now with the gTLDs such as dot com and dot tel. My question is as follows also: When it would be ICANN's preference to adopt the approach in the gTLD space as its basic methodology for working out how the ccTLD community meets the proposed contribution? And if not, what approach would ICANN like us to use? >>ROD BECKSTROM: Thank you very much for asking the question. I would have to say that ICANN would be happy with any approach that you come up with, that you can buy into in your proposal and that we can implement. And so whether that's a percentage or that's a fixed fee per name. And as you said, in the space of the gTLDs, those fees are different according to some names. There is some consistency across some of them and less across others. But, you know, I think we're flexible. We would just really like to see the gap narrow and have whatever we do be implementable. >>STEPHEN DEERHAKE: Do you have a preference? >>ROD BECKSTROM: Well, sure, from an operating side, you always want simplicity. So whatever is the simplest method of measurement and collection would be preferred. But, you know, I think -- >>STEPHEN DEERHAKE: And what is that? >>CHRIS DISSPAIN: Steve, come on. >>MIKE SILBER: That's for you to do the work. >>CHRIS DISSPAIN: I think your point is very well made, and I think the response is that we should -- we should figure that out. Last one and then we really have to close this off. >> LISE FUHR: My name is Lise Fuhr. I'm from the Danish registry. I just want to make a short remark because I don't find that what you say and what you do correspond. You say you want to be a global organization and we have to do cost reductions. And then I see you open office Number 2 in the State of California. To me that's not the correct signal to send to the international community. >>PETER DENGATE THRUSH: Perhaps I can answer that because I was responsible for negotiating that with Rod. We previously had a CEO operating out of Sydney with an office in Los Angeles. And the board's experience of that -- and I think part of the community's experience of that -- was that that's not optimal. When we set out the CEO position, we said we want someone who is going to work out of the Marina del Rey office. In fact, none of the short list of candidates could actually do that for a variety of reasons. So it became reasonably apparent during the negotiations that we had to do something else. Rod's arrangement -- and this is written in his contract -- is that he's able to open an office with a limited number of support staff where he lives, which is in Palo Alto. We actually find that to be a reasonably sensible commercial solution. It is certainly much closer to Marina del Rey than Sydney was, and we've opened -- well, we've negotiated for an office there. Rod, I think we have actually had offers to purchase the office. It turns out the deal we made at the bottom of the recession to get very good space very cheaply for our CEO and his support staff has turned out to be a very good one. But that's if you like the contractual relationship. I don't think that's got anything to do with the topic that we talked about, that is, if you like an administrative exercise related to the employment of a new CEO. It is a distinct improvement over what we had before. It has nothing to do with the globalization of ICANN or the opening of offices to provide regional services. Rod, do you want to add to this? >>MIKE SILBER: Sorry, with all due respect, we have had this discussion on the board. And I don't think it is worth misleading the community by making that statement. While I agree with everything you've said around the arrangements around the Palo Alto office, the optics are not good. We know they're not good. And for Rod to sit here saying we don't have the money to set up another office outside of the U.S. when we spent money on an office in the U.S. doesn't look good. I don't think we can say it is just an administrative matter, please ignore it. We've got to come up with a better reason than that. We do have a good CEO, he made a choice we accepted it as a board collectively. It wasn't Peter who negotiated it. We were told as a board that was one of Rod's requirements. We accepted it as a condition. That being said, it doesn't look good. We are aware it doesn't look good, and we need to come up with something better than "it is an administrative matter." I'm sorry to interfere in this. [Applause] >>CHRIS DISSPAIN: I think -- I think we need to call this to a close now simply because apart from anything else we have other sessions, and Kim has been sitting there very quietly waiting. Can I just acknowledge Michael and Peter and Rod for coming and being prepared to talk. And, also, can I acknowledge all the other members of the board who I know are in the room right now for coming as well. Thank you. And you know that you're all welcome at any time at our meeting. So, please, don't feel that you only come to this session. We always like having you around. Could you join me in thanking Peter and Rod and Michael. >>MIKE SILBER: Thank you. [Applause] >>PETER DENGATE THRUSH: Thank you. >>MIKE SILBER: Chris, sorry to take another 30 seconds from your time. If I can encourage people -- I don't get nearly enough board mail at the moment. If there are specific issues, please if you don't have my address, let me know. I will give Chris all my addresses, personal, commercial, ICANN, whatever it may be. Contact me, let me know because if I have a sense of the community, I can feed it through to the board. If I have no sense, then I simply exercise my fiduciary responsibilities, and I push through on the basis of my best judgment. But I don't necessarily then speak for you. >>CHRIS DISSPAIN: Understood. Thanks, Michael. Okay. Now, we are running late and coffee -- cheers, Rod -- we are running late and coffee is probably gone. I am going to suggest we do a five-minute comfort break because I certainly need one and let Kim get set up to start his presentation and we will get going again in five minutes. Please, if you are going to leave the room, that's fine. But, please, if you want to hear the IANA presentation, come back as quickly as possible. Thank you. (Break) >>CHRIS DISSPAIN: I am going to start again in a couple of minutes so if you want to go out, go out and come back. Ladies and gentlemen, could you please take your seats. We're going to start the next session immediately. Well, thanks, everybody, for making the effort. There are some -- still some people to come back but they're on their way, I know, and it's important that we get started. This is our usual IANA update. Kim and Richard are here, and are both going to do a brief presentation, but before that, I'd like to formally introduce you to the lady sitting on my left, whose name is Elise Gerich, and she is the new vice president of IANA and I think we should all welcome her. [Applause] >>CHRIS DISSPAIN: Okay. Kim, over to you. >>KIM DAVIES: Thanks very much. As usual, I intend to pick on a few key subjects that we've been working on since we last met, go into a little detail, and then at the end, if you have any questions on what I've presented or alternatively, something I've forgotten, please feel free. The first major topic we've been addressing in the IANA team is IDN ccTLDs. I'm sure you're aware that IDN ccTLDs have been a major initiative of ICANN over the past few years, culminating in the final implementation being approved in the October meeting. We started accepting applications for IDN strings to be approved in November, and ultimately we started getting applications to IANA for delegation early this year. The net result of our work on IDN ccTLDs is illustrated in this graph. Outside there's a brief that says one of the meeting sponsors offers over 300 TLDs. I thought that was a little amusing, given that there's only 283. But you'll see that there's actually four non-Latin top-level domains delegated in the country code area right now. We still have those 11 testing TLDs as well, so ultimately we have 15 internationalized top-level domains right now. And of course we expect there to be more coming along soon. So we've delegated four IDN ccTLDs. One thing I wanted to note is so far, we've well exceeded our standard processing times. That's a variety of factors involved. It's really hard to estimate the amount of time that delegations take, because each one is quite different. Usually we're used to dealing with re-delegations, which involve transferring an existing operation to a new operation. That's more complex than starting a new registry. So in that respect, it's not that surprising that they're simpler because we're not involving a transfer of operations. But also, we have devoted a lot more resources internally to processing these kinds of requests, and we still give the estimate of 3 to 6 months and we don't want to set expectations too high that we'll do it within a specific amount of time, but that being said, we will do our best to diligently do the work on the requests as quickly as we can. We recognize the urgent desire in many communities to have fast-track domains allocated, and we want to contribute to that as much as we can. So far, the staff processing time involved has generally been within a few weeks after we've received all of the documentation from the applicants. And to be clear, one thing we don't intend to do is sacrifice quality. We're not changing our process, we're not removing some of the requirements. It's still a requirement that you follow the standard delegation process. So what have we learned so far? You know, we've delegated four ccTLDs. We have a number more being processed. Obviously, we've got some experience now about handling these fast-track requests. The first thing we've learned is that applicants are not contacting us prior to applying through the process. As a result, countries that are working on their fast-track applications often are doing it with assumptions on what the delegation process is without having a dialogue with us about that process. Sometimes they assume correctly about the process and sometimes incorrectly. This is really, to us, a little surprising because the ASCII ccTLD delegation and re-delegation process has been so vastly different. I've been handling delegation and re-delegation requests now for five years. It's really almost day and night, from my perspective. With the existing ASCII TLDs, we usually have a substantial dialogue over a long period of time, well in advance of papers being submitted. We understand well the situation in the country. You know, I spend half of the ICANN meetings talking with countries about delegation and re-delegation requests, and I guess obviously incorrectly we assumed that we'd have a lot of that kind of dialogue with the fast track. And that's something we need to work on to improve the process, because we feel that the model works best when it's a collaborative and iterative process. We don't want applicants to be surprised by our process. We don't want, at a late stage when you've already got your plans in place, to have to delay the process as our processing goes on. I think as a general rule the earlier we know about your application, the earlier we can talk to you about what you're doing, the smoother it will go and the better we'll be able to perform the process in a way that meets your needs. Just to highlight this, I pulled a quote out of one of the applications that I thought was illustrative of the problem. One of the applicants has stated that -- I'll just read it -- "The ICANN requesters manual has no indication that ICANN needs supporting documents evidencing community support for the proposed ccTLD manager even though such a requirement was mentioned in the final implementation plan. It is likely that ICANN believes it is sufficient for the applicant to show that the government supports the application and has nominated the organization to be the ccTLD manager. Therefore, evidence for community endorsement for the organization to administer the domain is technically not required for our application to ICANN." So this assumption is quite false. We definitely want community endorsement to be a key part of the application, but it's just an indication of a situation where an assumption about the process has proven incorrect and it's potentially delayed an application. The other thing that perhaps isn't clear is that the standard root zone management process applies. Many of you that maintain your domains know that once IANA has done its processing, we submit the application to the U.S. Department of Commerce for authorization, and then to VeriSign for implementation. This applies for delegation requests as well. So even though a board may make a decision, there is some time afterward for that additional process to occur. I just wanted to make you aware of it, because in some cases it's not been clearly understood. One thing we've managed to do in that part of the process, though, is make it much swifter. Through the combined effort of ICANN, NTIA, the U.S. Department of Commerce, and VeriSign, working together we've managed to perform these changes much quicker than expected. At least one applicant was actually surprised that it was so quick. The biggest problem being we actually didn't know it would be that quick in the beginning. You know, we provide estimates based on historical cases. We can say that while there's no SLAs, and there's no time limit on how long this can take, historically it's taken such amount of time. But in the case of fast track, it actually took much quicker. One thing I wanted to bring to your attention is one applicant expressed unhappiness that we'd performed a delegation on what they considered the weekend. The change was implemented around 6:00 a.m. on Wednesday Los Angeles time, and again, just to reiterate, that's a change that VeriSign implements, it's not a change that ICANN pulls the trigger on, so to speak. You know, it's an interesting question, and certainly we don't intend to surprise anyone about doing delegations at a particular time. That being said, it's not really an issue that we can immediately address, and we recommended that if they considered that an important issue, that they bring it to the ccNSO for discussion. We don't control the timing, but if ccTLDs feel that a particular approach should be done to root zone changes and timing of root zone changes, we'll certainly relay that feedback to those that might be able to implement it. So what are we doing? Well, right now, we're processing many more delegation requests due to the fast track. I just looked just now. We have 12 IDN-related requests right now, out of 46. 46 simultaneously root zone changes is a record, at least from what I've seen. Substantially more than we're typically used to. So, you know, it is affecting our -- it's not affecting our turnaround times but we're seeing significant amount of work associated with root zone management, as opposed to a few years ago. We're continuing to pursue publication of more and better documentation. We think that we can improve the root zone documentation and we're working to bring that to you. We're spending the time to encourage prospective applicants who want to apply under the fast track to speak to us early and often, to avoid incorrect assumptions on both sides about the process and what's happening. And we're looking at our staffing on an ongoing basis to see if adjustments need to be made to cope with the amount of work that we're receiving, particularly in mind that in the medium term, new gTLDs are expected to arrive. So that's my update on IDN ccTLDs. Another project that's slightly related actually bridges the two themes of my presentation is the WHOIS server. We provide WHOIS server. Most people probably don't even know it exists. It provides lookup service for top-level domains, and one thing we've done is upgraded it, added a few new features that I think are very useful and important. So this is the output that we see today from the IANA WHOIS server, and this is the output from the new WHOIS server. You know, superficially there are some formatting changes, but side by side they actually contain the same data. There's nothing -- we haven't added anything new in terms of the data but just highlighting a few of the things we've done, firstly we've added IDN support. When you query IDNs, you get both the IDN encoded label and the Unicode label back in your answer. We've formatted it in a way that is much more machine-readable. It's what we call RPSL style. It's a WHOIS format used by a lot of ccTLD registries, so there's a lot of commonality in the way it's structured. Should make it easier to read and also easier to process. And finally, we've added DNSSEC support. So those TLDs that are coming online with DNSSEC, you can do WHOIS look-ups and find the DNSSEC information as well. One extra feature that we've added is you can actually query any domain. Not just the top-level domain, not just dot INT domains, but you can look up, you know, domains within a ccTLD and then if we don't have the information, which of course we wouldn't, we'll provide a hint on a referral. So if people don't know the WHOIS server for a particular ccTLD, they can look up any domain and our WHOIS server will tell them what the most appropriate WHOIS server to query next is. And one completely new feature is we now have complete IP address support as well. You can look up any IPv4 address, any IPv6 address. We'll show you allocation information. If it's assigned through a RIR, we'll refer you to their WHOIS server. We support AS numbers. We support number ranges. We support single IP numbers, and a bunch of other stuff. So finally, signing the root. This has consumed a large amount of time within ICANN over the past year. It's involved many different departments. In fact, my colleague Rick will go into more detail once I've finished. But it's certainly something that's touched on IANA as well. Where we're at right now is we are now accepting DS records, so DNSSEC-enabled TLDs right now can apply for the DS records to be inserted in the root. We started accepting these just a few days ago. We've received the first submissions. We're just at the tail end of processing them now, so I think you'll see the first DS records in the root just in the next couple of days. Another important thing which I'll go into detail about is the key signing key has been generated at a key ceremony, and just to be clear, the root zone is already signed but at the moment it's published as a deliberately unvalidatable state. Which means you cannot do DNSSEC validation but that's expected to be lifted shortly, so we can do a full launch. So we had a big event last week. The first-ever key signing key ceremony. I think it's fair to say I had no idea what that would entail a few months ago, and I'm sure most of you have no idea either. What it is is generating that private key that will be used to sign the root zone in a secure manner that can be then trusted by the community as the private key that secures the root and ultimately the DNS system. One of the participants in the exercise last week read a long summary and I've just excerpted what I thought was a neat little summary out of what he wrote. "The ceremony lasts several hours (7-ish in our case) and combines the scripted predictability of a Broadway show, the detail-oriented pedantry of a pilot's checklist, and the excitement of watching paint dry (brand spankin' new facility even smelled like paint). It's choreographed to the nines, with sign-off and time stamp on pretty much every single step." Sound fun? Well, that's pretty much what it was, and even though the event was quite impressive and it was really an important step, being in that room for seven hours wasn't what I'd consider the most fun I've ever had. So what happened? Well, we have this facility on the U.S. east coast, a secure facility. I'll let Rick go into the details about access controls but there's a variety of access controls, to ensure that no bad actors can get in and do bad things. We invited a number of community representatives to come in and observe the event and participate in the event. There was also a number of ICANN staff. There's different roles for different people in the ceremony. Some members of the community received access credentials, keys. They received recovery keys, shares, and a bunch of other things. And the idea is that that will come together at future events and participate in future ceremonies and using those credentials can help further sign the root zone by generating new keys, doing other functions. The actual device that holds the private key is stored in a safe. The smart cards that are used for accessing that device are stored in another safe. All of this is stored inside the room. This is actually the unboxing of the device that holds the private key. Very impressive I know. This is it being plugged in, and this is it working. This is it actually generating the private key, so, you know, this is what everyone was witnessing. After the private key was generated, the public key part of that was shared with the group. They all received printouts. They can all take that home as sort of a letter of authenticity, to confirm that when the root zone is signed in a month's time, they can compare what they have from that event and make sure that it's the exact same key that's being used. Matt Larson from VeriSign whom many of you know was there. He was there participating in the second step of the process, which was taking the KSKs and getting them signed by the -- sorry, taking the ZSKs, getting them signed by the KSK. There's Rick pressing the button. And at the end, you know, Doug -- Doug Brent, from the back, was thanking everyone for participating and coming along. So I think that we -- we actually have a video of a lot of the detail of the process online. I don't want to expose you to all of that, but I've condensed it down just to a minute or two of the video, which I think is -- helps you understand the process a little better, which I'll play for you now. >>VINT CERF: I would compare this to the arrival of the World Wide Web in the early 1990s in terms of its enabling capability. Of course we'll see whether that prediction holds up, but it's a very powerful step. >> It's a carefully scripted ceremony for maximum transparency. Each step is carefully lined out. We have a room full of -- oh, wow -- about 30, 35 people that will be watching every part of this step. Some will be participating in this process as well. The people will be brought into -- into the room. Filming begins. The whole -- the whole ceremony is filmed. It's not anything where people hum or have some sort of strange, you know, ritual or anything like that. I think sometimes it gets misunderstood. It's just a very formal process. Then there will be a process of actually pulling out equipment from various -- >> These are in a Class 5 -- GSA class 5 safe that are used by the federal government. They do have seismic sensors and they also have door sensors which would basically lock us out when the alarm systems are turned out. You can't leave the room if this door is not closed and locked. >> There's alarm systems in every -- every part of this facility, so that any unauthorized personnel set off alarms and stuff. Equipment is pulled out. We go through the steps and we generate this key inside this cryptographic box. And then once that key is generated, we'll have printouts with what is called a hash of the key, a shorthand version, not the full key, which is a 2048-bit key, but not a -- but a short version of that that we'll hand out to the participants and they'll be able to say, "We were there. We saw it generated. Not only that, we saw that, you know, there were -- there were no cards up anyone's sleeves. We saw the process, we saw it on the monitors. We -- we attest to this being generated properly. >> Generating the 2048-bit RSA key. Okay. [Applause] >>CHRIS DISSPAIN: I'm on the edge of my seat with excitement. That... [Laughter] >>KIM DAVIES: Well, perhaps it isn't the most exciting thing in the world but for a lot of people that was the culmination of a lot of work, so I think everyone was quite proud of that moment. So right now, TLDs using DNSSEC can submit their DS records at any time using the -- there's a revised template on the IANA Web site for doing root zone changes now. It now has new fields for the DNSSEC information. We'll process them the same as any other root zone change, as we've done historically, and then removal of that deliberately unvalidatable part of the root zone is estimated for 15th of July, at which point the exercise should be finished and the root zone will be signed. So just one, I guess, reality check for the moment. This was the -- the slide I showed earlier on the number of TLDs. The number that is signed right now is substantially less impressive. Half of the signed TLDs actually are operated by ICANN and, you know, there's not a lot right now. And we recognize that a lot of you have been holding off until the root is signed, so that's not a criticism, but it's just a reality check that right now the vast majority of TLDs are not signed, so probably cannot immediately participate in the signed root zone. So submit your trust anchors. We have a procedure document on our Web site that explains the process in more detail, but we're ready. And then very last before I finish, I just wanted to firstly recognize David Conrad, who isn't here right now but David and I joined ICANN pretty much the same week and I think many of you know he's been instrumental in bringing IANA's service to what we see today from what we saw before, and, you know, it's certainly been a team effort but David has been a key part of the team. David's moving on, and his last day is in a couple of weeks, so we'll greatly miss him. I think he's contributed a lot to our team. But I'd also like to again introduce Elise, who is filling a new position of our vice president of IANA. We're very happy to have her on board, and we really look forward to working with her in bringing you IANA service into the future. So with that, I'll finish my presentation and I'll leave it to Rick to fill in the gaps of what I said. >>RICK LAMB: Well, there's not much more I can add to that. Kim always does such great presentations. The one other event that happened in the east coast while we were doing this was Kim wore a suit and it was very -- it was quite impressive to see him. He looks pretty good in a suit. I could put this on the screen, but I won't. I'm just going to summarize some of the stuff you might see on the DNSSEC workshop on Wednesday, but there were 30 people in the room for seven hours. No laptops, no cell phones. You know, this lasted from about 1:00 in the afternoon to 8:00 p.m. You know, and people were very patient. I minimized the number of times anyone could take a break and was considered ogre for that but, you know, we wanted to get this done. You couldn't stop because keys were being generated, cards were sitting outside, things were exposed, so very professional. No way, you know. But out of this, we had 16 trusted community representatives, and I'd like to -- you know, this is just going to be a spiel about thanking you guys, because without you, this had no value. Anybody can generate a key. You can generate it on your laptop. Anyone can generate a root key for DNSSEC. What made this special was the community, the public participation in this thing. And it was direct participation. You know, they -- they were -- as Kim mentioned, some people have physical keys to safe deposit boxes, they have pieces that we need in order to be able to perform our function four times a year. Some people actually have smart cards in tamper-evident bags that are used for deep backup, say should the west coast fall into the ocean and the east coast get blown up because of its proximity to D.C., although it's -- the little city was a little -- just outside the nuclear blast zone. Go figure. So anyway... [Laughter] But again, there were so many people to thank for this. We had contractors from all over. We had a couple -- we had 11 ICANN staff. A lot of is this tough -- you know, I have to mention the guys that did the work for dot SE. You know, their trailblazing work really started us on this path and later we, I think unfortunately for dot SE, took all of their time. And so we've had them for the last couple years, and of course Matt was there. The DNSSEC key tag that was generated for that day -- not that it's anything special but, you know, you'll start seeing this key tag every was -- 19036, so I don't know, that's -- to me that's kind of interesting. I wanted to print up T-shirts at the end -- I wanted some T-shirts preprinted with that number on it, but of course I didn't know what the key was ahead of time, but that was -- that would have been cool. Let's see. So I described a little bit about the frustrated community representatives. They sacrificed their time and money to come to this thing. ICANN did not fund their travel. The communities behind them funded their travel, and their time. These people came from far away. This just was just -- just wonderful for us. I mean, this was -- this was amazing. So we had, like I said, 16 people on the east coast. This was on the 16th of June. Very hot summer day in the D.C. area. And just another fact: None of these trusted community representatives, they don't work for ICANN, they don't work for VeriSign and they have no affiliation with the Department of Commerce either. And that was the idea. Was to bring people from outside the normal group of people that are involved with root management. Okay. I would like to put up the names of some of the people, if it is possible to move the connector. Let's see if this works. Bingo. I know this is not going to -- full screen mode, is that it? Anyway, I know the font is kind of small. But, again, without this sort of swell of support from the community, we would have nothing but just a very expensive experiment and, you know, a lot of cool safes that we would be trying to put on eBay now. So for the East Coast, we had Alain Aina from Benin. We had Ann-Marie from Sweden, Frederico Neves from Brazil -- These are all experts in this stuff -- Guarab from Nepal. Olaf Kolkman, Robert Seastrom from the U.S. and Vint Cerf. And for those seven hours, it was really impressive how these guys all stayed awake. If we did anything even slightly off, they would catch you right like that. I know it sounded really boring. I thought it was really boring, but these guys were watching every one of our moves and that was good. That actually made the whole process move much faster. Also, at the East Coast was that center column of recovery key shareholders. We had Bevil Wooding from Trinidad/Tobago. Dan Kaminsky, of course, the trouble maker himself was there to also witness which was great. Jiankang Yao from China, which you may have seen some of the IDN and international e-mail work. And Moussa Guebre from Burkina Faso had made a very difficult trek across the ocean to get here. Norm Ritchie from Canada, Ondrej Sury from Czech Republic who did a lot of technical work, runs dot cz. And, of course, Paul Kane. There are other names there, but I just wanted to recognize those people and thank them. That's really all I need to say. All the work that was done -- all the software is Open Source software. There is a lot of documentation and scripts and details that go behind this stuff. It is all free. If you guys decide that you have to -- you would like to build a system of similar level of bullet-proof security, you know, you're welcome to take some of our stuff as an example. And, hopefully, we'll be able to learn from your efforts as well as you guys implement these things. With that, thank you. Thank you very much for helping us make this happen. >>CHRIS DISSPAIN: Thanks. Thanks, Rick. Thanks, Kim. Do we have any questions? Comments? Ondrej. >>ONDREJ FILIP: I have two questions for you. You said there is -- and I don't know what you said, there will be a new WHOIS or there will be a new WHOIS with IANA? I wasn't sure if it was implemented or it will be implemented. >>KIM DAVIES: You're right, I completely forgot to mention that. We intend to put it online in the next few days. It is actually available for test right now. We did a blog post about it about a month ago. You know, it's working for us, and we haven't received any negative feedback or screams of outrage. So I think -- >>CHRIS DISSPAIN: We'll get there. >>ONDREJ FILIP: Okay. And the second question is -- is about DS records, if you send the DS records, it will be approved, how quickly will it appear in the root zone? Will it be tied with the signature of the root zone, or will it not be tied and it will appear automatically after they will be approved? >>KIM DAVIES: So we've modeled the acceptance process the same as the current root zone change process. So you submit a template to us with the DS records listed. We do a single technical check, which is that we check if there is a matching DNSkey record in the zone. However, as with most of our technical checks for NS records, if you are deliberately listing a DS record that isn't in your zone right now, you can inform us and we can override that. We will push back if we don't see it. If you come back and say, "that's okay, that's by design, I'm absolutely sure that's the right DS record," that's fine. It is more there is a check in case you make a typo. We then submit it to the U.S. Department of Commerce for authorization and to VeriSign for implementation. We expect that to be on the same time frame as NS record changes, so within a few business days. One thing that's different from the ITAR, for those of you that use the ITAR, there's no scheduling of appearance. So you can't nominate a start and an end time. Rather, when you want it to be listed, you send us a request. Down the track when you want it to be removed, send us another request and it will be removed. >>ONDREJ FILIP: So the DS records will appear automatically before the root signing, right? >>KIM DAVIES: That's right. Our intention is to have DS records in the root well before we remove the DURZ. >>CHRIS DISSPAIN: Thanks, Ondrej. If you can bust your way through Ondrej. >> FAHD BATAYNEH: Okay. Hi, my name is Fahd Batayneh from Jordan. Jordan got its IDN ccTLD approved back in April, the 21st, and we actually started our delegation right after that with IANA. We abided to the rules and regulations that were shown on the IANA Web site regarding new delegations. We did send all the papers required. We received an e-mail around 40 days later stating that you requested further information. And the information that were mentioned on the e-mail were actually quite, in some way or another, different to what is different than on the Web site (alarm). So I send back an e-mail -- >>CHRIS DISSPAIN: Carry on, carry on. >> So I send back an e-mail to IANA requesting clarification on why this e-mail was sent. I mean, if you have certain requirements, why shouldn't it appear on the Web site. The answer that I received was that IANA's in the process of updating their Web site. So my concern here is that if four countries have already considered their delegations, why hasn't IANA updated the Web site to reflect the information that you truly request in your e-mail? That's my first question. That's my first question. My second question is more of a concern. I believe IANA follow a generic form in terms of delegation, but that form actually does not apply to all communities. So, for example, I hear from a community where they are encouraged to use a new service but they most probably are not aware that it is there. For example, IDNs, not everybody in Jordan is aware of IDNs. But by encouraging the community to use IDNs, they are quite pushing forward for it (alarm). So the consultation -- community consultation part doesn't really apply in Jordan's case. And I guess it doesn't apply to many other countries. So I would request that ICANN or IANA or whoever is responsible for this issue to reconsider this generic form and try to make things even more flexible. Thank you. >>CHRIS DISSPAIN: Kim, do you want to respond? >>KIM DAVIES: So with respect to the improved documentation, as I mentioned in my presentation, we definitely want to have improved documentation from what's there now. The basic guidance we have on the Web site isn't inaccurate but we would like to have much more detailed information about the process, including frequently asked questions, that kind of thing. Those are on the delegation and redelegation working group will be aware that we've actually shared some of the draft documentation with them last year. We're working, as we operate under a contract, we require authorization to publish new documentation. So we're working to obtain that authorization. Until we have that, we're not in a position to publish additional documentation. But it is our hope that we can do that. With respect to the guidance and its applicability to any one country, that's actually the quintessential challenge of documenting the process which is we absolutely recognize each country's different. You know, there is a set of principles that I think the community generally agrees applies for ccTLDs, but each country is different. As staff, we provide as much guidance as we can so you can get up to speed with our process. But, again, it comes back to what I said earlier which is it is an iterative process and because we can't give you a concrete check box list of what each country needs to do because each country is different, we want to talk through with you what your situation is in your country. So as staff, when we're preparing our analysis for the board, we can take that all into account. And none of the rules -- "rules" is the wrong word -- the stuff that we list in documentation are hard and fast rules. It is more of a guide. We don't expect every applicant to provide every single thing but rather to paint a picture of what has happened in the country, what are the local circumstances and when this is an appropriate action so that when the board has to make its decision, it can feel comfortable that an appropriate process for that country has taken place. You know, that's fundamentally what it's all about. And, you know, can -- is guidance to one country going to be perfectly applicable to another? Of course, not. But we'll try and improve our documentation and process, but we also encourage applicants to have a dialogue with us as well. >>CHRIS DISSPAIN: Thank you, Kim. Elise, do you want to say a few words? And we can finish up. >>ELISE GERICH: Well, hello. I'm Elise Gerich and I'm very excited to be joining ICANN as the VP of IANA. I look forward to getting to know this community better as we go forward. I'm very exciting to be joining at this time because as Kim and Rick have noted, there are a lot of exciting things happening in the community. The staff has done an excellent job of getting us to this point and I'm the beneficiary, I guess, of all the work they've done for the DNSSEC and the other delegations and redelegations for IDNs. So I will be here all week, and I do look forward to meeting you, if you would like to stop and say hello in the hallways. Thank you. >>CHRIS DISSPAIN: Thank you. And would you join me in thanking all of these three for their work today. Thanks. [Applause] Okay. We're done. Thank you. Our next session is Rod, the anti- phishing update. And, Rod, you're ready to go? Just so you know, because we ran late with Peter and Rod -- can't think why -- we're going to move what was going to be a marketing session with Malaysia and South Africa, we are going to move that to tomorrow morning. Apologies to Vika and to Sharil. So we are going to go on with Rod. You have got a presentation up there? Okay, so anti-phishing. >>ROD RASMUSSEN: Thank you. And thank you for your time. I was scheduled for noon, right? >>CHRIS DISSPAIN: Yeah, yeah. >>ROD RASMUSSEN: We're right on time. And thank you for having me again. And I actually just came from -- just before I get started on this I came from the open SSAC meeting, and there were a couple of topics, I think, that I want to bring to your attention since obviously you weren't there that were being discussed. One was protection of registrant information. And I would like to point to -- there's going to be a -- something coming out of SSAC about doing that, about how to protect against hijackings and something like that and something that has gone on recently in the ccTLD world as well. I would like to point to a couple of registries out there that are doing registry lock type of services, and that might be something to take a look at if you are running your own ccTLD. VeriSign has got such a service, and it's a good thing to take a look at to offer to your registrants. The other is orphan name servers, and there's some studies going on. And the preliminary study was very fascinating in about 30% of orphan name servers turned up showing malicious activity on them. It is yet another thing to take a look at from running a ccTLD, is policy around orphans. So that had nothing to do with my present ace, but I wanted to get that in there. Very topical as within the last hour it was put out. So the anti-phishing working group does a semiannual survey of domains that are using in phishing attacks. And many of you have seen previous ones. This year's -- or the last half of 2009 has some interesting data in it. And myself and Greg Aaron are the co-authors but we had lots of help with other from the folks at APWG on that as well. What we are trying to do is try to figure out what abuse patterns there are across the namespace and see where things can be done to shore up defenses, change policies and things like that and really give a benchmark to the industry not just to the gTLD industry but the entire domain name industry as to what is going on. This has been very helpful in the past to help various registries put policies in place and understand where they're standing in the world. There has been a lot of activity in the last year, so we'll go over some of that. So we take a look at the entire anti-phishing working group look of URLs that come in, we get millions of them over the course of the year. And we boil that down into actual confirmed phishing sites and take a look at how long they're up, where they're located, all kinds of things like that. And, you know, we have -- we also take a look at the domains that are registered in all the different TLDs and this is where we can get information. And there is a few TLDs that we can't get information from. It would be really helpful if you contributed to that, at least let us know approximately how many domains are in your registry, if you don't publish that stat. It is very helpful in being able to categorize that. So here's the rundown for the scorecard, the top-level scorecard. As you can see, the number of phishing domains was sharply up in second half of 2009. Almost over double of what we saw in the first half of the year. This is an alarming statistic. However, there is a story behind this, and I will get into that. The number of TLDs, as you can see, is most and IP-based phishing which is .1.2.3.4 phishing site has been down significantly again. And that trend continues, as you can see. IDNs, that's a good success story. We were very fearful of IDNs being used for phishing. They aren't being used for phishing. The ones you see here are all compromised ones, phishers are not registering look- align IDN names in namespace to put up phishing sites. We have only had one example of that over the last several years. That has been a fear. I know a lot of people have put measures in place to prevent that. It seems to be working so far. Either that or the bad guys just aren't smart enough to do it, one of the two things. So the big story, as I said, there is a story behind that massive amount of new domains being used for phishing. The big story is criminal infrastructure we call Avalanche. Some of you are extremely familiar with this attack pattern because it has really gone after some ccTLDs in a very hard manner. And its responsible for actually 2/3 of the phishing attacks we saw. Now an attack is, basically, a Web site that's set up to mimic somebody, a bank, online commerce, e- mail, things like that. There is more attacks in domains because all these Avalanche sites were attacking 40 different institutions on one site. You have one domain name, you have 30 or 40 different phishing sites on that one domain name all attacking different institutions. That's how the number of attacks becomes more than the number of domains, just -- if you are looking at the math and trying to figure out what that is. All of these are hosted on Fast Flux botnets. Try saying that three times fast. And then we saw they were in 33 different TLDs over the course of the year. The other thing that's very disturbing about Avalanche is not only were they doing phishing but they are also distributing really the cutting edge malware out there called Zeus. If you haven't heard of it, that's good for you because that means you haven't had to deal with it. But it is a very nefarious crimeware tool. It can actually -- once it is on a victim's computer, it can do, basically, piggy-backing banking transactions. If I'm attacked with Zeus, they can basically remote control my computer without me seeing it and transfer lots of money without my accounts. They're targeting typically small, medium-sized businesses in the United States and cleaning out hundreds of thousands of dollars in one -- at one time out of their accounts. It is very -- it is causing millions and millions of dollars of damage a year -- I mean, weekly basis. And unfortunately for the victims, they don't even know they are doing it and the small and medium-sized businesses in the U.S. are not protecting by the banking regulations like consumers are. So people are going bankrupt and out of business because of this malware that's being distributed. It is very serious. FBI, secret service in the U.S. are looking at this. SOCA and the U.K. and the BKA in Germany are all looking at this. It is extremely serious attacks that's going against multiple folks. And this is being distributed via this attack. It is 2/3 of the phishing sites were Avalanche. Here's what a typical site looks like. This is one that happened to be attacking HSBC. Like I said, there were 30, 40 other victims. This one gets you to download a new certificate. That's a certificate -- it looks like a phishing site but what it is actually trying to do is install malware. This is the kind of thing pa people end up getting. So there's a success story here, though, too. So Avalanche was 2/3 of the phishing sites. You can see we have got the numbers up from July. If you see the solid line there is actually the number -- if I remember right, this is the number of domain names registered which is the scale on the right, there was a very large coordinated take-down effort amongst security companies, law enforcement, et cetera, in November of last year where the infrastructure was removed from the criminal's actual control. So what we saw is that they responded in December by registering a whole bunch more domains in response to losing their first infrastructure and they set the new infrastructure. But there's been continued work and effort to keep them down. So it is a big of a whack-a-mole but we actually hit the mole pretty hard on the head. So that's a good success story. Unfortunately, this does not go through this month which we're seeing attacks ramping up again. So they've established a new infrastructure doing new sets of attacks, attacking typically right now they are attacking, I believe, the I.R.S. and the Internal Revenue Service in the United States, which is our tax authority, which is again flying to download Zeus malware. But we certainly made a dent in their actions in trying to get these guys under control. Excuse me. Overall, I wanted to show also another success story that over the last several -- or last couple years we're seeing the lifetime of phishing sites on average going down in the median. You can see here over time, we're managing to get phishing sites down more quickly on average. So today we're seeing, you know, basically, a little over a day on average and the median is under half a day in taking things down, which is terrific. That's a great story. Now a lot of that is based on specific registries implementing policy to assist law enforcement and response community. So it is really a group effort here, and it is a very good success story, I think. Here's some more actual data on those up times here. What we've had to do with our numbers actually is because the Avalanche attack was so prevalent, we've had to split up our data between Avalanche and non- Avalanche. So Avalanche ironically, we got so good at responding to it that it actually brought down the median and average times for the last half of the year. Other non-Avalanche phishing sites have been staying up a little longer. There's thoughts about why that is. One is that we're spending so much effort on looking at that one attack that we kind of let some of these other stuff go a little longer or, you know, there's -- the other theory is, you know, bad guys are getting better at putting things on sites where you can't actually take them down because most phishing sites are not installed on domain names that people register -- the bad guys register. They are actually hack sites that are -- you have to -- you can't take down the domain name. And that's very key for us. We have to know who to contact at the right time in order to get something shut down. If it is on a hacked or compromised domain, we actually have to work with the Web host to get those shut down. So they're getting a little bit better at putting those on places that are harder to find, get the right contact to get them to fix them. This is a look at some of the TLDs and there have went various up times they have had on the gTLD side. As you can see, it changes quite a bit over time and depending on the size of your registry, you can get really weird numbers. The dot name one obviously sticks out quite a bit because it is not a very big registry, so they get -- their times fluctuate quite a bit when there is one particular site that stays up for a long time, it affects their number quite a bit. Overall, you can see the black line in the middle is kind of the average up time. And been turning down, there was a little bit tick up in the year. This reflects the fact that Avalanche attacks went away in November for the most part. So, again, the prevalence of that attack series and the effect the community had on it affects these numbers. I'm trying to explain a little bit behind what's in the numbers here. And these are the attacks by TLD. This includes the Avalanche data, so you can see here that dot EU had some -- they were attacked heavily by Avalanche and as a result came almost the number one domain -- or TLD used for phishing. Other ones that are on here as well, U.K. in particular, was another heavily Avalanche target. So it changes the statistics over time as to who ends up showing up on these lists. Again, trying to explain why these things are showing up where they are. And then -- but, again, dot com manages to be number one. Here's breaking out the Avalanche attacks versus non-Avalanche attacks. You can see the dot com dominates in the non-Avalanche attack series. Oh, you got a question? Sorry. Again, this is why we're breaking out the data because it so affects the scores that we had to break this out. We have been doing this for three years, but we had to break this out so you can actually see what the long-term trends are versus the short-term. So one of the other things we try to do here is normalize between TLDs, since there is such a difference between the size of the TLDs. What's the prevalence per number of registrations you have on a TLD? So we try to normalize this so we can get a handle on who's having abuse problems versus who isn't. And so we do a number of attacks -- phishing domains per 10,000 in the registry. What we've seen is the median -- what we take is the median in dot com as kind of the normal band because com is so prevalent. So if you are in there, you are like everybody else. If you are below that, you are doing a better job. And worse, higher number, then there might be some issues you would have to look into. The caveat that smaller TLDs are going to skew higher just because it is the denominator of the equation is a smaller number, so it tends to affect things. We try to tell the story behind what's going on with each one. So this is the scorecard, so to speak, on the TLDs. And this, again, haven't ran into issues with Avalanche because they have so many attacks per site. You can see you go down to Number 7 on the list is dot EU. They had a relatively -- a higher than normal but relatively small number of attacks per domain -- I mean, sorry, phishing sites per domain but they had a very high number of attacks. You can see that, basically, 30-to-1 ratio there because that's mostly Avalanche attacks because they had 30 phishing sites set up on a single domain. Again, that skews the statistics which is why we are reporting them separately here so you can get a better feel for it. Thailand has been one of our trouble spots for a very long time. And dot th, most of those are -- in fact, all of those are not on maliciously registered domains, they are actually on government and University Web servers. They are have a very high hacking rate in Thailand. And I have been told various stories as to why that is. It mainly has to do with I.T. resources in the country. Korea actually has an excellent cert and excellent program for getting things taken down they got hit hard by Avalanche during the year. However, they got hid by Avalanche during the year so their numbers skewed up here. Those are numbers there. And in the report, we have every TLD's score and the information available. If you want to know about domains within your own TLD space, you can send me an e-mail and we'll send over the data. I know several of the TLD operators have done that in the past and we've sent that data over. Some good success stories, dot uk, Nominet did some really good outreach and created what they call a phish-lock status within their TLD for handling phishing domains. So our thanks to them for really addressing this problem head on. Hn and im had a very swift response when they started getting targeted. And we have continued success from registries that have put in place programs. Hong Kong, as you may remember, was hit very hard by Rock Phishing. Now they hardly get hit by phishing at all. Biz, info and org by Afilias have very aggressive programs. I've just got a couple more slides. Okay. So malicious registrations was one of the things that people are obviously interested in, and these are things registered by the bad guys. As I mentioned before, most are compromised sites. About 22%, most of those being avalanche, were actually registered by the bad guys using your systems. Of those, a little over a thousand actually had some sort of form of the brand in them, so if I'm attacking Bank of America, it might have B of A somewhere in there. It's a very small percent, about 3 -- a little less than 4%. So the bad guys are staying away from domains that look like bank names for the most part. What they're doing is registering nonsense names and then adding the name of the bank or whatever they're attacking in the host name. That's where most of it appears. Because they realize that there are a lot of companies out there looking at the registrations and going after those domains that look like a bank's name. No surprise there. And then of those malicious registrations, you can see most of them are just in a few TLDs. And again, this is driven by avalanche. And Belgium unfortunately our host country here had a big problem with it. Now, they did manage to get around that, and -- or put things in place to mitigate that, so they've updated their security procedures and things like that. As I mentioned, only -- oh, well, that slide came out really good. [Laughter] The -- there's only been one look-alike IDN registration the last couple years, so that's a really good success story. We -- obviously we knew the new IDN TLDs are going on, and we'll see what happens within those. We haven't seen any phishing sites in those yet. One big thing important that I've mentioned in prior things is the sub-domain services. And these are people who have a domain name and then act like a registry or registrar in giving out sub-domains on that domain name. These are continuing to be abused heavily. They don't have the same -- they don't come under ICANN rules. They don't have the same scrutiny and security procedures. So we're seeing a big shift towards that. We're also seeing a shift towards other kinds of services like this. There are more sub-domain services used for hosting phishing sites than there were actual domain registrations for supporting phishing. So this is a big shift and we're tracking this, and this -- we reported on this, when we're saying a TLD has different issues, that we give credit to the TLD because, you know, there's not a -- a phishing site is not under the control or anything they can do when it's on a sub-domain service. You can't take down that domain. The other thing that -- the other trend we're seeing is what we call URL shorteners. These are things like bit dot LY or some of the things that people use on Twitter, things like that, to get a really shorter URL and then they have a referring -- or refer to a longer URL, as in a Web site. We're seeing those being used heavily, and especially this year, this number is going to go way up because the bad guys have figured out that they can do layers of obfuscation on this. And that is affecting the way that we -- we do -- we do things. And the way we look at things. Because they are able to register these for free and just -- just send them out so it really is changing the game. So just the conclusions. We had the big -- big story was avalanche. It continues to be a story but just not as big. We have some success stories and overall we're doing a better job at fighting things. And we've seen some great response out of the community, both the gTLD and now the ccTLD community, putting policies and practices in place that allow them to disseminate information to their registrars, get the information out, and get things handled very quickly, and that tends to -- to help both the situation and to -- and to get them to quit attacking on one particular registry or another. We still have some -- some issues with avalanche and right now they're using infrastructure in the dot RU namespace. Russia. And although Russia has put into place some -- some identification verification processes, we're still seeing some heavy abuse there and there's some -- we have problems with the way their bureaucracy handles domain shutdowns and so that's -- the dot RU space is probably going to be heavily abused until they can actually fix that. And I'd be very happy to talk to the dot RU folks about what we can do about that. And, you know, we're all -- we're all working on what we can do with sub-domain resellers. So that's it for the survey. I don't know if we have time for questions. >>CHRIS DISSPAIN: Thanks, Rod. That's great. Could I -- if anyone has a quick question for Rod, then please go to the microphone. Could I get the law enforcement guys who are due up next to come up now? If you're -- if you're part of the -- what's the correct collective known for law enforcement people? Phalanx or something. Law enforcement -- helmet. If you're part of the helmet of law enforcement, could you please join me up here? Hilde? >>HILDE THUNEM: Thank you. Hilde Thunem from the Norwegian registry. Thanks for a very interesting presentation. I note that 80% -- roughly -- of the phishing sites is not really connected to a domain being registered by somebody bad, but basically being somebody else having their computer hacked. >>ROD RASMUSSEN: Correct. >>HILDE THUNEM: So in the large majority of the phishing issues, there is really nothing we as a registry could do, or what do you think we should do in cases like this. >>ROD RASMUSSEN: Well, there's -- depends on the model of your registry, right? One of the things that's very helpful for either a registry or registrar to be able to do is inform their customer, the registrant, of a compromised site. But typically when we're doing a shutdown of a phishing site, if it's a compromised site, you'll never hear from us, right? Hopefully. If you hear from us, it's a mistake. If we're asking to get a domain shut down. >>HILDE THUNEM: Yeah. >>ROD RASMUSSEN: And I think that the industry has gotten very good at identifying whether or not a domain name has been purchased by the bad guy or is just simply been compromised and not sending notifications to the registries and registrars when it's -- when it's a hacked site. >>HILDE THUNEM: Yeah. And I think that's very, very helpful, because as a registry, it's fairly frustrating to be asked to turn off sites that actually belong to somebody that is a good customer and that hasn't done anything wrong except getting a virus on their computer. >>ROD RASMUSSEN: Absolutely. And I would -- I would encourage any registry or registrar that gets notification to shut down a domain name of a legitimate customer to give feedback both to the people asking to shut it down and to the antiphishing working group. Because we have -- you know, we are peers and we will, you know, obviously work with people who are having issues identifying which kinds of sites are -- they're trying to go after. So we want that feedback when there's a problem like that. >>HILDE THUNEM: Last question then. I haven't had time to read your report yet, but since you seem to have the metric of the amount of domains that are -- or the amount of attacks that are simply hacked sites and the amount of attacks that is actually connected to badly registered domains, would it be something that you would actually produce for the relevant ccTLDs in the report instead of just saying that there were 12,000 attacks in Thailand and also actually saying that -- and the number of the attacks that is actually connected to a domain is 1%. >>ROD RASMUSSEN: Yes. Actually, in our -- in our full report, we actually do the number of malicious registrations versus the number of hacked sites for each ccTLD. So that number is in there. >>HILDE THUNEM: Thank you. >>CHRIS DISSPAIN: Thank you, Hilde, and please join me in thanking Rod. [Applause] >>CHRIS DISSPAIN: Okay. We're going now to our law enforcement update, and I'm going to hand off to Paul Hoare from SOCA e-crime who is going to take us through this session. Paul. >>PAUL HOARE: Hello. My name is Paul Hoare. I'm with the Serious Organized Crime Agency in the U.K. On the panel with me are Adrian Koster from the Swiss Intelligence -- >>ADRIAN KOSTER: Cybercrime unit. >>PAUL HOARE: Cybercrime unit. And Marcos Vinicius is from the Brazilian federal police. There are numerous other law enforcement officers here. >>CHRIS DISSPAIN: See if you can recognize them. >>PAUL HOARE: Yeah, yeah. [Laughter] >>PAUL HOARE: The -- everyone is in suits, I think. [Laughter] >>PAUL HOARE: The -- I'd like to say thanks for giving us the time and the opportunity to address you. Certainly the RAA amendments have been in front of ICANN for a little while but I don't think we've actually spoken to the cc community about them in such a formal forum as such. It's always nice to follow Rod on the stage because I don't have to go through what we're actually seeing at the moment, because he's just done it far more eloquently than I would have done. What I would just would say is that Internet crime is not just about fiscal issues and not just about phishing. There are -- there's true human suffering behind Internet crime, and it -- the drugs trade, human trafficking, the trade in firearms, and child abuse, of course. It all wraps up in the use and abuse of domains. As you're going to be -- the way we're going to run this, I'm just going to speak for a few minutes and I'm going to hand off to my colleagues to speak, but I think what we'd like to do is obviously leave some time to engage with you for a question-and-answer session at the end. But as you'll be aware as ccTLDs, probably more than anybody else at this forum, cybersecurity is on the agenda of all governments of the world, and it's level, and resourcing and commitments to cybercrime has increased exponentially over the last 12 months. It can -- the proposals, the RAA proposals which I don't intend to go through in detail here because they have been circulated and I hope people have read them are -- have been in front of the GAC since October last year, and they're fully endorsed by most GAC members. The law enforcement globally, we've taken a lot of effort to actually engage law enforcement globally, so I don't sit here effectively as a representative of the U.K. law enforcement community, but as global law enforcement. The Interpol cyber working groups, the G8 cyber working groups are supportive of the recommendations we've put in front of ICANN, and there are several representatives of law enforcement here. There's also the Belgian federal police, the Japanese federal police, the Swiss federal intelligence service to my right, the FBI, the DEA, and the United States Secret Service, the Brazilian federal police, the Dutch police, the German BKA, Interpol, the New Zealand police and the Indonesia police are here. They're a small snapshot of the law enforcement agencies that are interested in this type of work because what we're actually trying to do is affect all criminals, rather than picking one or two off as has been the traditional law enforcement methodology previously. The International Associations of Chief Police Officers have supported it, as have the Messaging Anti-Abuse Working Group, which is important for us as a big industry concern. And the Council of Europe at the officers conference earlier this year supported the recommendations. What I would say is there are many, many registrars and registries who have very, very good processes and due diligence is in place. What we -- what we would -- these -- the intention of these recommendations is that what we want to do is improve the accuracy of the registrant detail and its availability and to also take the takedown process. The good practice that's in place, all that happens is the criminals migrate to those registrars who don't have as good of processes as others, and it's not a -- it's not a -- the good practice is not industry sector standard, and there is a need for minimum mandatory standards, so that everybody comes up to that level. What got pointed out to me before is they are minimum standards, so those of you that -- or those of the registrars who do more than that, we wouldn't be expecting them to come back down to those standards. That is a minimum. And they need to be enforced. ICANN needs to enforce standards that's already written into the RAA, and those that are going to be added. Law enforcement need accurate registrant details. And it's not just law enforcement, it's those agency -- those industry bodies, security bodies, the financial industry, who actually mitigate the majority of crime as well. Most disruption and mitigation of crime is not done by law enforcement. We're a very small cadre and I can talk about that for hours if you want. We need swift takedown processes for those who don't supply accurate data. What we're trying to make -- one of our big problems, which you're probably aware of, is that crime means a hundred different things in a hundred different jurisdictions, and getting cross-jurisdictional cooperation is sometimes difficult in the face of different laws. What we try to do with these amendments is to make them crime-neutral, so they're not actually about crime or the nature of the material, it's about the registration details and the accuracy of registration, and handing over accurate details when you buy a domain name shouldn't be beyond anybody. What we have done is recognized the privacy issues, that it's very important that people have -- have privacy in the proxy registration and the privacy issues are explicitly recognized within the RAA amendments. So what am I doing sitting here? I very much realize that you're not part of -- the part of ICANN's RAA amendments or accreditation agreements and I wouldn't -- certainly wouldn't lobby for you to be so, but I would look to the ccTLDs to consider and possibly implement these recommendations as well, and to lead the way in good practice. Interpol representatives certainly from across the world are supportive and we'll probably be in touch in the near future as to what -- how you can cooperate more between law enforcement and the ccTLDs. And certainly within the U.K., we work very closely with Nominet, and that relationship's very productive. And I know a lot of my colleagues work very closely with their ccTLDs, but I would encourage any of you that don't have good relations with your national law enforcement, to develop so, because they will be coming to you. And with that, before I go on and on and on, I'd like to hand off to Adrian. >>ADRIAN KOSTER: Yeah. As he said, my name is Adrian Koster. I'm with the Swiss Federal Intelligence Service, the cybercrime unit. I'm here to talk to you about the Swiss model case, about the measures that we have taken to address the abuse of the dot CH domain. As everyone probably knows, in Switzerland there are banks, and banks are -- get phished or the customers of the banks get phished, so we had quite some -- some troubles with phishing, and one of the first measures was that the registry, they further -- before, they had the possibility that you could register a dot CH domain and they will send you a bill that was payable by 30 days. So actually in phishing, we know it's the first some days that are crucial, so they changed the terms and conditions so you had to pay up front and you couldn't use -- you could register your domain but you couldn't use it before there wasn't -- it wasn't paid. So that already led to a huge diminishment of Swiss ccTLD to be abused. Furthermore, we had our regulator to introduce some new regulation, and that we as a -- accredit by the -- a cybercrime unit who has to be accredited by the regulator in Switzerland could actually make a super-provisional order to the registry so they would have to block a domain name and delete -- so delete it from the zone file, if it was used for phishing or the distribution of malware. Why did we do that? We -- that's -- basically it's limited to phishing and malware because there is a danger, an imminent danger that customers give away their credentials or that they get infected by malware. But when -- once the super-provisional order is issued, the registrant can ask back and enter the due process in mitigation of this issue, and if they are criminals, we haven't seen someone starting this due process so far. Another thing that we introduced in Switzerland, we -- before -- or until now, it was still everyone in the world can register our ccTLD domain, but if there is a problem, any Swiss authority can ask the registry to demand an address of correspondence within Switzerland, so we have the possibility to take jurisdiction over our own ccTLD. This wasn't so clear before because if the only point of attachment was the dot CH domain, it wasn't so sure if -- who should decide on is this legal, is this not legal, should we retract the domain or do we have to -- to let it flow. So now this is all in the terms that came through regulation, but entered in the terms and conditions of our registration, so it's not a -- a governmental but more a private contractual issue. So the registry can demand from the registrant to establish a correspondence address within Switzerland where we could issue court orders. And also enter due process within Switzerland. Yeah, I believe that's it for the moment. Maybe there are some questions. >>CHRIS DISSPAIN: We might take the questions at the end. I think it's probably easier. >>ADRIAN KOSTER: Okay. >>PAUL HOARE: And next, Marcos Vinicius from the Brazilian federal police. >>MARCOS VINICIUS: Thanks, Paul. Good afternoon. I'm working with the computer forensic unit. We are based in Brazilia, and most of the information my colleague from Switzerland has said also happens in Brazil. So what I'd like to mention is that in Brazil, we do have a good relation with our registry authority which doesn't mean we don't have problems with dot BR domains, but when we find some problems, we had already a good contact with them, and we can solve things faster. So that's just a matter of cooperation. Sometimes it's hard to -- to get together inside our countries, but when it comes to big meetings, such as the ICANN meeting, we can talk better about these issues, so that's one thing I should stimulate the delegations to try to cooperate, and that's what we are trying to have in Brazil. We also have a huge banking -- online banking system in Brazil. Most transactions are online transactions using Internet, computers, cell phones, so they do have a really good job in protecting the domain database from automating scanning tools. And we came to a point that we already have special access to the database within the law enforcement agencies, so that's one good point I would also like to mention, and of course every recommendations that lead us to, you know, making Internet a safer place should be approved and that's why we are starting to cooperate more and participate more on these ICANN discussions, so we have been talking with our GAC representative, our GAC delegates, with our Brazilian registry authority, and it's all a matter of having some more transparency and accountability in our domain names database. So if -- it also happens in our country code top-level domains, why shouldn't it also happen with the global domains. That's what we are trying to have. And that's basically what I would like to mention from the Brazilian perspective, so just about cooperation and have good tools for having the information when needed. Thanks. >>CHRIS DISSPAIN: Thank you. I think that we -- obviously questions and comments from the floor, if you've got anything that you want to say. Martin, you're heading to the microphone. I have a -- a question or a comment or whatever. I think this dialogue is really important and it's important for ccTLDs in their own country, but it's also good that we can have it, you know, internationally. One of the things that I find is that it's difficult to have conversations with people about cybersecurity because we don't always use the same language. So for example, when you talk to the public about cybersecurity, they immediately think you're talking about the World Wide Web. Their immediate response is -- because that's the thing that they do all the time. It's the World Wide Web. Whereas, in fact, a lot of the time, for example, the challenges might be on peer-to-peer networks, which -- so for us, I think getting language right is important in having our discussions, because I think that makes a difference because then at least we know what we're talking about. So the concept, for example -- and I'm -- this is a personal comment as an Australian -- there is currently a push in Australia from our government to introduce a filtering protocol on -- on the net, and the main justification for that is for -- is that it will have an effect -- it will -- child pornography is the thing that is used as the flag, et cetera. And that's all perfectly valid, but of course it doesn't necessarily solve the problem. And so I think a useful cooperation between the technical community and the law enforcement people would actually be to educate, perhaps, some of our politicians about the truth of these things. I don't expect you to comment. I understand that might be difficult. Martin. >>MARTIN BOYLE: Thanks. Martin Boyle from dot UK. And I would echo Paul's comments about the importance of working very closely with the stakeholders on a national framework. I think that actually is almost the key to making sure that we can respond quickly and effectively to things that happen. And I suspect that as you go around to the different ccTLDs, the balance that you'll get in the different ccTLDs will be in a different place. But as you were talking, Paul, you -- you hit two sort of buttons for me that sort of left me thinking I'm not quite sure that that is necessarily going to be the most constructive approach, and I think Chris was touching on that as -- in his introduction there. The two things were, firstly, you were talking about making sure that you get accurate data, and certainly I would agree with you if you're collecting a database you want to have accurate data. But I'm also aware that you can spend an awful lot of time going around and trying to get data that appears to be accurate and all you do is have a very, very big impact on essentially the good and the legitimate guys who have to provide a lot more information and meanwhile the crooks will still provide you with very false data. And in fact, one example I have from my government days was in a non- dot UK registry where somebody had managed to get a hotel name dot -- the name of the registry. They had provided the WHOIS data based on the main hotel. Everything on the Web site looked like that hotel, and actually much more important was being able to respond exceptionally quickly to the fact that you have had something happen. If you spend a lot of time checking that through, how much -- how much detail are you having in your mind that you would need to drill down to get the sort of level of accuracy that you think actually might vaguely help your cause. And the other point -- and you mentioned it fairly early in your presentation -- was you made reference to proxy servers, and I'm hoping I misinterpreted you, but it actually sounded to me like you were almost encouraging the proxy server, and I think this is actually also then related to the accuracy data as well, because as soon as you start checking people, more people are going to use proxies, good and many of them bad, to hide their data from you. Making our job more difficult and diverting resources that we might put in from things that might actually be more beneficial. >>PAUL HOARE: Thanks for that. A couple interesting points Martin raises. Yes, it is going to be onerous to collect more accurate data, but knowing your customer is not a new phenomenon within commerce or even with online business. It's the regular model for most online businesses to actually know who your customers are, or make some checks who your customers are. I'm not sure that registrars do -- or, I mean, there are very good registrars who do a lot of that, but there are some who don't do any, who don't do any of it. And they're the ones that we have problems with. Now, what we -- what we really don't want -- we want to avoid is putting a huge onus on exactly that. Making it -- having sledgehammers to crack a nut. But we've got to have some kind of accurate detail within the WHOIS, or whoever system we actually end up with for actually registrant details. Crooks will use false data without a doubt, but it would be nice if they had to actually make some effort to do that, and that -- and if you -- if we then discovered that a criminal was using false data and told every registrar in the world that that was false, that they would remove that domain on the basis of it being false data, rather than having us to have it go through the international protocols and the international crime agreements which we currently have to negotiate to get anything done. Adrian's already alluded to it. At the moment, we have a system where you can -- you can actually register a domain within a few minutes and then have it taken down two weeks later on after the complaint. The way that works -- Rod will back me up on this -- certainly if you have -- if it takes a day to take a domain down, if you register 365 domains, you've got a year's worth of connectivity. The current -- I understand the point you make about accurate data and how difficult it is to do, but I think we need to find a work-around for it somewhere, and find a balance between getting the accuracy and not making it putting people out of business to do that. >>MARTIN BOYLE: Can I interrupt quickly on that one? >>PAUL HOARE: Of course you can. >>MARTIN BOYLE: As far as for us, as soon as you can show that the data is wrong, it does allow us immediately to suppress the domain name. >>PAUL HOARE: I know. And we work very closely with you and I'm very grateful of that, but that's not the model that's in place across the whole world. >>CHRIS DISSPAIN: Can I just -- let me stop you one second. I've got no problem carrying on, but just want to make sure that everybody knows that we're going to be out of time very soon. I want to get to Nigel without having to say to Nigel "shortly," and Hilde, so if we can -- >>NIGEL ROBERTS: As often happens. >>CHRIS DISSPAIN: So finish what you were saying and then we'll get back to them. >>PAUL HOARE: I just wanted to clarify the proxy service as well. What we're saying at the moment is -- within our recommendations is that proxy servers serve a useful purpose for people who need to actually maintain privacy. At the moment, we've got a situation where some proxy services are effectively proxies themselves and are completely untraceable, so for law enforcement to actually, even through the legal process which is available to us, we can't actually find the proxy service, let alone the actual people who are registering through the proxy service. So what we're saying is that you should have proxy service but they should be accredited. They should be accredited proxy services, so we know where they are. >>CHRIS DISSPAIN: Nigel. >>NIGEL ROBERTS: Thank you. My name is Nigel Roberts. I'm director of the Channel Islands registry. This is a subject that we've look at for a year or so. Had some conversations with various people in the past. What I'm very pleased to see is words like "privacy" and "due process" coming out of the conversation today. Clearly, there has been a rational debate going on within the law enforcement community as opposed to the perception sometimes, as Chris referred to, as the child abuse thing being used as the stick to grab powers. The difficulty for a registry is liability. If we get a -- just a line saying, "This domain is bad, take it down" and we just take it down and it turns out to be some poor innocent person, there's been some mistake, all the exemption clauses in our contracts aside -- and we have an exemption clause that limits our liability -- but all that aside, if we take somebody down and they lose a day's worth of trading or whatever it is, they are going to look to us or whoever is responsible for that and so on. And the second point I was going to make comes out of the discussion about proxy services. The desire to do good is very understandable, but for years and years in old jurisdictions like the Channel Islands and like the United Kingdom have made a name out of lawyers and some providing trust services. A proxy service is simply a trust over a domain. Providing you can make the person who appears on the face of the register responsible for the use of the domain, and you can get to that, it's no different from somebody putting their entire wealth in the hands of a London lawyer. The difficulty, of course, is when you can't trace them and when you can't find them. And that might be something that's worth addressing. I'm looking forward to talking to you about this offline. >>PAUL HOARE: The liability point is really important actually. And I think everybody who actually requests a domain name takedown has to be very aware of what basis they're actually asking for that to be done and has to be willing to take some of the liability on for actually requesting that. There's got to be a basis for actually taking that down. Certainly you won't get law enforcement -- or shouldn't get law enforcement asking for that to happen without, certainly within the EU, the considerations of VCHR and the actual justifications for doing such work. My Belgium colleague made a point earlier in the week, which resonated with me was what's the liability for not taking a domain down when you're actually requested to take one down and it is indicated to you that it is a criminal domain and you don't take it down and criminality continues as a result of that decision? That's just a talking point which I think we might cover. >>CHRIS DISSPAIN: That's a very interesting question, actually. Hilde? >>HILDE THUNEM: Hilde Thunem from the dot no registry. You have already made the point that ccTLDs are different. And for most of us, we will be operating within our local jurisdictions where there is a local balance between the privacy and law enforcement and, of course, we will have to follow that. I do find it interesting to see the sort of global input that you're providing to the registrar agreement for the generic domains. But I do wonder, have you -- when you are talking about WHOIS security thought about what is a relevant accuracy as compared to, for example, the accuracy in the citizen database in the country, which isn't always accurate, or the car registry accuracy in the country because I'm a firm believer that domain names are not magic and that there is sort of no special magic stick we can wave that makes it more accurate than what happens in the offline world. My other question is: When you're considering the sort of global takedown policy and global WHOIS transfer policy and other things, have you been talking to -- well, I won't say the closest we get to global policy on the privacy issues, but at least the EU have working groups on privacy. And do they support your initiative? >>PAUL HOARE: A couple of points there. I think we accept there is no silver bullet. You are not going to get 100% accuracy on anything you actually want. But I think you've got to make more effort to actually obtain any kind of accuracy around the data. And then you have got to remove material which we would do from normal databases or we would challenge the car registration database. If that's in correct, there would be a challenge brought out as to the actual registration detail when you could deregister vehicles on the basis of that. And, yes, we have been very closely involved with the EU. Certainly, the RAA working group panel that was up here yesterday included somebody from the commission; and they've been working through the data protection issues which are probably as onerous as anywhere. So I think if the EU is supportive, we are pretty much safe. >>CHRIS DISSPAIN: Byron, last one and then we need to close up. >>BYRON HOLLAND: Just a comment and hopefully a couple of quick questions. Validating data, I mean, this is a real challenge operationally. And my concern is it is kind of the issue that's a classic policy issue. Who would disagree with valid data? Nobody. Down on the ground in the trenches where you are trying to do it, it is a fairly expensive thing to do, particularly when you have registrations that are all multi-year. As we probably all recognize, the quality of the information degrades. There is a very significant degradation rate on the quality of the data over time. We are in a project right now to try to make our data better. And in the Canadian context, there is lots of firms that will do that for you. It is 3 to $4 per. So we have 1.4 million domains. You can do math. It is a non-trivial exercise. I'm sure it wouldn't be that different from any of the registries in here. Our registrars down below us don't really even often have the facility to do that. You are talking about really requiring them potentially to change their business processes as well as the cost associated with doing it. So just a comment that it's not a trivial endeavor. Nobody is against good data. But when you actually have to do it, it is expensive. Two other things. I guess what I'm wondering -- I come from Canada. We have quite a robust privacy regime. That's the context we work in. One of the questions I would have for you is why would you believe there shouldn't be some sort of judicial oversight when you're requiring what we have as private data, a basic warrant or something that in our context -- and certainly a number of others here would be a fairly streamlined process. Why isn't that an acceptable situation to you? That's question one. Question two, just a quick one -- I'm sorry, I have forgotten your name from Brazil, you mentioned you want global access. Challenge for me, if I interpret that right, is it would be tough enough for me to provide that type of thing without any judicial oversight to my Canadian law enforcement folks. It would be a really tough conversation to say, "And you know what, I want to be able to give it to any law enforcement from anywhere." I mean, to be honest, I think that's a non-starter. So did I interpret you right? And if I did, what's the comment on that? >>CHRIS DISSPAIN: We need to be quick. >>MARCOS VINICIUS LIMA: Just to clarify things, I was just saying that we have problems with the generic top-level domains. So what we are trying to do is have the good cases within the country code registry to be followed with the generic top-level domain. So that doesn't necessarily mean we are going to simply give information across borders, across countries without the legal process or whatever. Just a matter of having accurate and public WHOIS information which differs a lot from country to country, from registry to registry. And I know it's complicated. So that's why we're starting to be more representative inside ICANN to talk with you, with GAC representatives and every group that's working inside ICANN. And we are open to hear you, to talk about these issues. But I didn't mean we are going simply to deliver information to every law enforcement agency or whoever asks for it. It is just a matter of having a public, accessible and accurate WHOIS database. >>CHRIS DISSPAIN: Okay. Thank you. Last comment coming from you, Paul? >>PAUL HOARE: I think when you talk about global law enforcement, access to global law enforcement, before we get into whether you should hand it over to global law enforcement, I would imagine one of the problems you all have is when you get an e-mail or a phone call, you think, Is this law enforcement? And how do I validate the fact that this is actually a cop from somewhere else in the world? This is one of the issues which we all very much are aware of. Working with Interpol and Europol to try and find some solutions to that so that we can share with industry so we have got a trusted database so you can actually reassure yourself who you are actually speaking to is a judicial law enforcement body from that -- from whichever jurisdiction. The warrant thing, certainly -- if it was just -- if all my problems were in the U.K. and I had to go and get a production order or a warrant from the U.K., it may take me an hour or so to go and do that, or a couple of hours to do it, but I could do it. Since -- point in case, when you went to just purely judicial, what it means for me as a U.K. law enforcement officer is not a case of getting a warrant. It is a case of going to the Crown Prosecution Service. I don't want to bore you with the problems of law enforcement. It means going to the Crown Prosecution Service, write an international letter requesting the Canadian authorities to issue a warrant to obtain that data. That has to go -- that takes some time. It goes across the Atlantic. It gets signed. The warrant gets taken. That data comes back. It can be several months for that to happen. When it actually happens, what the first thing that comes out is a question about something else. So we then go and get another letter. >>CHRIS DISSPAIN: Paul, sorry. I understand that completely. But isn't that what you have to do for all data? >>PAUL HOARE: So for data -- for other types of data, there are protocols in place that you don't have to do it? >>PAUL HOARE: Depends entirely on the country and the industry. Certainly, within the U.K. secret Service, or the U.S. asks a U.K. company for data, if the U.K. company is willing to provide it, then there is no need for judicial process. We can go and get it and hand it off. >>CHRIS DISSPAIN: Yes. But if they are willing to provide it -- if their advice is they can't provide it unless there is a process, then there is that process. >>PAUL HOARE: Generally. Certainly, within the EU, and I think globally, it's recognized that if law enforcement requires such material for the investigation or detection of crime, then there is a caveat certainly within the EU data protection which allows it to be -- >>CHRIS DISSPAIN: I understand. This is a fascinating discussion, and it affects us all, and we need to continue to have this discussion. It is very important. It occurs to me, for example, it is actually not -- it may not actually be possible to simply refer to law enforcement -- do you mean anywhere? Do you mean any law enforcement agency in any country? Or do you mean only the law enforcement agencies that we like or approve of or we think come from democratic countries? Do you mean crime in their country, which might actually be persecution in our country? These are the sort of topics we need to get on to. >>PAUL HOARE: This is why we've made these recommendations completely crime neutral. >>CHRIS DISSPAIN: Absolutely. I understand. >>PAUL HOARE: They're not about crime. They're not about the nature of crime, the nature of what's actually happened. It is about accurate registration details. >>CHRIS DISSPAIN: Absolutely. >>PAUL HOARE: In Interpol, there are issues about political crimes and things that aren't agreed across the world. Interpol will work through. They won't take action on anything that's politically motivated. >>CHRIS DISSPAIN: Sure. All right. Well, thank you. Can I ask you to join me in thanking the three gentlemen of the law. [Applause] Okay. It's lunchtime you will be delighted to hear. I have no idea where the Panoramic Hall is but that's where lunch is. Do we know what floor it's on? Five? It is on five. Okay. So the panel -- hold on. The Panoramic Hall on the fifth floor. Gabi has 100 tickets. Pardon? I'm sorry. Can I get you to sit down. I apologize. We are -- we are not early but Afilias, of course, needs to do their presentation before we go to lunch. That's the deal. We all know that. And, actually, if I check my agenda, it quite clearly says that Afilias will be doing their presentation. But, of course, we're in an Afilias-free zone at the moment. Sorry, Roland. We go straight to the GAC after lunch. So while Roland is setting up, can I have your attention? After lunch, we are meeting with the GAC. Their room is on the fourth floor. I have no idea what number it is. It's 400. Thank you, Roland. So, guys, we are meeting with the GAC after lunch at 2:15 in Room 400. And one of the things we're going to be talking about is delegation and redelegation working group. Now the delegation/redelegation working group has published a report which we will be discussing amongst ourselves later on this afternoon. One of the things we will be doing with the GAC is going through the methodology that has been used to write this report. It would be helpful if we did not have to go through it again when we meet on this ourselves at 4:30. So if you could come to the GAC so that you have listened to the methodology presentation, that will give us more time later on this afternoon to talk about the meaty stuff rather than trying to explain to you how we put this report together. Okay? Right. So, Roland, thank you. >>ROLAND LaPLANTE: There we go. Thank you very much, Chris. It is a great pleasure to be here. I will be very speedy today because I know you guys all want to get to lunch. So I want to just talk about a couple of things. By way of introduction, Afilias supports 15 TLDs today with about 16 million total registrations. This is the list. We also support IDNs. I know many of you are wrestling with the issue of iTLDs, IDN versions of your TLDs. If you are thinking of setting up separate registries systems for those, Afilias can help with our core registry services. But the thing I wanted to talk about for two minutes now is DNSSEC. It is coming, it is big, and we have an idea on how you can help protect your TLD during this transition. DNSSEC is at the tipping point. There has been a lot of discussion here. There was a lot of in Nairobi. DNSSEC is definitely coming. A lot of TLDs have already signed. Org is going to sign second levels very soon. The root is going to be signed in July. All the new TLDs will be required to have DNSSEC, and we are already supporting DNSSEC for many of them. And we are doing it for SE as a secondary provider. DNSSEC is big, and I say that for three reasons. It will result in a larger zone file size for you. It will include greater bandwidth requirements, and you're going to get some more traffic as well. The zone file increases will be -- are estimated to be four to six times among those who have already implemented DNSSEC. And that's going to require you to have more space available for your zone file. There will also be bandwidth increase requirements. DNSSEC responses contain a lot more information. And as a result, the response is about eight times bigger than a normal response. So that's going to take more bandwidth to send those back and forth. The extra bandwidth requirement based on our experience with dot org and so forth is about two to four times what it currently is. There will also likely to be traffic increases. There will be more TCP queries because DNS uses a UDP, and you may need to resend these queries in responses several times until you get the entirety of the DNSSEC response because the DNSSEC response is larger. So there will be about a 1 to 2% -- or up to a 1 to 2% in TCP traffic. About half of the traffic that Afilias is supporting today through our name servers request DNSSEC information. So that means as soon as you sign, you're going to start getting these queries. And so you need to be ready for the increases in load. One possible solution to this is to consider secondary -- hiring a secondary DNS provider. You already have your own primary DNS already. This would reduce the risk of load increases from the DNSSEC deployment by enabling you to effortlessly handle significant increases due to DNSSEC. It is also an economical and risk-free way to boost up your capacity. It will guarantee -- provide additional guarantees for your up time even regardless of DNSSEC and it is a way to augment your existing DNSSEC network. We offer such -- secondary DNS services in addition to the primary DNS services and the registry services that we offer. And we have a special offer for this year for 2010. For ccTLDs who are deploying DNSSEC in 2010, we are offering 45 days of free secondary DNSSEC support or free DNS support for you as a contribution to the community and also obviously as a way to enable you to sample our DNS service and potentially sign on with us for a longer period of time. So it is my great pleasure to host your lunch, again, in this session. Thank you for the time, Chris. Thank you very much for your kind attention. >>CHRIS DISSPAIN: Roland, thank you. You know, you guys have been great because you keep coming back bizarrely and you keep buying us lunch. Thank you. [Applause] Okay, Gabi has tickets. Gabi only has 100 tickets. No arguments. No fights. There are 100 tickets. (Lunch break) >>CHRIS DISSPAIN: Welcome back, everybody. If you could please start taking your seats, we are going to start again. Thank you. Obviously a number of people are still trying to find their way back from the GAC room, which appears to be in another universe. So welcome back, everybody. We've got a couple of short sessions now. The first is a report from the wildcard study group, their final report, which Ondrej and Young-Eum will provide, and then we have a report from Jörg on the incident response plan working group, and then we move to our final session for the day, which is the delegation, redelegation working group which will obviously carry on the discussions that we started in the GAC just before coffee. So are you ready, guys? Okay. Who is running this Ondrej or Young- Eum? >>ONDREJ FILIP: Yeah, I will start. >>CHRIS DISSPAIN: Okay. Ondrej, thanks. >>ONDREJ FILIP: My name is Ondrej Filip and this is Young-Eum Lee. We are the co-chairs of wildcard study group. I'm representing dot cz registry and Young-Eum is from dot kr. We would like to very briefly report about our work and our work, I think, is going to be over and we are close to submitting a final report. So what happened so far since our last meeting? We made our draft report. It was sent to the mailing list, to the membership, and so far we got two comments and those were very valuable, so thank you -- thanks to the people who sent that. But now what's included in the report? So what will be this presentation about, first, so I'll briefly mention what was the scope of our study group. It's quite important to understand what are the outputs, because we were not the normal working group. We were a study group and our scope was quite limited. Then we will briefly elaborate on the fact that we came to some difficulties about really understanding what is wildcarding and what does it mean. Then Young-Eum will go through some individual cases. She will mention about the methods of identification, what we did, and she will also show you the list of harms we identified in our study, and then she will also mention some recommendations we would like to send to the ccNSO council. So we'll go a little bit more quicker through the slides than usual, but we have just basically 10 minutes for presentation, so if you need some details, please download the presentation and look at it off line. So, first of all, the scope of the working group. We were to summarize the issues that were associated with the redirection as identified by SSAC report. We should liaise with SSAC to seek further clarification and input if considered needed and appropriate by the group. Liaise with stability, security, and resiliency department of ICANN to seek further clarification and input if considered needed and appropriate by the group. Liaise with the ccTLDs who are currently using redirection to solicit their views and perspective on redirection. That was one of the major parts of our work, actually. Prepare a session at the ccNSO meeting, either at the ICANN meeting in Nairobi or Brussels, and discuss the results of the study group to the ccTLD community. That's what we are doing now. And provide a final report of its findings to the ccNSO council. So that would be the future step. So what were actually the activities? As I described earlier, we summarize the independent findings, we compared SSAC and ICANN staff harms list, provided some short description on each harm. We reviewed types of redirection. We assessed redirection results and then met the cc's according to the harms list. We took, for the word "wildcarding" we took a definition from RFC 1034, and so far we identified about 11 ccTLDs that are involved in the redirection in the wildcarding. One of the, I think, very good and nice outputs of our work is the fact that at the end of our -- of today, four of those ccTLDs stopped using wildcarding, so I think that's great work and it shows that just entering a dialogue helped a lot and we clarified a lot of things among us. So that that's one of the really greatest outputs of this working group. But as I said, we have some problems what we really define as wildcarding, because there could be several behaviors that are not exactly the wildcard in the sense of the RFC 1034, but there could be the behavior also have some sense of wildcarding, so what we explored depends on the technical test you performed on ccTLDs. You can get different results. So the very easy way is just to query for asterisk, dot, and a specific TLD. We got about nine -- or today you would get about nine ccTLDs that looks that are doing wildcarding, but on the other hand, if you just put some random string and dot TLD, some string that probably can be registered, then the result is just seven of them. It's minus dot CN and dot TW. What is the reason? The reason is that those TLDs do not just have -- they do not wildcard everything but they just concentrate on xn-- strings, so that means they do wildcarding just for IDN strings, probably. But if you make a test that you try to query xn-- random string dot TLD, you will find that there are 10 ccTLDs currently involved in wildcarding, and one more is the dot MP which doesn't include dot TLD in the string but they do some sort of wildcarding. So that's one of the findings we found and that means in the definition of wildcarding can be quite broad and it's not exactly clear what does it mean. And that's the end of my part and I will pass the mic to Young-Eum. She will go through the individual cases. >>YOUNG EUM LEE: Thank you, Ondrej. I would also like to express our thanks to the members of the working group, and especially Kathryn, who was very heavily involved in the final -- in coming up with the final draft that's on the Web site, and we would like to encourage you to go to the Web site and download the document for details because we're not going to have time to go over each fact. So there were four cc's that gave us reasons -- or gave us their position on wildcarding. There were two that were still involved in wildcarding, and expressed -- explicitly expressed the desirability, so to speak, of wildcarding, or the usefulness of wildcarding, in order for them to serve their users. That was dot VN and dot PH. And as for the specific arguments, I would, again, encourage you to go to the Web site and download the final report, or the draft final report, and we will come up with a final report after this. And there was dot NU, who had stopped wildcarding, but also stated that the standards of IETF and the SSAC were not in tune, and so asked for clarification. There was one that stated that it was doing some sort of redirection because of the necessity to provide IDN dot KR services, and that was dot KR. And so based on Ondrej's demonstration of the different lists that we come up with when we use the different methods, we decided that we don't -- that we do not have a final list. That the initial list of 11 cc's were given to us by IANA, and even that was not comprehensive. So we termed this as an anecdotal list of harms, and so this -- we looked at the behaviors of seven of these cc's and some come out with page not found, some come out with adds, some come out with the -- tell you that the domain may be available. And so what we did was based on the list of the harms that were identified by the SSAC and the ICANN staff that was the list that was presented earlier in this presentation, we tried to see which of the cc's -- which behaviors of the cc's applied to which, and we found that -- and this exercise was done by Kathryn and Rungang Mo, I understand, and we thank them for that, and it was found that some of these would apply to all cc's involved in wildcarding, and some of these behaviors would be dependent on what their registration policies were and so on. And some of these would also apply to certain cc's that were more heavily involved in additional wildcarding activities. And so we came up with this mapping exercise. The specific mapping mechanism is also included in the final report. And so we came up with three recommendations. The first one, dialogue. We asked each cc that we were given -- of the list of the 11 cc's that we were given, we asked them what their reasons were for wildcarding, and during that process it was found that four of the cc's stopped. And we also learned that for some cc's, it was necessary. Some cc's actually had gone through the -- sort of the proper consultation process and had a different opinion. And so we realized that a dialogue with the cc's is very important. But that we felt that it would only succeed if judgment on the reasons for use is suspended. So although we use the word "harms" and we don't mean to use it in a really negative way, we just used it -- used that word because that was the word used by the SSAC and the ICANN staff. And so we are not making any judgments. We are trying to -- or we were trying to engage in dialogue. And the second point is that we really need a clear identification of what wildcarding is, and how to identify these cc's that are involved in wildcarding. And so -- so that we can come up with a more comprehensive list. And then after that mapping exercise, it was felt that the different harms were exhibited by different cc's, depending on the manner in which the registries used redirection, and without making a judgment on the desirability or the undesirability of each, we would like to recommend that the council consider determining which harms or behaviors are less harmful, was the wording that was suggested by Patricio, because "harms" is not desirable in any way. But, I mean, even given that, we are not making a judgment but basically we would like to recommend that the list -- that we differentiate between items in the list as to which is more involved in wildcarding and which is less, basically. And that's it. Ondrej, would you like to add? >>ONDREJ FILIP: No. That's all. Thank you. >>CHRIS DISSPAIN: Okay. Are there any questions or comments on the report, which will go to -- formally go to the council tomorrow, and the council may immediately do something or may need to think about it or whatever, but the report will go to the council tomorrow, so it's on our agenda. If there are no -- here on. I'm so sorry, heat on. >>HIRO HOTTA: So congratulations on the intensive study report. I see for each ccTLD who does wildcarding, as far as the study group identified, the reason for using wildcards is reported. So my question is: Did the study group study on how essential the wildcarding is or was in such ccTLDs for their core services as a registry. Here "essential" means, for example, necessary and having no alternative ways to do that. Such a study may help us to understand the balance between necessity and harm of the wildcarding. If such study hasn't yet been done, it should be clarified through more dialogues recommended in the report. The last part is my comment. Thank you. >>ONDREJ FILIP: Thank you for that comment. Basically, there's a list of all individual ccTLDs and their reasons why they used -- why they were using wildcarding, and basically there are just two reasons that we found. There are some technical reasons and they are usually tied with IDN, and, for example, Korea is a good example because the Korean registry declared that they will stop using it when the final technical solution is done on the Web browser side, for example. And there are some ccTLDs that make it mainly for -- for commercial reasons, which is, for example, the PHN, and they probably would like to continue with that. >>YOUNG EUM LEE: I would also like to add that, I mean -- thank you, Hiro. And I would also like to add that that criteria could be one of the items that we may use to differentiate between the list of items here, so it would actually help us further specify or, I mean, get more detailed about the differences between the items in the list and that would be a very good criterion to use. Thank you. >>CHRIS DISSPAIN: Anybody else? Okay. Well, Ondrej, Young-Eum, thank you very much, and as I said, the council will take the report tomorrow and we'll see what happens next. Thank you. Jörg, would you like to come up and do the incident response working group. >>JÖRG SCHWEIGER: There we go. So thanks, Chris, for the introduction. It's my pleasure to give you an update on the progress that has been made by the incident response working group and just in case you can't recall, I would like to, in the first place, acquaint you once again with our purpose. So our charter says that we are about to implement mechanisms for the engagement of and the interaction with ccTLDs and registries during incidents that may impact the DNS. And as that, to the scope of the group would be to set up a repository of contacts and cording channels of communication. So as to this, we set up the following work plan that has been laid out in Nairobi, and the first issue was to define what is supposed to be considered an incident for this working group. Well, we did so and came up with the following definition, what is supposed to be an incident for this working group. And that is a large-scale, unintended misfunction of the DNS or a systematic rigorous preparation of or actual attack on the availability of both DNS and registration systems; on the data integrity or privacy of both of those systems; or the stability and security of the Internet at large where there is a coordinated international response by operators and supporting organizations advised. So this is probably something interesting as I would like to remind you that this definitely does not include that we take a closer look at malicious use of the Internet itself, for example, so we are not concerned with spam. We're not concerned with unlawful use or misuse of specific domains or content. And we do not care about any routing problems. So once we do know what is supposed to be an incident, we had to define use cases of the envisioned contact repository. We did that as well, and basically the list of the use cases does look like that, and you just could title them in two different categories. One would be information exchange, so a scenario for the use of the contact repository would be to provide a security contact point under any circumstances, and we would want to issue early warnings. Second category would be counteraction, and over here we see a scenario or use case that we would like to inform participating community about an incident and that we would facilitate or enable the community support for a member of such community. And once again, let me point out what has been dismissed, because these use cases got a tendency to be very narrow, as I feel, so there actually had been discussions like we wanted to generate reports on prevention, best practices, and we would store, compile, and give access to mitigation lessons learned but we leave that to, well, at least a second version of the contact repository. We don't even feel that we would provide generic action plans and we for sure would have to reflect that in the charter because that is one point that has been said in the charter. And finally, we don't see how we could, by just such a repository, come up with anything that could coordinate responses with just the plain repository. So this point 3 of the work plan is probably just not going to take place. Task 4. So once we came up with the use cases for such a contact repository, then we could easily define a data model or at least an attribute list according to such use cases for a contract repository while over here you see the very first version of this attribute list, and in the darker gray part you see the information that gives some aspects of organizational concerns. In the lighter gray shadowed part, you see in black some information about the contact person itself, be it the first incidence response contact or be it a substitute that should also be named within the contact repository, and written down in green actually is the real contact channel of information we do envision to be integrated in this contact repository. Well, finally, we didn't come to terms and it wasn't as planned as well that we already know who is going to implement, who is going to run and maintain such a repository, so this work still has to be done, as well as getting clear about at what expenditure this is going to be covered and who is going to do it. So finally, further discussions that had been going on in the working group is we were concerned with who is entitled to access such a repository anyway, and I would like to point out that we came up with the impression that it should not only be accessed by ccTLD members, but by TLDs in general, and not only them but DNS operators and registry operators as well. Concerning the tools one might envision that probably would be associated with such a repository, we have been discussing quite a number of functions that we could envision. Even something like Twittering information or Web 2.0 functionality, so where you can get into trusted contact to somebody else who you do not know personally but somebody else knows, so I think you're quite familiar with that kind of functionality. So we have been discussing that, and we left it open to probably a second version, but basically come to terms that we do not want to provide anything that exceeds the mailing list so far. Last point is what also has been raised in Nairobi was that there has to be a clarification on the relation or the delineation of the incidence response working group with respect to organizations that already do exist and that are more or less obliged with related or similar tasks, and over here at least concerning the envisioned DNS CERT, there has been some action, and that was that after the Nairobi meeting, the charter of the working group was amended in such a way that the working group should only include, as it says, aspects and relations with ICANN's DNS CERT initiative it considers relevant, and that we would seek input and feedback from you, the community, and try to coordinate this input towards the DNS initiative. Well, it took a while to amend the charter, and basically what has happened was that we were kind of overtaken, so there already had been -- in the progress of the Nairobi meeting -- substantial commenting on the DNS CERT initiative anyway. So at this point in time, I just do not believe that it is necessary to further comment on anything that has been proposed so far. So what are we going to do with the amended charter and how are we going to cope? So the plan is that if ICANN will initiate steps for the bottom-up multistakeholder approach to ensure DNS security and stability, and that for sure was what was envisioned, for example, by the ccNSO and others, then in that case, this working group would gather comments from you, from the community, and would relay that to, well, probably the envisioned working group Chris has been talking about this morning that is on its way as a joint action from the NSOs and probably another way of conduct would be that we might even participate in a joint approach how to move on with the DNS CERT initiative. So that's basically what's planned for the upcoming days of the working group. >>CHRIS DISSPAIN: Fantastic. Thank you very much. Great piece of work. Any comments or questions for Jörg? Okay. Thank you very much, Jörg. That's brilliant. Thank you. Marvelous. Okay. So we're going to move on now to the last session for the day, which is delegation redelegation retirement working group. Bernie. Keith. If you will please join me. And Bart. And Bart, just in case -- Bart's leg is stuck under the chair or something, clearly, judging by the noises he is making. So the idea of this session is that -- can I just get an idea how many of you were in the GAC room with us a while ago. Pretty much? A lot? So thank you. So for those that weren't, we went through a slide show for the GAC that talks about this working group's progress report and the big report that we've published. And we're going to do that -- do some more of that now and, hopefully, have a discussion on -- perhaps in a bit more depth than we did with the GAC. And, Keith, over to you. >>KEITH DAVIDSON: Thank you, Chris. I will spend a bit of time and bit more detail of some of the aspects of the progress of the working group here, but I really don't want to be too repetitive in terms of covering the same ground twice. So I hope everyone was in the GAC session and that we might be able to get through some aspects of this a little bit more rapidly. And just in general terms, again, I'll walk through the progress of the working group and then hand over to Bernie to walk us through some considerably more examples of some of the findings of the working group and their analysis and so on. Okay. In terms of members of the working group, it is a very large working group. I don't intend to go through the entire list of names, but there are representatives from -- throughout the ccNSO community. There are some members of the Government Advisory Committee, and there are some expert advisors from ICANN and elsewhere and quite a number of ICANN staff supporters. And this presentation will be online, if it isn't already. So if you have some questions, feel free to tickle your local or close-by member of this working group to raise any questions or issues with them or with me or Bernie or Bart or Chris. Okay. The document that we've released is the draft issues document, and it's made up of three main parts: The public consultation questions, a methodology to evaluate what we see as potentially interesting cases, and the analysis of 16 interesting cases. The methodology was -- or the questions that we would like answers on and submissions from you on between now and the 15th of September are the following: The first is the reality check. Is the methodology developed and deployed adequate for the purposes of the working group? Do the policy statements identified provide adequate baseline to evaluate the actual practices of IANA and the ICANN board relative to delegation and redelegation and retirement of ccTLDs? And are there other policy statements which are applicable for the work of the delegation/redelegation working group? Should they be included in the baseline? Now, the sorts of things that could come up there, there are some earlier RFCs like RFC 920 -- sorry, 980 and 1020 that refer to registrations of top-level domains and so on. We're also -- we've put out a call in the past and will continue to call for any documentation on any delegation or redelegation of a country code that occurred prior to the formation of ICANN in 1998. We haven't been able to uncover any of that documentation. So if you know of somebody who may have a newly delegation e-mail from Jon Postel or something like that, we would really appreciate receiving a copy. And if you have any other indications of policies that you think this working group should take into account, please let us know. Does the documentation identified provide an adequate representation of actual practices by IANA and the ICANN board relative to the delegation, redelegation and retirement of ccTLDs? Should other cases be included for analysis? Is there other documentation which is applicable to the work of the working group which should be analyzed? And so we have this open period. The documentation is all online, and the consultation is scheduled to close on 15 September to allow us time to consider the submissions and incorporate them into a report going forward to the ICANN meeting in December. And on to the methodology, and I will hand over to Bernie. Thanks. >>BERNARD TURCOTTE: I think I will move over here. Hi, folks. Yes, it's me. All right. Methodology, just to recap on the history, if you missed it, we did go through every single IANA report in detail, every single sponsorship agreement, MOU and all the annexes and all the board decisions that referred to ccTLDs. We sort of did an initial sort into "pretty straightforward," "nothing to go with it," "here are a couple of issues." We took those, and we started looking at them and then developed a methodology for analyzing certain aspects relative to existing policy frameworks to see if they matched up because that's an easy call. I mean, if you define the framework properly, you have a look at it, either they met the requirements or they didn't. It doesn't mean it is the only thing we're looking at in the scope of the working group. But this one is, I guess, what we could call low-lying fruit. It is fairly easy to come up with an empirical revision of what's happening. Once we finish developing the methodology against a certain number of cases, we then went through that second set of cases and sort of relooked at them and looked at the interesting ones and came up with the 16. So what I'm going to do now is just walk you through quickly a more detailed version of the analysis process. As we said in the GAC, we really tried to keep it simple, three classes: "Significantly interesting," meaning it would strongly support the recommendation of a PDP; "interesting," may support or could support the recommendation of a PDP; and "possibly interesting," would probably not support the recommendation of a PDP. Of the 16 cases that we had selected after that, they essentially fell into two classes: The cases that were related to policy-type development, implicit or explicit -- and we'll get into that in a few minutes -- and cases which were strictly related to the application of existing policies. And when you put them together, you get a matrix of six elements. Are we good to here? Okay. Moving right along. There will be a test before you're allowed to leave, so you should pay attention. >>KEITH DAVIDSON: And I'm making notes of people with their eyes closed. >>BERNARD TURCOTTE: You don't want that. In examining the cases, the working group considered a simple way to sort of help categorize these things. We made a decision tree. Firstly, does the difference between the policy statements and the documentation or the issues that we're looking at, i.e., the board decisions suggest a change in policy applicable to the delegation/redelegation or retirement of ISO-3166-1 ccTLDs? So we're trying to keep it framed in the mandate of the working group. The board did take other decisions. We're not into that. We're into these things. And to help answer that question, we came up with four criteria: These differences identified involved in explicit or implicit board decision that concerns the delegation, redelegation or retirement of ccTLDs; the core elements of the approach reflected in the documentation appear to be inconsistent with or not addressed by an existing policy statement. If policy says you can do A and you've gone and done A and B, well, you know, you got to see how that goes. The changes will bring noticeable changes. You know, it is not a question -- it is a question of size of impact, too. I mean, if you don't follow the rules perfectly but it has no significant impact, it's probably not worth wasting all our time looking at that. So, really, there has to be a question of significant impact. The differences identified in the fourth term relate to something that could be applied broadly, i.e., involvement of an approach that is likely to have lasting value or applicability, albeit with the need for occasional updates. What we are saying here it is fairly obvious that the rule that has been passed can be applied to others, even if it requires some minor changes or adaptations. So those are the four elements of the decision tree. That is our first test, if you will, to decide if the element -- the decision element we're considering is a change in policy or not, regardless whether it's called that. We helped classify that, which is why we say "implicit or not." If the answer to all four questions is yes, the working group considered the differences to be a change in policy. If the answer is yes to the first three questions, then the working group determined that the differences probably reflected a change in policy. Other combinations are probably not a change in policy. Now, if the working group determined that the gap between the policy statements and the documentation in any particular case did reflect or probably reflected a change in policy, the working group considered whether or not the change was undertaken in accordance with applicable procedural requirements or policy changes. All right, I've read it. What does it mean? What it means -- and it's described in detail in the longer version of the report -- is that ICANN has published rules for developing policy. I mean, if you classify it as a policy, if it looks like a policy, it smells like a policy, it walks like a policy, it's probably a policy, right? And if it's a policy, there are rules that are applicable to how you define policies and make them for the ICANN board. Now, before the ccNSO, the scope -- the requirements for creating policies was a lot lighter. And we described that in detail, and I'm not going to go through that here. After the ccNSO, life changed. Life changed because there was the ccNSO, and life changed because in general the procedures for developing policies within ICANN evolved significantly. There were very clear lines marked in the sand and put into the bylaws about what it means for the ICANN board to be able to develop a policy. Where the working group identified no change of policy considered whether or not the documentation reflected an implementation of policy, i.e., the decisions we looked at, if they're clearly covered by a policy, then we have to look at, Okay, fine, but did they follow the policy that's there that covers this case? The absence of policy in an organization such as ICANN where the board of directors makes a decision that can be cited in the future, such decisions should be viewed as affecting the policy if under the circumstances the decision only applies to a single ccTLD because it sets a precedent. This is fairly standard procedure. The reality is if the board makes a decision in the context where there is no policy, it is setting policy, whether it likes it or not. Okay. So are we good up until this point? So we've got basically two major blocks we're looking at, okay? We looked at those 16 cases and said, "Is it a change in policy or is it an application of policy?" And we've got those four questions that help us answer that. The second thing, once we've answered that, whether it's an application of policy or development of policy, we look at, did they follow the rules? If it is an application of policy, well, the thing we're looking at for following the rules is, did it follow the policy? If we're looking at a development of policy, we list the various terms that are required at the time the decision was taken because you have to remember that the rules change as time goes along. At the time the decision was taken, we have a look at what the conditions are and if those conditions were met for that kind of work and decision. So what we are going to do next is we are going to go through in not excruciatingly painful details but we will go through in details the analysis of one case, what it ends up reading in the long document to give you an idea of the work that was actually done. And then after that, we'll skim through the remaining 15 cases -- there is actually 14, and that's a long story. So our first one is the same one we used with the GAC but now you're going to see we have got the next level of detail in going through it. And it's the September 25th, 2000 ISO-3166 reserved list decision. I'm not going to go through the motion. It's up there, and basically the board came up and said, "Okay, under specific circumstances we can create ccTLDs from the ISO-3166 reserved list," boom. All right. So, let's take a look at that under the framework of analysis we've defined. Under the first part, this is an explicit -- oh, sorry. This is an explicit decision by the board that concerns the delegation of ccTLDs. I mean, you will be creating a new class of ccTLDs. Allowing for a new class of ccTLDs is a significant change for ccTLDs. A decision generates noticeable change. I mean, there is a whole new class of players that can become ccTLDs. So our evaluation is that it is noticeable. The board decision is not specific to a given ccTLD. It says, "We can under a set of circumstances allow new ccTLDs from the reserved list. It is not about a specific entity. It seems to meet that test." Thank you. Getting too excited here. Look, they're captivated. Don't go into a trance yet. Come on. The last of the four questions, the core elements of this decision, were not covered by existing policies at the time of the decision. No ccTLDs from the ISO-3166-1 exceptionally reserved list had been allocated since the inception of ICP1. And, remember, we're covering the period of stuff during ICANN's reign. We're not looking at the other stuff in the context of the applicability of policies. So we have to limit ourselves to that framework. IANA has approved ccTLDs from this list in the past. However, this was prior to RFC-1591 even being in existence and ICANN. And there is some other stuff there. So, basically, the conclusion as to whether this is a change of policy or not, if you look at those four things is that this is an explicit decision by the board that meets the four criteria from the decision tree and supports the working group classifying this decision as a change in policy. All right? So that's how we work through all these cases, exactly the same way. You look at them. You will find the same logic in every case. All right. So now we picked off this one is a change in policy according to our set of criteria. All right. What are the set of rules that were in effect at the time? They were liked because this was 2000. This was before the new and more accountable ICANN and the reform came in. I mean, basically you had to tell people you were developing a policy. You had to hold a meeting and have input, and that was about all the requirements you had to have to develop a policy. So I always like to date because the set of criteria changes in time. So the policy development requirements, according to Section 3, notice and comment provisions of the bylaws in effect at the time, which basically were the same since the inception of ICANN, was, as I said, to provide public notice on the Web site, provide reasonable opportunity for parties to comment and to hold public forum at which the proposed policy would be discussed. We're not talking serious requirements here. And the evaluation is there is no record of a public consultation on the topic. There is no record of a public forum discussion on the topic. And there is no record of any communications between the board and the DNSO at the time before the ccNSO on this matter that could be considered advice. So, basically, this one is fairly easy if you're using this scheme to conclude that this policy decision failed to meet all of the requirements for policy development in effect at the time and supports the working group classifying this as significantly interesting. As I say, again, the approach, you will find this in every single case. Sometimes it's longer. In some cases, we've actually pulled out all the elements from RFC-1591, all the elements from ICP1, all the elements from the GAC principles and looked at each one and how they apply and what they mean. And so sometimes just that evaluation part can run to two or three pages of quotes and pieces that we picked up from there. But we always try to go back to the documentation that is available publicly. So that's the detailed analysis of the first case. I don't know if we've got questions on this specific one and how we use the process. I'll take that as a stunning endorsement of my kills as a presenter. Thank you. As I said, and I'm not going to spend a lot of time on this, where we thought it was useful, we added in some comments after we completed the analysis. Now, obviously, the change of allowing elements from the ISO reserved list is fairly clearly a change in policy. Yet, if you go through the document, you will notice there's never any mention that there's been a change in policy, which is sort of interesting. Even five years later, we're getting documents that are being published that say, "No, no, the only policy applicable to ccTLDs is ICP1." Anyways, I just like -- it is an interesting sideline. What I've done next is I've taken them by the three classes: "Possibly interesting," "interesting" and "significantly interesting," and I'm just listing off the cases for you. So under "possibly interesting," we've got the September 10th, 2001 AU redelegation relative to sponsorship agreements, okay? Because it came as a bit of a shock for those that were around at that time that all of a sudden you couldn't be redelegated unless you signed a sponsorship agreement. And, basically, if you run through the mechanics, given that the sponsorship agreement rule was passed, they basically followed the rules. So from a sponsorship agreement point of view, it's only possibly interesting. Similarly with the EU decision in March 2005, basically once you accept the ISO-3166-1 reserved list decision, when they did delegate dot eu, it basically followed the rules if you basically accept the fact that the reserved list decision was a policy decision. Next we go into the "interesting cases." And September 25th, 2000, which is, yes, the same date, the same ICANN board meeting where they decided on the 3166 reserved list decision, they also decided on sponsorship agreements were required for anything going forward. And this ends up being classified as "interesting" because they followed some of the rules, okay? The sponsorship agreements were basically three versions, were posted on the Web site. They were discussed at several ICANN meetings. Now, through all that traffic, if you read all the sources of public information, no one ever mentioned that sponsorship agreements would be absolutely, totally and unquestionably required for redelegation. We were just looking at potential models for an agreement. And when it came to September 25th, they said, "Ah, we have this great agreement and now you can't get a delegation or redelegation without a sponsorship agreement." So that one ends up being "interesting." September 10th, 2001, not allowing individual delegees for ccTLDs. Again for about the same reasons, because it got covered in the same backhanded way, if you read through all the versions of the draft sponsorship agreements, it's there. It's actually there. It's not really clear what it means. But once you put all the dots together, it becomes fairly clear that's what they were meaning. However, it was there. People failed to comment on it. We'll skip over the fact that public comment periods at that time, if you have negative comments -- and I know because I was at some of those meetings -- never got recorded for some reason. But we're forgetting that, okay? There's a whole period of about four years where ICANN must have been doing a great job because there was never a negative comment recorded in any public consultation. We move on to the next "interesting" case, which is July 18th, 2006, the dot gd redelegation. There starts to be some questions about Internet community support. I mean, in all the IANA documentation and everything else, it has always been a gold standard that there was an evaluation of local Internet community support when you're talking about a redelegation. And this one's got some issues, which is why it got flagged as "interesting." In November 2007, we have the dot bb redelegation where it is sort of weird but it's clearly stated in one of the official statements that the applicant did not meet the technical requirements. But the board chose to redelegate anyways, and that was a first. Again, the other criteria were met; so it got put in the middle pile, which sort of says "interesting." Before we go into the "significantly interesting," are we doing okay? Not too many people are walking out. >>KEITH DAVIDSON: Two of them nodding over there. >>BERNARD TURCOTTE: Two of them nodding. Well, they're Kiwis. [Laughter] All right. Not that long, we're into the home stretch now. We're heading into "significantly interesting" and hopefully it will be significantly interesting. All right. Let's go. May 19, '99, ICP1. Yes, we dare take on ICP1, basically, there is one part in ICP1. If you take the first statement in ICP1 that says, "There is no change in policy," all right, which was always the reason ICANN said it didn't need the board to approve it because it wasn't a change in policy. If you go through it and you actually do the homework, we're saying that's not true. There is a change of policies when it comes to the ability to redelegate. And it is fairly clear. And if you go through the analysis, I think it sort of falls out rather clearly. And it did not meet any of the requirements for policy decision. As we all know, ICP1 was simply published. And that just happened. So that gets a rating of "significantly interesting." How did that end up there? The reserved -- no. Sorry. That's a miscopy on the 3166 reserved list decision. Oh, no, what am I talking about? On ISO-3166 reserved list, we've gone through the case and we've explained to you why it ended up being significantly interesting. November 19th, 2001, the dot US redelegation ended up getting a quote of "significantly interesting" for a lot of reasons. Now, this one's a little special. There are no board decisions. There are no board minutes. And there is no IANA report. And there is no sponsorship agreement. However, we have dug up a significant amount of information on this one, and if you are interested in cc matters and wish to read a very interesting story, if you have not followed it, I would highly recommend that if you not pick anything else, you read that one. June 9th, 2004, the dot LY redelegation for Libya. All of a sudden we got a new term. We had a "provisional redelegation." Where it's not clear where that comes from, but all of a sudden we have provisional redelegations. You run it through the mechanics and it ends up being significantly interesting. July 28th, 2005, the dot KZ redelegation. What's interesting about this one is that the September 2000 -- September 25th, 2000 decision, which was a policy passed by the board that says, "Going forward, all redelegations will require the delegee to have a sponsorship agreement." So that's in effect, and this is the first decision -- five years later -- where a ccTLD is redelegated without a sponsorship agreement, and there is no mention of why, okay? It is just redelegated. And what's even more interesting is, in the board minutes, this entire discussion -- although there is no mention as to why there is no sponsorship agreement where IANA gets beaten up for still having that requirement on its Web page -- and if you go through the "way back" machine, it actually gets removed the week after. Without any notice also. So anyways, you finish going through the analysis and it's significantly interesting. January 16th, 2007, the dot UM un-delegation which is the first removal from the root of an active ISO-3166-1 code. Now, some people say, "Well, you know, no one wanted to operate it anymore." And if you're not familiar with the dot UM code, it's the Outlying Minor Islands, which is a shatelle (phonetic) of the U.S. government and has penguins on it, I think. So anyways, the penguins were not using the domain too much. No one wanted to run it. However, the reality in a policy analysis framework is that there's nothing on the books -- ICP1, RFC-1591, et cetera, et cetera -- there's nothing on the books that says we're allowed to remove a valid ISO-3166 that's been delegated from production. So it ends up being quoted like this. September 11th, 2007, the dot YU redelegation. We actually get two of those because it's two different cases. There's the redelegation part, where all of a sudden we get new terminology again that means something completely different again. We get a temporary caretaker redelegation. Nothing else to back this up anywhere else. Just sort of mentions that, you know, we're redelegating to a new manager but you can't register new names. So it's a special redelegation. So anyways, that got classified as "significantly interesting." And then there are the elements of the dot YU retirement where also if you go through the documentation there's no -- there's nothing that talks about how you retire a ccTLD that's no longer going to be on the list. And then all of a sudden not only are we talking about retiring it, but a bunch of very specific conditions about when and how it's going to be retired. So if you run it through the mill, basically it just ends up being significantly interesting. The final one, 2008, is the dot AE redelegation, and this one is really a confirmation, if you will, that, you know, there can be redelegations without any serious local Internet community support. To the point where one of the directors actually, you know, couldn't support the motion, made the point in the minutes, and filed a document after the meeting stating his requirements. All the annexes, all the elements, we're not asking you to dig up URLs, we've cut and pasted them into the document, which is why it's 110 pages. Well worth the read I assure you. So that's what we ended up with. Were there other cases which, you know, on the face of it we were interested in? Yes. And we had to make a decision at some point which ones to keep, but maybe we got it wrong, which is why we're running a consultation. We're not just running a consultation for the other SOs or things. We're asking everyone to have a look at it. If we've gotten something wrong, please tell us. We'll be glad to relook at all the cases. I don't think we've forgotten any cases. I have been, I think, fairly detail-oriented at going through every single one of them, and some of them it was borderline if we were going to include them or not. But we tried to generate a good set of examples that were clear. And there are the references and I'll be glad to take questions. Or the other gentlemen to my right. >>CHRIS DISSPAIN: Yeah. I just wanted to make an observation. Just in case it's not blindingly obvious, we're not judging whether these decisions were good or bad, okay? I mean, it may be that the right thing to do was this. But that does not -- that's not the criteria. The criteria is was it within policy. Some of these decisions you might think are great decisions. Some of these decisions you might think are appalling decisions but that's not relevant to this analysis. I just want to make sure -- because I'm conscious and in fact, we're all conscious because we've all been a very long time -- conscious that it could -- we don't want this to be perceived as trying to bash people up or, you know, attack people's integrity or anything like that. This is purely looking at it from a policy mechanics, so some of those decisions, I think, we would think were good or bad but I just wanted to make sure that that was absolutely clear. Thanks. >>BERNARD TURCOTTE: Yeah. I was trying to make that point. The one that's the most clear is the dot UM revocation. I mean, it's clearly way out of line from a policy point of view, but what are you going to do if you've got a ccTLD that no one wants to run? I mean... so we're not trying to rehash history. We're not commenting on the end results. We're looking at the mechanics, because what's important in the context of a group like us, you've got to be able to trust the mechanics and that's all we're looking at. Right? Did I make that clear enough, Keith? >>KEITH DAVIDSON: I think so, but just to absolutely reemphasize it, this draft report is not seeking to invite re-litigation of any individual delegation or redelegation. It's -- nor is it an opportunity to castigate the ICANN board for having stepped outside of policy or having had a -- too broad an interpretation of policy. It is merely to document where there have been gaps and how they might be remedied, whether they can be remedied outside of a PDP or not, and remember that this working group is not particularly interested in the individual instances of a delegation or redelegation, but more the overarching aspects of how IANA and the board have acted within their guidelines and policies. And just also just one more point before I totally open it up for questions. That is that we had a shorter presentation set of slides for the GAC today. There's this presentation. And there's also a slightly more substantial 60 PowerPoint -- or 60-slide presentation which are all going up on the Web site. I think they were pushed last night but I can't find them yet. But if at the very least -- the least interest you want to show in this subject is, I think, to go and have a look at the 60-slide PowerPoint presentation, which is a bullet point summary of the progress report and the issues uncovered, and I hope that that would then tempt you to read the 110-page document and make some submissions. Anyway, I think that we've been talking from here enough, and -- oh. >>BERNARD TURCOTTE: We can have a midnight showing of the 60 slides, if people are really interested. [Laughter] >>KEITH DAVIDSON: And the maintain point of today is to actually encourage some feedback and further discussion, so Hilde. >>HILDE THUNEM: Thank you. Hilde Thunem from the Norwegian registry. I would first like to say thank you to the working group because this is a substantial amount of work in actually going through a lot of very complicated cases and looking for a pattern, and I would like to echo your comment that what we're actually seeing here is a pattern. Some of the times the decisions made would have been perfectly common- sense decisions. I can think of decisions I would wholeheartedly support, like dropping the sponsorship agreement requirement, but it would, of course, have been nice if procedure for making the decisions were followed, and I think what I get out of your presentation, and might get out of reading the report if I ever get that far, is the feeling that at this point in time it would be useful to look more into how a delegation and redelegation happens and what kind of policy actually applies to it, and how that policy is implemented. But I would like to ask you a question. You were looking at delegations and redelegations. What kind of definition did you use to find out when the redelegation had happened? Did you look for IANA reports, for changes in the IANA database? What did you do to -- >>KEITH DAVIDSON: Purely at the ICANN board decisions and the IANA reports. Remembering that IANA and ICANN only publish reports and resolutions where there is a successful redelegation, so we've not looked at -- and nor should we be able to look at -- any application for a redelegation that failed. >>HILDE THUNEM: No, that's okay, but if there was a case where the organization -- the registry changed without an IANA report or a board decision, you would not have flagged it? >>BERNARD TURCOTTE: If there was no public documentation relative to a change, it did not enter here. Public documentation in some way related to the ICANN site. >>HILDE THUNEM: So merely the change in the IANA database would not be actually something you would discover. Okay. I might have a case for you later. >>CHRIS DISSPAIN: Brilliant. Absolutely marvelous. If there's something that's been missed, that's fantastic. Not that it's been missed but that you can tell us about it. >>KEITH DAVIDSON: And, yeah, there is no documentation that we have looked at that isn't publicly available, so we have gathered together a resource of that information which, if this working group does recommend a PDP, the -- the resource of documentation that we've amassed in one point should be a valuable resource to a PDP working group. >>BERNARD TURCOTTE: Just to confirm that, I mean, it's not included in the full report, but there is probably about -- I would guess 700 pages of annexes to support the 110-page report. So we didn't want to do that to anyone, but Keith is quite right. We didn't simply cut and paste from the Web site and say, "That's it." Everything is structured, documented. Each case was analyzed separately with all public documentation that is available, even though it may not all be included in the report. In the report, we tried to keep it to the things that were extremely salient to the points we were trying to make or the notes that we made after the decision, but in each case if we decide, as Keith says, if we decide to go forward, we're not starting up again trying to get the documentation. It's all there. >>HILDE THUNEM: The reason why I asked the question is that the NO registry was reorganized during this period where the registry was split out from the company it was originally part of and became a separate company. The delegation was moved from one company to another. We argued to IANA, being conscious of the requirement to sign the sponsorship agreement, that this was not a redelegation, and they accepted it and I was uncertain whether you would have viewed it as a redelegation or not. The name of the company did change in the IANA database, but there was, of course, no board decision or other things because it was a case of the personnel and machinery moving from one company to a daughter company of the original one. >>BERNARD TURCOTTE: If you send me the information, I'll be glad to put it through the sausage mill and see what pops out the other end. >>CHRIS DISSPAIN: Patricio. >>PATRICIO POBLETE: Thank you. Patricio Poblete from NIC Chile. I believe this is an extremely important matter. Important enough for me to go here and not watch the Mexico-Uruguay match. [Laughter] Having said that, I must confess that I signed up as an observer in this working group, and was not -- was not very active at the beginning to the extent of not being included in the mailing list and noticing for the fact for a few months. But once I got in, I couldn't help but be drawn into this, and I think I have to congratulate my colleagues who have done all this huge amount of work because the sheer volume is, in itself, very valuable information. Personally I was not aware that so many redelegations have happened. A large portion of the ccTLDs have been redelegated. Many of the people here have been the recipients of a ccTLD after a redelegation. That was new to me that it was such a large number. And I think that this case-by-case study is very interesting. It allows us to examine in detail how things have evolved, but it is only a part of what's needed for us as a working group to answer the question that was posed by the council. The real question had to do with us analyzing the current policies and guidelines, and to report on any issues or matters of concern that exist with those current policies. So it is the current policies that are most important to consider, and the analysis with respect to this is not just a formal one but I think it's more substantial in the sense of trying to determine if some of those current policies are somehow inadequate. Certainly if we determine that through history, the ICANN board hasn't always done things properly, that's one reason for considering that perhaps this needs to be looked into through a PDP, but if that analysis led us to the conclusion that the ICANN board had always consistently followed the policies in effect at the time so there was absolutely no deviation, that still wouldn't mean that there is no need for a PDP. Okay? And so if the analysis of this impressive work leads us to the conclusion that there is a need for a PDP, or maybe if it leads us to the opposite conclusion, I would think that we as a working group still need to do a -- go into the substance of the current policies and try to say something about them, even if it be that we consider that they are adequate or that we consider that they are not, and present some evidence on -- to support that. Because otherwise, I fear that our -- suppose we go into a PDP that we think that the PDP only has to do with those violations that have happened through history, while I think that the more pressing matters are those of the -- of now, not of the past. >>KEITH DAVIDSON: Thanks, Patricio. Chris? >>CHRIS DISSPAIN: Yeah. Patricio, I agree with what you said, and there's more work to do, obviously, but actually I think that this analysis informed -- in some -- in many respects informs that assessment, because if you look at what's actually happening, that helps you to consider whether what you've got that is supposed to govern what is happening is actually adequate. So to take a simple example, if -- it would be fairly easy, I would suggest, to draw this conclusion, to draw the conclusion that the analysis document indicates that the current policy, principles, whatever you want to call them, are lacking in detail, and thus allowing the board to color in the detail themselves. And so it is possible -- it might be possible to draw the conclusion, based on this, that clearly therefore there is a need for the detail for the color. Now, whether that means you need a PDP or not is a different issue. I'm not saying that the stuff that you've talked about doesn't need to be done. I'm saying that this informs that discussion, I think. >>PATRICIO POBLETE: Yes, but if I may comment on that. The fact that this analysis concentrates so much on whether the ICANN board has always followed the policies in effect at the time has the risk of distracting us from the analysis of the substance of the current policies to consider whether they are adequate or not. >>KEITH DAVIDSON: And Bernie, you wanted to answer? >>BERNARD TURCOTTE: Yeah. Patricio, we were exactly -- I was exactly where you are. And what you're saying is, we have to analyze the policies that apply today. Well, the reality is, we had to do this exercise to understand what were the policies that apply today. So I'm not arguing with you at all, but given the state of what is available, unfortunately -- which is completely weird in an organization like this, by the way -- we had to create the mechanics to find out what the policies are. >>PATRICIO POBLETE: Okay. Just one quick thing. As we say in academia, what I'm trying to say is that more work needs to be done. >>KEITH DAVIDSON: Oh, absolutely. And I think this is a work in progress, but this is a point in time where the working group needs to receive validation from the community that we're on the right track or be told that we're completely wrong, start again. So, yeah, we -- yeah, we have to move down the path is a step at a time. Chris, did -- >>YURI DEMCHENKO: It's Yuri Demchenko. A question. I looked through document. I see that you really refer to both -- or all three documents, where it's policy-related, but my question is: What's your observation? How strict or how clearly ICANN use GAC documents in their decision? Because sometimes it's not clear. Is it the -- >>CHRIS DISSPAIN: Let me make sure I've understood your question. You're asking, I think, has ICANN always used the documents, the three -- the three documents in the decision-making process. >>YURI DEMCHENKO: In particular, GAC documents, because they are the most restricted for, for example, redelegation and for government approval. >>CHRIS DISSPAIN: I think you're right. I think it's unclear whether they have actually used the documents or not. It's unclear. We don't know. >>YURI DEMCHENKO: Yeah. And then another question is what's your observation. How strict ICANN use GAC principles? Because they are sometimes more restrictive than ICP. >>KEITH DAVIDSON: I think, yeah, there are variations along the path as to what policies the board have felt more strongly about for individual decisions, and -- but the issue is more the issue around the interpretation of the policy. For example, taking the ISO-3166-1 list and saying ICANN is able to delegate reserved name -- or names from the reserved list as ccTLDs, the only reference to the ISO list is in RFC-1591, which states that the ISO-3166 list will be used. Now, there is no such thing as an ISO-3166 list. It's a ISO-3166 dash something list, of which one is the reserved list, so ICANN board have implied an interpretation of the policy and it's whether that's within the scope or not. Stephen. >>STEPHEN DEERHAKE: I'd like to thank Bernie and the other members of the working group for producing a -- what I think is a pretty brilliant document. This morning we were told by a board member, no less, that it is not the role of the ICANN board to make policy. What I'm seeing here makes it really hard for me to reconcile that statement with reality. I have a question for Bernie and other working group members, and I don't mean it to be a facetious question. But given all that you've uncovered with respect to policymaking by the board with respect to redelegations, at any point during this process did you detect a sense of embarrassment on the part of ICANN with respect to this? >>CHRIS DISSPAIN: Yeah. I'll just -- let me just say something and then Bernie can say what he wants. No, but I'll go back to what I said before, that the purpose of this is not to put people on the -- on the spot. I don't believe -- I -- personally, I don't believe there has been a concerted, conscious effort on the part of the ICANN board in its various guises over the last 10 years to deliberately ignore, change, move, et cetera, 1591, GAC, whatever. >>STEPHEN DEERHAKE: I don't either, but I'm just impressed at the extent of essentially a random walk through the last decade -- >>CHRIS DISSPAIN: Sure. >>STEPHEN DEERHAKE: -- of ad hoc policymaking. >>KEITH DAVIDSON: Yeah. I think there was a period where ICANN believed itself to be open and transparent and a bottom-up consensus decision-making body, providing it used those words; that it could do anything as long as it could use those words once a day. And, you know, for -- for those of us that remember those years, they weren't happy years in ICANN, and they subsequently moved on under the Stuart Lynn ICANN 2 model to actually becoming more committed to a process of open policy development, and I think what we're seeing today is a very different environment again, but remember that the -- that this is a policy that is almost an exclusive right of the ccNSO to create, and, you know, the actual issue of delegations and redelegations and its policies is an issue that is entirely within the scope of the ccNSO to create and go forward. So it is a bottom-up process rather than top-down. >>BERNARD TURCOTTE: Just before he goes away, what I will say, I agree with what both my esteemed colleagues have said here, but I would invite you to read the full report. >>KEITH DAVIDSON: Okay. And -- >> Yes. This is (saying name) and I want to make a clarification about the status of the reserved list because this is before -- because the reserved list is not an ISO list. ISO had established three lists, 3166-1, which is counties; -2, which is actually part inside countries; and 3 which is history. The reserved list is a list for the maintenance agent only, officially, so it's not part really of ISO but it contains codes which are, you know, scheduled to become on the list or not and that also has codes for various other reasons, and I just want to make sure that it's not understood this is an ISO standard. It's just a list of -- a working list. >>KEITH DAVIDSON: I'm thinking I hadn't seen you in the room so I thought I'd get away with that as an example and there's no better person to talk to us about the ISO-3166 list, but thank you for the clarification. Over here. >>ALBERTO PEREZ: Alberto Perez from Spain, dot ES. My comment was part in line with that of Hilde, our Norwegian colleague, because in the case of Spain and redelegation took place during 2004 and there was no sponsorship agreement signed, so I've read in the screen that Kazakhstan was considered a change of policy, so I'm not very sure about how dates are taken into account, because the IANA report is published with a date of 2005 but is referring to events that took place during 2004. I have to say it's a very unfortunate process because it took nine months when it was clear-cut. It was one branch of the government giving it in the best terms of cooperation to another with everyone in perfect agreement but took nine months because we were trying to being forced to sign agreements. We would not agree. But we sent a letter saying that we might study how to sign in the future an accountability framework, something similar. This is even listed in the IANA report and that that was considered as enough. So it has struck me to see the Kazakhstan case as a change in policy, but maybe the dates can get wrong because the IANA report is published with a much later date than when the events took place. >>BERNARD TURCOTTE: I'll review my dates again, but if I remember correctly -- and there's a lot of documentation. So as we said, this is out there for comments like that so we can get all our stuff right. I believe the decision was made to take the Kazakhstan example, there was nothing. There was no letter. While in the Spanish one, there was that letter saying, "We might sign one later on." I wanted to take a case that was absolutely clear where there was no reference. >> ALBERTO PEREZ: I was making the point like Hilde that the dates can be a bit confusing. >>KEITH DAVIDSON: Yes. >> ALBERTO PEREZ: Thank you. >>CHRIS DISSPAIN: Yes. >>KEITH DAVIDSON: Yes, please give us your submission and any clarifying documentation you have. Siraj (phonetic)? >> Hi, I'm Siraj (phonetic) from Iran. I would like to ask you about the nature of evidence you observed for community support in the redelegations you studied. I could also ask the same question about the nature of the local support you get for fast track, although I know it's being covered by a different thing. >>BERNARD TURCOTTE: IANA in most cases does not make any formal documentation which is a show of support of local community, Internet community support available, okay, in the documentation. So the standard that we use in analyzing the documents was trying to gather clear statements in both the IANA report and the board minutes that there was support. If we had both of those, then it was -- we would accept clearly, without any other document that is available publicly on the IANA site, that there was support. If there was only one of those two, it was a bit of a judgment call. And if neither were there, that's why you ended up with those two cases which are documented. So as we said when we started out, we worked with information that is available to everyone. That is on the Web site. It's not because we've got full documents -- copies of the full documents in the analysis that you have to believe us. You can go and do the research yourself, get the URLs and get those documents. But we limited ourselves to documents that were available to avoid any type of questions, "Well, we can show this. We can't show that." We've based ourselves purely on stuff that is publicly available on the ICANN site for supporting the given questions that we were looking at. >> Would you consider -- would you consider it desirable to have something more formal in the future, PDP about this community support? >>BERNARD TURCOTTE: Could you repeat your question just to make sure I understood it properly? >> Would you consider it desirable to have a more formal evidence for community support in the future, in a future PDP or whatever? >>BERNARD TURCOTTE: I don't think we really know. It's one of those questions that, you know, could be answered by a PDP. But the point is we're trying to bring together points. And, you know, the question you're asking is a metapoint, as far as I'm concerned, because throughout all the documentation, I think without it being a stated policy, they just don't give evidence of support. So is that desirable or not, I think is for the group and the community to comment on. Patricio? >>PATRICIO POBLETE: I don't know if Kim is in the room. I wanted to know if there is another trail for the IANA database so one can search and find out what was in the IANA database at any given point in the past. >>KEITH DAVIDSON: I think the working group did ask the question, and somebody generated a quite useful report of the dates of changes. Yes, Eberhard did. But we didn't find it necessarily useful in terms of the examination and analysis of these decisions. I mean, we haven't tried to capture every single instance of every single thing that's happened. We're more testing, where the bus has been going and when it has been going off the road and how far it has been going on its journey. I think now is a period for discussion about -- whether the breaches of policy, if you'd like, are sufficient to warrant a PDP or that we're happy enough as a community to just carry on in the future without a PDP. So those are the sorts of questions that I would like to see answered in the submissions. Okay. Are there any -- over here. Stephen? >>STEPHEN DEERHAKE: Elisabeth Porteneuve used to keep meticulous changes to the IANA database. And if you were looking for a definitive record up until I don't know how recently, that would probably be your go-to source to answer Patricio's question. >>CHRIS DISSPAIN: I think we're done. >>KEITH DAVIDSON: If there's nothing else, no further questions, I would like to record my thanks to Bernie for his excellent research and analysis skills and keeping our working group fully participative in terms of working on that analysis and so on. And to Bart for his great work in terms of reminding us of our limitations in our working group charter and so on. And so Gabi and Kristina for their support of the working group. And I think Kim Davies and Jaap Akkerhuis as ICANN's expert advisors to this group and willingness that they've shared information with us. And I'd also like to thank you all in fact for your submissions that will be forthcoming between now and the 15th of September. >>CHRIS DISSPAIN: Thank you, Keith. Thank you, Bernie. Thank you, Bart. It is time for us to close for the day except, of course, we are all going out -- not all of us. Some of us are going out for dinner. Gabi has sent an e-mail around to all of the lists with the survey for the day. Please fill in the survey on the Web so that we can work out whether we're still doing this okay or not. So everyone should have -- all three of the lists should have a link to do that. Please try and do that soon rather than in a week and half's time when you don't remember whether it was today or tomorrow that we did stuff and you have no clue whether it was any fun or not. So if you wouldn't mind doing it soon, that would be great. We start again in a different room tomorrow at 9:00. We're in the Ark. So come in two's tomorrow at 9:00. And thank you all very much indeed for your participation today, and we'll see you all in the morning. Thank you.