RSSAC Review ICANN Meeting - Mexico City 4 March 2009 >>HARALD ALVESTRAND: Okay. Welcome, everyone. If you are not here for the review of the RSSAC presentation of the independent reviewer's report, you're in the wrong room. So this is the -- I said that. This is a presentation of the report of the independent reviewers that have looked at RSSAC as part of ICANN's review process. And I'll let them present their views. The report got to us -- the report is from Westlake Consulting Limited. They've been working hard since October 2008. It was posted on February 25th, and we started the public comment period. No ICANN hands have touched this report before publication, so you get the full independent review. The next things that are going to happen are that we're going to listen to comments, "we" in this case being the Structural Improvements board -- Structural Improvements Committee Working Group on the RSSAC Report, which consists of Harald Alvestrand, Bruce Tonkin, and Steve Crocker. Steve, wave. So our hope is that after this meeting and after presenting the same material in the RSSAC meeting in San Francisco in a couple of weeks, the working group will be able to draw some conclusions from the public input. And the working group will then prepare a report, probably by Sydney -- and hopefully well before Sydney so that you can read it before coming to the meeting -- about suggesting what to do with the proposals in the report. There's a chance that there might be some public comment on that proposal, which will then be fed back into the working group, which will then work for a while until producing its final conclusions before the Seoul meeting. And unless we -- the public comment on that meets with a barrage of criticism and reasons to fundamentally reassess our position, we're going to suggest the whole thing to the board, or to the structural improvements committee, which will suggest it to the board. And sometime around the end of 2009 or the beginning of 2010, if all goes well, we'll go into an implementation phase, that is, implement what we have concluded should have been -- what we have concluded the sensible recommendation from this review is. And then we'll have to figure out what happened to us as a result. So, without further ado, let's hand the mic over to Westlake Consulting. I'll let you introduce yourself. >>RICHARD WESTLAKE: Good afternoon, ladies and gentlemen. My name is Richard Westlake. I'm the principal of Westlake Consulting. I'd like, if I could, while we just get the screen up, to introduce my two colleagues here with me, Colin Jackson and Andy Linton. You probably know these two better than you know me. But what we have been doing, you'll see, is -- and, as Harald has said, we were charged with reviewing the Root Server System Advisory Committee of ICANN. And I say that, right at the start, because it was a review of the RSSAC, we have not reviewed or even tried to review the root server system nor the root server operators themselves. When we come to some of the comments, you will see that we have tried to restrict those only to those that relate to the RSSAC or are relevant to the RSSAC. But for reasons that will come clear quite soon, I want to make that distinction, because there is, in some areas, certainly, obviously, a lot of overlap and certainly also some confusion. I'm taking it that you have all had a chance to access the report, which went up on the Web site, as Harald said, last week. There's an executive summary there as well of about six pages. If you haven't, if you want to do so right now, if you want to bring it up, there's a short URL up there on the screen which will take you through to the report if you want to have a look at it right now. We have worked as a team of four people. We're based in New Zealand, with a globally focused consulting business. And, as I said, two of our people was Andy Linton and Colin Jackson. They went to the Cairo meeting. And Andy, again, together with Vaughan Renner, who is not here today, went to the RSSAC meeting in Minneapolis, both, in November last year. During that time, we interviewed something like 50 people, both in person and later by telephone or other ways. So we've had quite a lot of contact. We've sought opinions from as broad a range of sources as we could in order to produce our report. What I'd like to do, then, if I could, is to take you through now -- just before I hand over the microphone to my colleagues, I'd like to just take you through some of the comments that were made to us about the RSSAC. Now, I make the point that when we were talking to people, these are some of the comments. They are direct quotes made to us. They are not our findings. They are not our results. Despite, I think when we went out to validate the reports, to validate our research, we sent out a fairly long document which summarized the comments we had received. And some people took that to be our final report. But we sent that out for validation. These are some of the highlights of the comments. The first one here -- and I don't know how many of you can read that screen -- but, "RSSAC is mostly a Kabuki play that merely parrots what has already been decided within the root-ops closed meetings." In other words, they felt that the RSSAC was little more than a voice for expressing the views already agreed by the roots-ops themselves. Secondly, and you'll see this one here, was that "Getting an opinion from the RSSAC is like pulling teeth." There was a view that there wasn't enough advice or opinion coming out of the RSSAC operating functioning as a committee. Conversely, from a member of the RSSAC itself was this comment that, "Most of the ICANN board is nontechnical and believes that any technical problem can be solved with money." So the perception coming from the RSSAC itself was that the ICANN board probably did not fully understand enough of the technical aspects and really would not appreciate the issues that they were dealing with. So what we were seeing was a -- if you like, a polarization of views, whether it was from the RS-ops themselves who were looking at ICANN and looking at the ICANN board and saying, "Well, you know, they never ask us for anything," and then from the ICANN side, looking at the RSSAC, and they're saying, "They never tell us anything." And then, finally, this other comment or this other comment that came up, "It would take a change in culture to get the RSSAC to forward contrasting views. They only put forward a view if there is a consensus." And, as Andy is going to explain a little bit later on, the point here is that it is very difficult for the RSSAC to reach consensus, for various reasons, the result of that being that very little advice would emerge because it was -- well, as far as we could establish, it was unheard of that there were either contrasting views or even an expression that there was a range of views expressed at the RSSAC meeting, that only when they fully agreed on a position did they actually make that come -- did that come forward. And the final comment -- And remember, this is what people have told us. These are not our views. This is a direct quote. "Does the RSSAC actually exist?" So on that note, reminding you that these are not Westlake's words, these are what we have copied down, I would like to now hand over to Colin Jackson, my colleague, who will talk to us -- sorry, to Andy Linton, I'm sorry, who will explain what we did find in a little bit more detail. Thank you. >>ANDY LINTON: How's that? I'd just like to pick up the last, but one point on there. The one about the contrasting views or the consensus thing, that was from one of the -- that was from an RSSAC member as well. So I just think it's important to note that wasn't a view from outside; that was a view from inside the RSSAC. Okay. So what did we find out, and how did we do it, and that sort of thing. The stuff that we found out was that there's certainly good work that RSSAC has done. There's no doubt about that. And people we talk to on both -- who are linked more strongly with ICANN than with RSSAC acknowledge that. The work of IDNs. There's a document you can find on the Net. There's work on IPv6 and DNSsec. But, interestingly, if you want to go find that information, it's pretty difficult to actually put your finger on it. If you go to the RSSAC Web page and look for what's there, you'll find the paper on IDNs or the position that RSSAC reached on IDNs. If you want to find out their position on IPv6, you have to go off scrolling down to the pages, find a paper that was jointly coined by SSAC and RSSAC. And, eventually, you can find it, and so on. So there's a lack of ability to go to the Web site that deals with the RSSAC activities and find out what's going on. So this -- I'll sort of reiterate that. This is a common thread that has gone on with things we tried to find out. This work that RSSAC does does not have a huge public perception. Some people might say that's because it's not very interesting -- there's lots of people out there -- and, therefore, it doesn't really matter. But there was certainly a lot of people who we talked to who said, "It's really hard for us to know what RSSAC is doing. So they may be doing a fantastic job, but we just don't know." So we have also looked at the bylaws as they're set out. There's quite a long paragraph on the bylaws that says basically three things: That RSSAC is there to provide advice to the board about the root server system; they should examine and make recommendations about the operating systems that the root server operators should run and the hardware capacities and network capacities. And the third point that they're charged with looking at is the deployment end of name servers around the world to make sure that those are robust and reliable and so on. Now, those last two points -- there's a real sort of tension and dilemma on this because this is really the territory that the root server operators believe is their territory to look up and that RSSAC has got absolutely no business looking at this and they should be perhaps reporting to the board but certainly not making decisions and recommendations about it. So there's almost this problem, if you look at the actual bylaws, that says, you've got three things to do here and two of them you can't do. So that makes it pretty hard for a committee to be effective and do exactly what the bylaws say. And the other piece of documentation, if you like, about what RSSAC is about, in 1999 when they first met, the first set of minutes has a number of work items that they thought were the useful things for them to do. And there were one or two things in there which are clearly overtaken by events. The Y2K issue has been and gone. There were a number of other things in there that they were to do. And for various reasons, they weren't able to either achieve those or those are things that have bypassed them, it's gone by the way. So there have been, certainly, some difficulties. And the reason why those were difficult things for them to do is, you've got a volunteer group who have very little infrastructure support. If you look at the minutes that are on the Web site and in discussions with people, they have talked about, on a number of occasions, trying to get some administrative support in there. But because there is little administrative support in there, then the process of getting some administrative support in there is difficult. So it goes on. So that certainly was an issue. And I already talked about this notion that the RSSAC section of the ICANN Web site -- there's some detailed points in the report that talk about this -- that needs work. And that's work that ICANN can and should do on behalf of RSSAC with some RSSAC direction. So we've got this position where RSSAC had a set of think tasks they were set to do. You could argue that two of them were almost doomed to failure to start with. So we find that RSSAC has actually worked out its own agenda of what it should be doing. And some of that is that piece of prevailing advice to the board. But it's also ended up being a conduit between ICANN and the root server operators and other people who are involved in this process and are interested in this process, people like the Regional Internet Registries, people like the IAB/IETF sort of group, and other people who are interested in this sort of stuff. So what else did we find out? Okay. Now, the committee membership is set out in the bylaws. The bylaws say that the committee should consist of someone from each of the root server operators and other persons appointed by the ICANN board. Now, we can find no evidence -- we'd love to see, if we're wrong on this -- but we can find no evidence that the ICANN board has actually ever said, "And we would like Fred Blokes to be here and whatever to be on the RSSAC committee." And that quote of "whoever happens to be in town" actually came from one of the RSSAC members that we talked to when we were in Minneapolis. If you want to find out who is on RSSAC, there seem to me to be about three ways -- two to three ways that you can sort of -- you can ask people and see if they thought they were on it. You could look at the mailing list, which is hosted at -- I think, John, you look after that. And you could go back through the minutes of the meetings and see who had been there. But if you're -- you haven't been at the meetings, going back through the minutes can be a little bit difficult, because you'll see the people who were there were John and Suzanne and -- and quite a number of places, it's actually just given by first name. So you have to be on the inside to know who those people are. And that makes it fairly difficult to actually work out who the membership is. >>BILL: So, Andy, are you taking comments now or you want to finish first? >>ANDY LINTON: Well, let me finish. And we've got an hour to sort of wrestle in the middle of the floor here, Bill. It's not a problem, you know? >>BILL: The member of the board, Jun Murai, who remains the chair of RSSAC, did make the initial appointments. So the board actually -- >>ANDY LINTON: Okay. Yeah. >>BILL: -- did it at least once. And, then they forgot to refresh. >>ANDY LINTON: Yeah. Okay. I take your point, Bill. That, I mean, you can look at John as being there because he was a root server operator or linked to someone who was a root server operator. >>BILL: He was the board member who was tasked with starting this thing up. >>ANDY LINTON: Okay. Okay. We'll talk some more about some of that stuff in a moment. Yep. So in the conversations we had with people, what we were able to sort of glean from them in terms of the agenda management was that this is a committee that effectively deals with -- and in a lot of cases -- not always, but in a lot of cases, deals with issues on an issue-by-issue basis. There's work needs done on IPv6. We'll do the work. There's work that needs done on IDNs. We'll do the work. And so on. While we were finishing up compiling the report, there was, actually, I think, an example of how this process works in that there was a joint group put together between SSAC and RSSAC to look at the issues around expanding the global gTLDs and adding lots of domains. And the issue has come up. And then there's a working group formed or an issue that needs to be dealt with. I've already touched on this notion that the committee's resource poor. So there is no one -- There's volunteers who take the minutes and do the best that they can with that sort of process, but, you know, if you look at the minutes, the minutes are compiled from the notes of two or three people who were there. And if you're a layperson trying to read those notes -- and I'm not suggesting that everybody in the world should be able to read them and they should read like sort of something that's in a tabloid newspaper and very straightforward. But, you know, they're relatively impenetrable to someone who doesn't understand the DNS. And, as a technical committee, that's not unreasonable. But there's also stuff in there that it's hard for people to understand what's going on in here. I already touched on this notion that consensus is difficult for the current group. I've only been to one RSSAC meeting. We went to the one in Minneapolis. And there was an issue on the tabling where a number of people were keen to have some sort of position, and it seemed really difficult for the people who were around the table to actually reach a position, and so they shelved it, put it away, and said, "We'll come back to it next time." That means this won't get looked at again for another three or four months. And that's sort of difficult if you've got something that you've asked for advice from the ICANN board to RSSAC. There's a two-week gap between the meetings. So it's two weeks before they effectively get to discuss it. And it might be another several months before things happen. And Steve? >>STEVE CROCKER: Just a minor point. On that two weeks, that's not structural. That's just an accident of the calendar time you're looking at. It could have been two weeks before; right? >>ANDY LINTON: Absolutely. Sure. You know, I mean, there's no -- you do have an interesting issue, I think, even of the timing. And this is -- my observation of the RSSAC meeting comes after the root server operators' meeting on the Sunday. So if RSSAC wants to reissue so it wants the root server operators to discuss, in some sense, those issues, from an out- -- an external perception, those issues get raised after the root sever operators' meeting. Now, I know Suzanne is at both these, and she wears multiple hats -- >>SUZANNE WOOLF: I was figuring out if you already cut off my mic. >>ANDY LINTON: Yeah. So there's some -- yeah. Okay. I'm going to go on to the next one, then. So procedures. Now, we had discussions with people -- Most of this stuff on the procedures comes from people who were -- who attend RSSAC meetings, several of them root server operators and other people who attend them. So, like, people from the RIRs, they say there's -- in terms of the planning of an agenda, it's -- you know, a lot of this is very ad hoc. Now, that may be perfectly acceptable for that group and that's the way they want to work. But it's not, we felt, the way that normal committees will work. You know, there's an agenda. You discuss points. You come to decisions and go on. And if this group is one that can't reach decisions, then you can sort of see why that's difficult. Chair selection. Bill has already touched on this. The chair was Jun Murai, who was appointed in 1999. And one of the pieces of the charter in that first meeting was to come up with a chair selection process so that in some -- at that stage undefined period, they would seek to elect a chair from the members of the committee. And that has never happened. And there have been several attempts, according to the record, to get that together to say well, we need to get some criteria. We need to get a selection process. And that has floundered. And you come back at the next meeting, and it hasn't been discussed at the next meeting. That, again, is a symptom of, I think, some of that resource poor stuff. If you had someone who was providing some administrative support, that's work that could be pick up between meetings and carried on. The succession this year as well, until relatively recently, there was a chair. And in 2005? Yeah. '5? 2005, yeah -- they -- the group decided that they would have a vice chair to sort of take some of the load off the chair and sort of provide the ability for somebody to be absent and so on and so on. So there has been a process there. But there is no process still of and this is how we would have an election. There's no process of people will serve a number of terms, and we would expect them to step aside and get some new blood in or change it and so on. There's none of that process. And, on the issue of transparency, the people, through the minutes of the RSSAC meeting and in discussions, there have been places where they have agreed that getting the minutes out in a timely manner is something that's really important. But, again, this lack of resource has restricted that ability to do that. And there were also discussions at various stages on the minutes which talked about being able to have a Web site which reflected the activities and the work that was going on. And, again, lack of resource. And, you know, we've certainly sympathized greatly with the group who have a lot of work to do but no process to sort of facilitate that going on between the -- between meetings. So that was -- there's a lot more material in the report, of course, if you want to look at that and pick that up. And we went through that and thought, okay, well, there's stuff here we think is -- needs some help, needs some work, needs to be -- I don't think this is stuff that we talk -- you should talk about being broken. That's just stuff that needs done. And I think the other piece of this that, you know, people should understand as well is this is not all stuff that's on the RSSAC committee's side of the house. You know, there's stuff that needs fixed inside ICANN as well with this. You know, there's support for the web page. There's support for the way questions get asked of RSSAC, the was questions should be answered and so on. There's a two- way street here. This is a relationship between two groups that need to -- need to do some work, and this isn't all about RSSAC needing extra work. Work needs to be done on the way ICANN handles the process of taking the advice and asking for it. So Colin is going to talk about where we got to and the options for change, which are in the second sort of part of the report. And I'm going to give it back to him now. >>COLIN JACKSON: Thanks. Thanks, Andy. Is this mic working? I need to be a bit closer, don't I. How's that? Okay. Options for change. We looked at that. And, of course, the [indiscernible] line, of course, you notice that status quo is not an option for change. But we threw it in for completeness. It's we don't believe, though, that the status quo really serves the purpose in the ICANN bylaws. It clearly doesn't. Because the ICANN bylaws require the RSSAC to do various things, quite details things, relating to its server operations, which is no business of the RSSAC. So I think everybody agrees with that. So, therefore, something needs to change. So that option is off the table pretty quickly. Next option we put up is to abolish the RSSAC. We don't believe that's a good idea from our perspective. What is required here is greater communications between ICANN and the root server operators. Abolishing RSSAC would have exactly the opposite effect. So, therefore, that's another option that we dismissed pretty rapidly without any great analysis. Third option on the list here is converting the RSSAC to an SO, in ICANN speak. Again, we don't really see that as a terribly valid thing to do. SOs in ICANN are there for forming policy. And we don't really see that that's the role that we would see a body between running jointly between the root server operators and ICANN to do. The classic model inside the GNSO or ccNSO or something is people who want policy come to ICANN and form policy under some kind of umbrella. And that's, again, not how we see, not what we see as terribly relevant to the root server operations. The fourth option here -- this really is the first one that is really credible on this list. And that would be to essentially rewrite the bylaws so that they gave a better sense of what the RSSAC can realistically achieve and provide it with adequate staff support so that it's got the resources to do it. And that is actually quite a realistic thing that could be done and, in our view, the minimum that should be done. The 5th option, which is reinventing RSSAC as a joint strategy group, is the one we prefer and that we're going to tease out a little further in a moment. And so I'm going to jump to the picture and talk about that. If you've looked at the report, you'll already have seen this. Okay. We've got the Internet community drawn as a cloud at the top to really emphasize that that's what we're doing -- that is who we are doing this for. That may seem obvious in telling people to suck eggs. But we are all ultimately here trying to -- trying to be answerable to the Internet community and deliver things so the Internet community, however you define that, can get on and do whatever it does with the Internet. And I know that ICANN with its multi-stakeholder account model very much sees itself as accountable to the Internet community. I'm sure root server operators do as well, although probably in a different way. So we are proposing a joint body here. We've called it the RSSAC. And, just as an aside here, we considered renaming it to emphasize it was a different body. But then we felt that that would get in the way of the whole proposal when we've spent hours debating names, which really, we don't think is the point. So we've kept it called RSSAC, but it is quite a fundamentally different thing. It is a joint strategy group as we proposed. And it also has strong links to IANA and to the technical community as represented by the IETF or the stroke IAB and to the SSAC, which, of course, is a key player in the whole area. The RSSAC and SSAC have worked very closely together in the past. And we're gratified to see that is -- that cooperation is expanding and deepening even in the course of us writing this report. And we would imagine that would continue. I'm going to discuss in a bit more detail the parts of our -- of the RSSAC reloaded now. The membership, which is listed here -- the thing I want to make clear here is that the most important thing about a member of the revised RSSAC is, as with the current RSSAC, really, the most important criteria must be technical knowledge and ability. There is, in our view, no point, probably negative value, in putting people on who don't have a good -- really good understanding of the DNS and what a root server is and what root server ops do. That would just waste everybody's time. It would be an exercise in frustration and would rapidly undermine the committee. So that is paramount, that criterion for membership. That said, we envisage nine members, as you can see set out there. That's four from the root server operators chosen however the root server operators wish to choose. That is one person from IANA. I feel confident that IANA can find an adequately technically competent person. And that is four persons chosen by the ICANN board from the ICANN community. On the previous slide we made a suggestion of various constituencies that the board might want to choose from. That's a suggestion. We would leave that up to the board who would make a decision presumably through the NomCom or whatever other process the board saw fit. But we would emphasize that the important thing is the technical criterion or the knowledgeability of the persons that the board was selecting to go on to the RSSAC. The next most important aspect of the new RSSAC is that RSSAC, in our view, requires a significant level of support. And we are proposing that ICANN provide that. I hope ICANN agree, but anyway. So we're proposing two different types of support here. And one is through what we have called a technical fellow. Now, this is a person whom ICANN would engage or select somehow who would have very considerable credibility and ability in this area. And we've provided an outlined job description for that person as an appendix to the report. So this is a senior technical individual with credibility in this area. Secondly, we also are proposing that ICANN provide administrative support in order that things like minutes can be got out, the Web site can be run properly. We -- you know, in our last slide a couple slides ago, Andy mentioned that there is a lack of process, as far as we've been able to tell. And I think we all recognize that process actually takes time. And to do process properly, you really want somebody there who's tasked to do that for you rather than these individuals or these busy individuals actually having to do it themselves. So we are proposing here that there is significant administrative support provided. We've set that out as a separate heading because we don't want people to get the idea that we are proposing that one person be both the technical and administrative support. I don't see that as practical. There are also liaisons for the committee here. Inward liaisons from the IETF/IAB. We're a little agnostic as to how that person would be selected. It could be through ISOC, for instance, who might nominate someone. That is to be worked through, but we believe that there should be somebody who is a strong representative of that community. We also see that -- sorry, that SSAC should have a liaison on the new committee, as indeed should the new committee have one on SSAC that that relationship needs to remain very, very tight and have a great deal of cooperation between the two groups. There is also, of course, an outward board liaison as there is at the moment. And that's important and that should remain there. We were asked to look at whether or not that should be a voting member of the board, by the way. It was part of our terms of reference. We asked quite a number of people that. Nobody seemed particularly enthusiastic about the subject. From our perspective, someone -- a liaison from a committee like the RSSAC should -- if the board doesn't listen to them, then we've all got a problem. If they come and say, "This will break the root server system," then I feel confident the board would listen to them. And, if they don't, I think we'd all like to know. There's one other major point I want to make here. We believe that this committee should meet at ICANN and it should meet in open session. Now, I know that there are specific items that people would desire not to be discussed in open session for valid security reasons. And that's understandable. But we don't believe that that should be the default, the norm. We think that that should be -- it's perfectly possible to put a meeting into committee and kick everybody out, if you need to discuss something which is too sensitive or likely to lead to problems if it becomes public knowledge too early. So there are ways to achieve that. But, in our view, the RSSAC should exist in a way that people can actually see it in operation. I think this is one of the reasons why currently a lot of people don't even know that it's there simply because they can't find it. They can't -- they don't know when it meets. They need an invitation to get in. And, through no fault of the committee's, the minutes tend to get published an awful lot later. Okay. I'm going hand back over to Richard who will wrap up, and then we're going to throw the whole thing open for discussion. >>Richard Westlake: Thank you, Colin. Well, where do we go from here? Where to from here? We have delivered our report to the review working group. And, as Harald explained to you, the process from here on is that the review working group will work through our report and finally make their decisions or, sorry, their recommendations to the board. As he said, the public comment process on our report is open until the end of March. The review working group works from there and will then publish their draft report which, in turn, will be open for public comment before the final recommendation goes to the board, as Harald has explained. Ladies and gentlemen, that's only a very brief summary of the report we put together. There are a lot of points in there. One of the points I would like to just make, though, is that it is a -- it's not a smorgasbord where can you pick and choose. We believe that there are substantial things that the integrated set of recommendations we have put together are actually -- it's quite important they're connected, they're related. And we would -- if we could, as a final comment, counsel the review working group to see it in that way and not to see the recommendations as individual ones to be picked and chosen and others to be ignored without understanding the linkages and the potential consequences of doing so. Ladies and gentlemen, thank you very much indeed. A final slide there. I hope we've captured at least most of the individuals in the room. And since we come from New Zealand, I should also like to close [speaking in language not translated.] >>HARALD ALVESTRAND: Thank you very much for your report. I think that now we can immediately open the question and answer session. We have a lot of time that we can devote to the discussion until 5:30. so please feel free to intervene on any of the points of the report. Just as a matter of course, if you can introduce yourself even because the session is being recorded. So, if somebody listens to the recording, they can identify everybody who makes a question. Thank you. >>SUZANNE WOLF: I was hoping someone else would comment. Put me in the queue behind whoever's first. >>JOHN CRAIN: I'll go because everybody seems to be shy. Very strange. I'm John Crane. And I actually work at ICANN, but I also operate DNS. I'm a bit conflicted here. So I'm going to ask a question. And that is the broadening of the membership by including ccNSO, et cetera, what is the purpose of that? Is it to include those that are direct customers, or is it to just to widen it and to bring more of the community in? And, if it's the latter, why did you pick those specific ones and not others? >>I'll take that one, if I can. We see the new RSSAC as a joint strategy group. Okay? I want to stress that. So it's a -- it's not just the root server ops plus one or two people. It's actually pretty much 50/50. Root server ops, IANA, which is kind of neither fish nor foul, and -- terribly sorry -- and ICANN community on the other side. It's not to imply that there should be tension between them as such but there should be, we would hope, as least some creative discussions. There's a lot of issues that go around IDNs, DNSsec. There are a lot. I could list off half a dozen where there is a real need for coordination and joint strategy between the root server ops who implement this stuff largely or have to serve it; IANA, who plays quite a role, of course; and the community who actually wants it or sees it as part of some other initiative. So that's really why we've arranged the committees we have to try to get this sort of joint strategy approach. John? >>JOHN CRAIN: Maybe I should rephrase my question. What was the criteria for the specific ones that you picked is really my question. I completely understand the idea of widening the input. But what was the criteria for ones you actually picked and the ones that you didn't. >>SUZANNE WOOLF: Yeah. I think one of the things to notice there -- I know, I should have waited to be -- if I can help John out here, I think one of the things to note here is suggested or the groups to constitute the revised RSSAC is that there's a -- there are many, many strictly representative groups in ICANN circles. And, since the affiliations were stated as the primary criterion -- and I've heard -- I'm listening to what you guys are saying about the technical clue being the defining criterion. But really, as you've written the recommendation, it's not. Membership in certain groups is the primary criterion, followed by we have to find people from these groups who are technically skilled. Therefore, I think I understand John's question of why those groups. >>I take your point, Suzanne, about the phrasing and the way that we've expressed that. We hope that what people would do would be pick up the position description towards the end or later on in that section where we talk about this. And we didn't differentiate in any way between the membership. We just said the members of the group should be like this. We didn't say and the root severer operators should be like this and the IANA person should be like this and the ones come from ICANN should look like this. No. To talk about why we picked the particular groups, ccNSO and GNSO are clearly customers of the root server operators. The root server system, let's call it that, right? And as such, you know, the work that IANA does in conjunction with the root server operators affects those people in a very direct and important way. I mean, that's what they're about. We also felt that the ASO with the IANA.ARPA issue, because that gets served out of these servers as well, is one that the address support and organizations have a definite interest in this thing. You know? And I suppose, you know, John and I talked about this last night. And, sorry, got the heads up on this one, in a sense. The ALAC one was and why ALAC and why not the GAC and something else? I don't want -- what I would hope that we don't do here is get this into we said they must be. I'm very happy -- and we've talked about this. We're very happy that phrase in the report was read as "such as." And it could be any of the constituents. It's not really that. The key thing and the brief that we would expect that, if the board goes ahead with this and, you know, the process continues, is that eventually a Nominating Committee will get some work to do here. They'll love this, but there you go. So the Nominating Committee gets some work. And they have to find some people who represent those constituencies. And Bill has something there. >>BILL: So I'm going to go back a little bit and try and wrap some thread around this. And then I'm going to ask my question. >>Sure. >>BILL: Jun Murai was on the board of trustees of ICANN when he was tasked with heading up this committee. >>Yep. >>BILL: When he selected people, he selected people from the regional registries, which comprised the address supporting organization. And they have been active ever since. >>Yeah. >>BILL: He picked people from the IETF, from the IESG, and from the IAB. They came for a while, and then they stopped coming. We also have governmental people on the mailing list, which come when they can. So the constituencies at the time when the board constituted this committee did, in fact, have some fairly broad representation. Adding additional people is probably reasonable. I think having a too small committee might be untenable. And there's some questions about whether there's actually a real distinction between ICANN and IANA, or is that a distinction without a difference? Now, my question: You're turning this into a strategy committee. What is the remit? What tasks are we supposed to go chase down that we're going to need to meet with every ICANN meeting in open session for a half hour and explain to people how busy we've been solving these strategic problems? What problems are they? >>I think there are issues of the transparency of the process. Now, if I want to find out statistics, I'll put my hat on as someone from .NZ. And I work on the committee. And I'm leaving the report aside here. If I want to know what's going on in the root server system, where do I go to find out about it? You know, you can say ALAC -- and I did this process when I tried to find out what's going on here. It's really hard. I go to the RSSAC page, yeah, there's not much there that tells me what's happening. I can't find out anything about response times. I can't find out anything about -- I can go off and find some other page that tells me that. That's advice that a committee that's advising the ICANN board on the performance of the root server systems should be in a position to provide. And it's whether they do that by collating results from the likes of CADA, DNSmon or whatever. Or they commission work to be done or whatever it is. There's work that needs to be done. So that's -- that's at least part of it. And there's other stuff in there. You know, they -- one of the pieces questions we asked people was what would happen if a root server failed? You know, the operator of it failed. We live in straight and economic times. And, when we started asking this question, it wasn't perhaps near as likely an event. But what happens? How do we decide to choose a new one? There is no process in all of this to choose a new one. Some people say well, the root server operators would work this out. >>BILL: It's been done twice since ICANN existed. >>It's been done twice, yeah. But, you know, is this something reasonable that the community, the Internet community should have an understanding that there is a robust process here? And I'm not saying that the process wasn't robust in the past. But, you know, a lot of this -- if you actually listen to what people said to us, it's not about what RSSAC does and what the root server operators do and what ICANN does in this space. It's about being seemed to be done. That was -- you know, that has -- that was one that came really strongly to us. It's the work is happening. But then we have other people who are saying well, it must be working because we haven't heard any problems or any reports of problems. And so there's some extra work, I think, that perhaps our group could work on. Steve? >>Just before we get to Steve, just want to amplify one point. We see this as providing advice on strategic issues. We do not see this committee as presuming to tell the root server operators how to run root servers. It's not an operational thing. >>Steve? >>STEVE CROCKER: I'm having trouble reconcile your opening statements about this is a focus on the root server on RSSAC as opposed to the root operators. Because these last points about transparency, about how you choose another root operator if one failed, about the statistics and so forth, are -- seem to me are all about what happens in the root server community. And, as we know, the ICANN and the board don't have any role in all of that. There's no structural arrangement. There isn't any policy to be made, because there's no basis for that. This is all -- I don't understand the construct here because the root server operators aren't involved in this consultation at all. >>Well, I think if -- if you take the title of RSSAC and say it's the root server system advisory committee, the committee is supposed to provide advice to the ICANN board about the operation of the system, not the root server operators but the system as a whole. And that includes the work that IANA does. They're part of the root server system because they publish the zone, and it gets displayed. It's not as someone -- and this, again, is me wearing my personal hat. It's not reasonable for me to want to go and find out about the root server system and have to go to 12 -- well, maybe it is. But, you know, to go to 12 individual sites run by the root server operators, many of whom who don't establish any statistics, graphs or any information about what they do. >>STEVE CROCKER: I'm not taking issue with the natural desire to want to learn more about this. And I understand your concept of the root system -- the root system. But, of course, it includes the Department of Commerce and it includes Verisign in roles that are not covered by any of what you've talked about here. What I don't understand is the construct that you put together doesn't address the fundamental situation that you're providing advice to ICANN to be taken by the board which does not have the power to make these decisions in a way that has any effect on the issues that you're raising. >>Well, I think -- if you think, Steve, about where we talked about the expanded terms of reference for the new group, we talked about this group not just providing advice to the ICANN board but having a role in providing feedback and advice to the Internet community. So you could say that providing advice to the ICANN board was one way for that feedback to get to the community. But is publishing their minutes something that needs to happen at that point? Should they just not send the minutes to the ICANN board? You know, there's a number of ways to look at how you provide advice to the ICANN board. The ICANN board is here as a representative of the community. >>STEVE CROCKER: But not as a representative of the root operators. >>And we aren't asking for them -- this committee to be someone who holds the root server operators to task. But you can't provide advice about the operations of the root server system if you don't know how it performs. >>STEVE CONTE: But it's not clear that what you structured even gets the information. >>Okay. That's a different issue. I mean, you know. >>STEVE CROCKER: But it seems to me the issue in that all the construct that you put together and that you've emphasized should be taken as a whole is founded on the assumption or on the basis that the root operators are actually cooperative with this. And if the root operators had commissioned an external review of RSSAC and said, "How can we better cooperate in this and make this more effective" -- >>And in a perfect world this -- the review that we were tasked with or a review on this space would be one that says let's review ICANN and its operation in relation to this, the root server advisory committee and the root server operators. And that would have been a joint decision. But it's not. RSSAC is a creature of ICANN, was created by ICANN. And it was created, given the language in the JPA, to say you must do these things. There's about half a dozen things which, if you look at them in the JPA, have been picked up and dropped into the bylaws. >>STEVE CROCKER: The great thing about policy pronouncements is that they are sometimes not connected with whether or not they're feasible. >>SUZANNE WOOLF: Right. >>Absolutely. >>STEVE CROCKER: So the fact it's in the JPA or the fact that it's not created doesn't actually make it a real -- >>That's the history of it, and that's why it's there. >>STEVE CROCKER: But that doesn't mean that, therefore, it has to be taken as a valid -- >>Okay, yeah. You can sort of say, "Well, we have a committee and it's" -- >>SUZANNE WOOLF: Gentlemen? >>HARALD ALVESTRAND: There is Suzanne then. >>Suzanne, go on. >>SUZANNE WOOLF: I've gotten to the point where I really feel the need to raise two process points for the record. >>Sure. >>SUZANNE WOOLF: I'm Suzanne wolf. I wear a number of hats. One of them is as a root server operator. One of them is as the technical person at IANA and ICANN in those days who was originally the staff support to RSSAC. And one of them is as the current liaison to the RSSAC board. However, as a process point, as I understand the process of the independent review, I have exactly the same standing to comment as any other member of the public because there's no particular role for the body under review in the process of evaluating the review and the board working group deciding how to go forward. So I'm -- I guess I can only speak as a member of the public. And I think, frankly, that's a flaw in the review process. But to the other process point, the initial tasking of RSSAC was created by ICANN's then GC and policy director with no input from any of the people who were being tasked. So, in a way, you guys were set up in a situation where you really had limited ability to do what you were being asked to do, because the tasking that appears in the bylaws towards RSSAC was never, shall we say, validity checked for buy-in by anybody. And another way of looking at what's happened since may well be that we can all be surprised that the folks who do participate in RSSAC have continued to show up at all and have put together the mechanisms they have to try to be helpful and effective in the ways that they have been. >>Can I just jump in here, just one thing. I would hate for anything we've said to be taken as Westlake's criticizing RSSAC or the members of RSSAC. That's not how it's intended at all. And we do appreciate that people put in a lot of time trying to keep this thing going. If I can be blunt, the way the thing has been set up is it's not really capable of doing many of the things it was set up to do. I think we'd probably all agree that. So I would hate to think that RSSAC members here will be taking it as some kind of personal criticism. It is not intended as such. >>SUZANNE WOOLF: No, I understand that you were working within the framework you had. But I think part of what we're seeing here is the disconnect or lack of closure on this discussion that we've always had. You know, we're seeing it played out in this room, which is, for instance, having participated as a board member as an RSSAC member and as a root server operator, there are many times and many ways in which both sides could have asked things of each other that just has not happened. And I don't -- what I'm hearing from -- then again, it's partly the situation you guys were set up in as the reviewers hired by ICANN to review a piece of ICANN. What I'm seeing a little bit here is you don't quite understand how this works and we're not getting from it what we thought we should, so let's change them. And there's a certain amount of clarification of mutual expectations that, frankly, never took place. And what we're talking about here is the fact that it's never taken place, and it does need to take place. But I'm not sure -- you know, it's hard to not take it as critical, when you're -- you know, as how it's been framed. And, again, I'm not putting that on you. It's probably what you have been hearing. But a constructive way forward might almost be to throw out what the original tasking was, what the original framing in the bylaws was. >>The review, no. >>SUZANNE WOOLF: Meet you in the bar. But to take away the -- and start clean slate. Don't say this has failed. Because, frankly, I'm not sure that there's any basis for judging. You know? You can't -- it's very hard to say that people have failed to carry out what you asked them when you failed to consult them what you were asking of them. So I'm thinking a more constructive path might be to say we'll pretend -- you know, do the thought experiment of you don't have a board level, an ICANN advisory committee level construct around engaging with this set of people and issues. What do we do? >>Suzanne, if I could just pick up on your point right there, that's exactly what we have suggested. What we have suggested is that the terms of references laid out in the bylaws should be amended to say that the RSSAC's new purpose is to be -- to provide a source of unbiased strategic advice to ICANN, the root server operators, and the Internet community. In other words, we're saying that this is a new job which it hasn't been tasked with before. We're differentiating the operational aspects, which is clearly the role of the root server operators themselves. And we're saying there's certain amounts of strategic issues and advice which currently aren't actually in anybody's job description. Here we've got something which has evolved to be critical infrastructure for the planet. And, as far as we can find, there is nobody who is tasked with identifying the key strategic issues and risks facing that system. And that's what we're trying to say that the new RSSAC will be tasked with doing. It's not trying to supersede the RS ops. It's not trying to supersede or it's not trying to in any way provide criticism to the current RSSAC, because the RSSAC wasn't actually asked to do this. But I think the point we want to make is that the RSSAC -- everybody has told us the RSSAC has acted reactively. When it's been asked for advice, it gives advice. However, we believe that there must be strategic issues out there which the board may not be aware of and, therefore, may not be asking questions because it doesn't know what it doesn't know. And, as a result, we're looking for a proactive advisory committee of the best group of people possible able to identify those issues and provide advice on that, whether it's risk assessment, strategic risk assessment, whether it's pointing out a strategic risk to the operators, the community, and to the RSSAC board itself. So it is quite a distinct animal. >>Are you guys sure you're done at that end of the table? >>SUZANNE WOOLF: No, but now it's your turn. >>Okay. So I'm going to take off one of my hats and put on another hat, which is a root server operator. And I look around. And from that diagram you had up earlier, my primary constituency is the people who send queries to my server. And with meetings within the root sever operators themselves and with RSSAC and with a couple of other external committees to try and meet the needs of parts of the community, we do what we can. RSSAC has done a perhaps not as good a job at communicating back into ICANN what's happening with that part of the root server system. And I see this review and some of the recommendations as an attempt to improve that flow of information into ICANN. But ICANN is only one member of the much larger community that needs information about the root server system. And I don't think ICANN has an exclusive hold or right to the information about the root server system nor to be able to control collection and dissemination of the data about the root server system. I think that that's a much larger remit that belongs to many more sets of people, not all of whom are under the ICANN tent or umbrella. And so, from that perspective, I appreciate and applaud the fact that there's an attempt to revisit this. I think that there are actually -- the board actually has the sufficient tools available to restructure or reconstitute, as it sees fit, one of its own committees. RSSAC is an ICANN entity, as you pointed out. It's not clear to me that, even if you restructure it the way you have, you're getting enough input from that other part of the root server system, because the root servers are not captive the way the IANA is captive under the ICANN umbrella. And so that's -- I'm not sure you're even going to get it even if we adopt all this stuff. >>I take your point about this being not something just for ICANN's consumption, Bill. That was part of the reason for the diagram with the -- this committee having a flow of information, if you like, to root server operators, ICANN, and the community. And I agree with you that the idea that ICANN has the sole prerogative on advice of what's going on in the root system. Again, this is sort of one of the restrictions that we have on us. We can make recommendations to ICANN on the basis of this report. We can't actually make recommendations to other people on the basis of this report. We can't say to ISOC or the Internet activities board "you should be doing this." So the best shot we have is to say to ICANN that this is work that needs done and you're in a good place to do it and you have some money to do it with. And that seems like a reasonable sort of set of recommendations to me. So that -- you know, that was our driver. And I want -- >>BILL: If it makes ICANN happy. >>Well, I would hope -- this isn't all about making ICANN happy. What I would like to think is this is about making -- we have a chance to make some of the root server operators happy. But, at the end of the day, the people that really need to be made happy are the people out there in the community who this is all being done for. You know, this is what we're all around the table for. It's the stewardship of the domain system and so on that we're here to provide for that community. You touched on earlier the idea that your responsibility is to the people who send you queries. You know, the -- that's one of your responsibilities. People in the ccNSOs like me in the NZ space, we're the ones who send you queries. Because we're the ones who are saying please answer a query about domain servers for .NZ, please. >>BILL: Let me look in my mail spool. >>So there's a disconnect for us about who do we talk to? How do we have an input? How do we actually make a connection with each of the root name servers? Yes, we could do it by mailing you individually. But, you know, there may be a better way to do that. >>STEVE CROCKER: You can't do it with the structure as outlined. >>Okay. >>HARALD ALVESTRAND: We have Bruce now. It's on. >>BRUCE TONKIN: Actually, firstly, just a question for Bill. You were saying you have a number of stakeholder groups. And I guess you get requests for information from some of those groups. At the moment are you -- is that communication back to those groups fairly ad hoc? In other words, you're creating a special piece of information just for that group? Or -- so you're kind of creating something more generic that you're sharing amongst a number of parties? >>BILL: Okay. So let me back up. I think that there was a small disconnect. When I say -- when I answer queries. >>I didn't mean DNS queries. >>BILL: I was talking about DNS queries, primarily. For a few other activities, like the Y2K activity, that didn't come out of ICANN. That came from a variety of governments around the world. And we got a lot of phone calls from different government agencies, from different countries. And they all wanted the same kind of information. And so we put some stuff together. And we handed it out and said, "This is what you -- you know, this is the results." And oh, by the way, ICANN got a copy of that as well. When we've had malicious or stupid DNS activity that tends to impact DNS services, we get a lot of queries from things like the press and from other various and sundry people, ISPs and the like saying, "Well, what's going on? Can we help? How do we mitigate this?" So we put things together that's available to a set of constituents, if you will. Depending on who that is, some information is opaque and they get, basically, a high-level 10,000-foot this is what's going on. And in some cases it's very detailed with packet traces. And so the constituents that we deal constituents that we deal with from that side of the root server system, it is imprudent or unreasonable to funnel everything through ICANN simply from an immediacy standpoint. So we need to actually have separate sets of relations with these other constituents and communities. We can't afford the delay. >>So, from your point of view, ICANN would add no value? >>BILL: ICANN adds at this point little value other than it assuages some of the concerns ICANN has about what's going on. It also has the opportunity for having better relationships between the IANA and the root server operators, which used to exist, which doesn't now. >>Right. Okay. But the point I was going to make -- I initially stuck my hand in the queue separate for that question. But I think part of the problem I've observed is that I don't think ICANN as an organization has really had the right interface that it could really have with the root server operators or other groups, including things like SSAC. Because the focus of the board and the organization, if you go back over the past sort of three to four years, there was a year, maybe two years that was tied up around, you know, negotiating changes in the dot com agreement. And we lost a lot of time. And then we had the new gTLD round of 2004, forgetting even going further back just the last two or three years. I think that occupied an enormous amount of time where dealing with some complex decisions around things like triple X and so on. So there was a lot of bandwidth, I guess, spent on those activities. In the meantime, the organization's got substantially bigger. It's now a $50 million operation. And it now has a lot more staff resources than it used to have. I think one of the things the board has been doing in terms of its own strategic planning, particularly in the last six months, is try and say what are the right -- we've got a big board. There's 21 or something like that people on the board. Some of them are voting, some of them are not nonvoting. But, essentially, it's 21 people. Some of those are technical people, people like Suzanne and Steve Crocker and Thomas Narten and others. And others are essentially trademark lawyers or they're ambassadors to governments or have been former ambassadors. So it's quite a diverse board. I think the way the board is structuring itself now is one is it's formed an IANA committee. And I think that would be an appropriate interface for the IANA committee of the board to be able to work more closely with RSSAC. And the other thing it's done is formed a risk committee. What the risk committee is really trying to do is say well, what are the key functions of ICANN? One of those -- one of which is the IANA functions. And what are the things we need to do to make sure that we've addressed any environmental risks and, you know, put any methods to improve management of those? But that risk committee that is an appropriate point to interact with something like RSSAC and say well, what advice do you have for us in this area or is there anything that we can do to assist you in that area? So I think part of it is isn't so much, when I look at these things drawn on an ICANN Web site, at a high level it doesn't look like there's anything wrong. There's a thing called RSSAC, gives advice to the board. What could be wrong with that? I think the real issue is that there's not an agreement work program where the board is able to say these are the activities we're working on this year. We want to have these interactions with these advisory committees and so they can plan their work, we can plan our work, and we can work constructively together. But I just wanted to put that out there that, you know, the board's really changing its structure quite a bit at the same time. >>HARALD ALVESTRAND: I think I would like to relaunch the question that was the initial question that was made by Suzanne in terms of process and that still is not replied. So what did you do in terms of validating your findings with the recommendation? What actions have you undertaken before coming to the final report in order to dialogue with the RSSAC community on your findings and on your recommendations? Which were the results? >>I struggle to put it sort of exact whether it was half way or, you know. But at some point during the process and in January we -- when we went to Minneapolis, the conditions that the meeting sort of gave us or, you know, a number of people in the meeting were very happy to talk to us as long as they got the opportunity to see what we'd recorded about what they'd said. So, basically, they wanted us to come back to them and say, "I'd like to see what you say I said" and validate that on an individual basis. And what we agreed at the RSSAC meeting in Minneapolis was that when we -- there was a number of those we did that on a one-to-one basis. We talked to people, and we sent them back a summary of what our response was or what their response to us was so they could go, "I didn't say that" or "You've got me wrong when you said that" or "you missed this really important point." So we did that. And then, when we actually put together our findings, we had an interim report, which we passed to ICANN itself. And we also sent that report to the RSSAC mailing list. Now, we had no written or verbal responses back on that saying "You've misrepresented things; you've left things out; you have forgotten this; or we forgot to tell you this." And we had one person who actually thought it was the final report and wanted to circulate it further. And we said, "Please don't. Please just hold back on it." So we felt that we had -- the comments that we had made and the -- that we showed earlier, those were all -- those sorts of things were included in there that we'd had these things back from people, and these were the sorts of views we had. We clearly noted that we had this sort of bipolar distribution of views, which was, if you want to characterize it, the ICANN view of the world and the RSSAC view of the world. And there was certainly some crossover between them. But there was certainly a dichotomy of view there. And the result we got back from RSSAC -- I was -- I took -- I have to take no comment assent. I can't do anything else on that one. We did post that one. And we got nothing back saying we got it wrong in our findings. I'd be curious. We spent a lot of time talking about the actual structure of the committee, you know, about whether it should be 9 or would this work in meetings? I will be interested in have we got the goals that this committee should have? Have we got stuff in there that's highly contentious that it shouldn't be doing? You know, we came up with a revised proposed set of changes to the bylaws. And we had nothing -- heard nothing from anybody saying we think that's a wild -- perhaps Steve sort of disagreed in his early comments a little bit. But is that anyway like the sort of mission that this -- a revised group should have? Suzanne, you touch on this notion that people weren't asked what they should be doing. They just were -- here's a set of bylaws, get on with it and you've been chosen. Is this a better fit? Because we spent a lot of time thinking about what those things should be. >>SUZANNE WOOLF: I'm not sure I'm prepared to answer that on the moment's notice. But no, that's a valid question going forward is what's the purpose? What is the -- what should be the point? >>And maybe that's the -- you know, in a way, that one and the issue of staff support for whatever group we have is a starting place. And you then say and the committee -- a committee that's best fitted to execute this mission would look like -- and that's probably -- the answer I think probably lies somewhere between the existing RSSAC membership and something else, this thing we're proposing. It's somewhere in there. There's plenty of other ways you could cut this. You could have 5 root server operators and 5 from the community, but then you get a committee of 11 or 12. And one of the things that you end up with is a bill unwieldy committee. >>SUZANNE WOOLF: I'm not sure reducing the size of the committee is a goal in itself. For instance, part of how we got before we are now is poorly documented, but the rationale does exist that the original constitution needed to be root server operators because, at that time in a different environment, there were not a lot of cross relationships there and a set of additional organizations, as I believe John pointed out, that were closely involved in the work and the well- being of the root server system. There was a deliberate decision taken that, rather than restrict it to individuals, there was a certain -- that the primary determinant of who was in the room was organizational as the organizations -- and the reason why you end up with a somewhat indeterminate roster has to do with the fact that, by and large, those organizations have been left to themselves to determine who was appropriate. And so it's not quite as -- not -- I believe we had -- there -- again, it may be poorly documented. But there has been an understanding of how many in an effort to balance between not forcing people to exclude people who had the relevant -- you know, had contributions but also not getting too unwieldy and out of control. But the point is there was a rationale to who's in the room, which I'll agree is poorly documented but does exist. And I'm not sure that - - and this actually mirrors a discussion we're having within the board about the board review where the recommendations came out regarding oh, this board is too big; it's too unwieldy. And there's a real controversy, a real healthy discussion about whether numbers even belong in the top three criteria of is this a good design? Will this work? >>HARALD TVEIT ALVESTRAND: One point to remember is that the substance of -- recommendation two in the report, which didn't make it into the slides is that the substance of RSSAC's term of reference should be changed. That is, the bylaws need to describe RSSAC completely differently. And I think the text in recommendation 2 is what we should be looking at to see is it the right purpose? And we'll have to take that to the public comment forum and various other fora, I think. There doesn't seem to be any more comments coming, and we're at the end of our allotted time. So I would just like to thank the reviewers for the report and for their willingness to stand up and be held accountable for it. And thank everyone from the community who participated with the comments that we will have to consider in figuring out what to do next. And thank our staff members for doing the support work. And we have to figure out what to do that best serves the interests of the Internet community. Because that's what ICANN is here for. And so thank you, everyone. See you next time. [Applause]