RSSAC Review ICANN Meeting - Cairo Wednesday 5 November 2008 >>PATRICK SHARRY: Good morning, everyone, and welcome. We're here this morning for an open session on the RSSAC review, in just a moment, I'll introduce the reviewers and hand over to them. My name is Patrick Sharry. In conjunction with Marco Lorenzoni, we are the effective staff support for the review. But our independent reviewers are up on the stage here. We also have the chair of our review working group, Harald Alvestrand, over here. And, first of all, I'd like to thank you for your time and interest in coming along this morning. These reviews are a really important part of ICANN's ongoing organizational improvement. And those of you who have been following them for a while will know that one very important aspect of them is that they're quite consultative processes and we're always very keen to get the views of the community. So, again, thank you very much for your time and interest this morning. I'd like on that note to introduce Colin Jackson and Andy Linton, who are from Westlake consulting. I'll let them talk a little bit about their backgrounds and so forth. We're very pleased to have them on board. Just so you understand where we are in the larger process, these gentlemen started work about ten days ago on this project. So we're very much at the beginning stage of the longer process. They would expect to be interviewing and gathering data over the next few months and then preparing a report for discussion at the Mexico meeting in March, and then handing that work over to the working group, who will take that forward and come up with recommendations for discussion in the midyear meeting after that. So, I'll hand over. Thank you, Colin. Thank you, Andy. >>COLIN JACKSON: And thank you, Patrick. And I'm going to -- does this still work if I hold it here? No, okay. I'm going to add my thanks to Patrick's for coming along and listening to us talk about the RSSAC review. Thank you. As Patrick said, this is the review of the RSSAC. The bylaws of ICANN require all the SOs and the ACs -- that's the supporting organizations and the advisory committees -- to be subject to a regular cycle of review. This is the RSSAC's turn. And, Andy. Thanks. If you just keep going, please. Right. As you see, Westlake Consulting, Limited, has been appointed by the ICANN board to conduct this independent review. I should say that Westlake Consulting, Limited, was -- previously did the ALAC review, which was earlier this year. Next, please. Terms of reference, as it says here, were finalized, and they're available on the Web. The terms of reference themselves were consulted by ICANN, and I'm sure that there was input into those from ICANN stakeholders. Just keep going, please. The terms of reference have a number of questions in them. But these are the two overriding questions. And I'll just read these out. Whether the organization -- that's RSSAC -- has a continuing purpose in the ICANN structure. And if so, whether any change in structure or operations is desirable to improve its effectiveness. And these are pretty much standard questions as far as I've been able to determine for any of the ICANN reviews of its component supporting organizations or advisory committees. Now, clearly, the vast has a crucial purpose. Well, when we say that, but, in fact, it's the root servers themselves, which, as we all know, are uttering key to the operation of the Internet. And the RSSAC is a vehicle for those, so for the people who run root server operations to communicate with ICANN and provide advice. So we need to actually make quite clear that we're here to look at the RSSAC. We're not here to look at root server operations, which would be an entirely different question and proposition. We're here in Cairo to meet as many people as possible who have a view about the RSSAC. And that's really why we're standing up here in front of you. That's why we're going around in the lobbies and why we're pestering people and asking you all to come and be interviewed by us. We want to find out what you think about the RSSAC, what you think about the mission that it is stated to have in the ICANN bylaws, and what you think about its effectiveness in performing that mission. And we've got a whole series of questions that we tend to ask people. Please come and see us. It's quite painless. We're going to go, or Andy, anyway, is going to go to the RSSAC meeting and the IETF meeting at Minneapolis in about ten days' time. That's to meet more people who have -- who will have a view about the RSSAC, including many of the root operators. But also, we are expecting further groups of stakeholders there. We're also going to set up an online questionnaire so that people can answer questions and submit their comments to us. We've set up an e-mail address here, which I see, unfortunately, is split across the page, it's rssacreview@westlakenz.com. If you don't manage to get ahold of us, send it off to that e-mail address. After we've achieved all the input we hope we can, which will be around Christmas time frame, we expect to start work on analyzing all the information we've received, looking at a range of options. I can't say at this stage, of course, I couldn't possibly foreshadow what the outcome of the review will be, but we will be considering options for progress and refining those. We will draft a report with recommendations, that's actionable recommendations, as we did for ALAC, that will be submitted and presented at the Mexico meeting. And there, it will be the subject of public debate at the ICANN Mexico meeting. And then it will effectively become the property of the review working group, as led here by Harald Alvestrand, who will run a process from there forth to see what should be done with the contents of that report. And we'll no doubt in due course produce our own report. These are the kind of questions we're asking people. What do you think RSSAC's purpose is? How well do you think it's achieving that? What's stopping the RSSAC from achieving its full potential? Is it the right structure? Is it the right form to reflect the views of the root operators to empower both parties to continue to do their jobs? And who else should we be talking to? Westlake Consulting does have reasonable amounts of experience in this area. The firm is about organizational governance primarily. The principal, Richard Westlake, is an organizational governance specialist of many years standing and is chair and director of many organizations. We're New Zealand-based. That's a nice thing for us. It's a great place to live. But we're globally focused. And we have particular experience with NGOs, and particularly in the Internet governance space. The organization conducted a review of Internet NZ, the ccTLD operator in New Zealand, which is well received and is in the process of being implemented. And I might add, is saving that organization a considerable amount of money, as well as improving its governance. The organization, as I said, also conducted the ALAC review earlier this year. Here's our photographs. Andy tonight resemble his that much, but he tells me that will change. Next, please. >>ANDY LINTON: I don't -- I don't know if (inaudible) or change in the photograph. I don't know which is easier. And here are the other two gentlemen who are involved, Richard Westlake, who's not here, and Vaughan Renner. But Vaughan will be with Andy in Minneapolis in a couple of weeks. I will say a brief word about our individual backgrounds as well. Richard, as I said, is an organizational governance specialist. My own background has been one of working as both a technician and a policymaker, always around the Internet, since its inception. I've worked as a -- as a coder, and I've worked as a project manager, and I have worked as a policy person for governments, and done my best to guide sane policy over the years. And, more recently, I've become an independent consultant, and I work with Westlake on matters such as this. Andy, do you want to say a few words. >>ANDY LINTON: My background is more in a technical background. I have worked in universities and Internet service providers and telcos in both U.K. and in New Zealand and Australia, academic network in Australia, R net, and was involved in building out a number of ISPs and stuff in Wellington. I'm currently working -- my other peels of work that I do is actually work as a lecturer at the local university, teaching network engineering. So I have a background in this stuff which goes back for 25 years. So that's my sort of take on this. I'm also involved in the Internet governance space, because I'm on the board of directors of dot NZ our ccTLD. So I'm involved in setting policy for that. So that's my.... >>COLIN JACKSON: Thanks, Andy. I should say that both of us have quite a history with ICANN, because we've both been involved in the New Zealand TLD for a long time. And both of us were founders of the organization there, and I was president of it for a while. Next slide. Just keep going. Thanks. This is really important. As we are gathering feedback from people, we are giving you an assurance of confidentiality. Our notes are for the purposes of the Westlake team only. They will not be distributed to anybody. They will not be passed to ICANN. Please be as frank as you wish. Okay. So there we are. We're looking forward to this job. We've already started. We're looking forward to meeting more of you. We're looking forward to actually coming up with some sensible, we hope, answers that ICANN can move forward with. Thank you very much. Happy to take questions. >>PATRICK SHARRY: Can I suggest that what might be useful to do now is just to get some views from people around the room on the issues that they believe to be relevant as part of this RSSAC review. You might have a particular perspective on the way that things should work, what the RSSAC should be doing, the way it might be interacting with other parts of ICANN. And we'd be very glad to hear those comments. So we'll start just with that general call for comments. That's fine. Colin and Andy, are there particular questions that you'd like to raise with people? And perhaps see if we can get some responses for those? >>COLIN JACKSON: I think it's -- it's more of an observation, but I'm trying to be a bit provocative. I think it's remarkable that the root servers are flown beneath the radar for so long. Here we are talking about something which is totally fundamental to the operation of the Internet. You turn them off, we might as well just forget about the Net altogether. And, yet, nobody seems to have strong views that they're prepared to share about this. Now, I find that very interesting in itself, but I also wonder what would happen if they did go away and where we would all be at that stage. I wonder if anybody -- if anybody wants to pick up on that point. The root servers -- it's certainly fair to say that of all the component parts of ICANN, the RSSAC is one of the least visible, one of the lowest profile. I don't think anybody could -- I don't think I could be accused of prejudging a review for saying that. It's quite difficult to find any information about it at all. Again, I find this a little curious, given the importance of the root servers to the whole structure. No? >>ANDY LINTON: Perhaps another way to come at this is, are people -- maybe interested in if just, are people content that because this is working apparently well, that if it isn't broken, we shouldn't fix it? Is that the sort of feel that people have? They're -- yeah, it's doing a good job, so let's -- we don't need to worry about it? This would only be an issue if we were here talking about how do we fix things or if things were broken. Is that -- I see a couple of heads nodding on that one, which seems to indicate that at least some people share that view. It's been interesting for us already to talk to a number of people and they say, "Well, our view is, we don't have one, because it's not visible, because there isn't a problem." And that may or may not be the case. But that's people's view on it. I'm guessing that nobody's got any burning sort of issues here, you know. >>HARALD ALVESTRAND: Just trying to be a little more provocative again. This review is -- I'm Harald Alvestrand. I'm chair of the working group that's going to have to deal with whatever these people come up with. But this review about is about RSSAC, which is a communication channel, and whether that is functioning effectively. The larger context includes the fact that ICANN has a mandate from the U.S. government -- we so love those mandates from the U.S. government -- to be responsible for or make sure the root servers continue to work. And so far, it seems that the root servers have continued to work. But what would we do if they didn't? And that's a risk to ICANN and ICANN has a reason to be worried about that. RSSAC is a communication channel. That's enough or that's the right thing or whatever. But if the communications channel isn't working, it's hard to say that we're confident that we don't need anything else. So is it working? Do we need something else? >>COLIN JACKSON: Thank you, Harald. >>PATRICK SHARRY: Just going to ask a few more pointed questions. The first one I'll ask of Dennis. So you better be listening. >> Not even paying attention. >>PATRICK SHARRY: Dennis, in the session that we had a little while ago about the SSAC, you were talking about your experience as an Internet user sitting at home, using your computer. And we talked in that context about how the SSAC work might be relevant. As an Internet user, putting that hat back on again, does the operation of the root servers concern you at all? Would you like to have more information? Do you feel that that -- because in the same way that when you turn the tap on at home, the water comes out, you don't have to worry, you just trust that the root servers are working? Or are there other things that we should be doing on the root server side that might give users more confidence about the stability, security, and so forth of the entire system? >>DENNIS JENNINGS: Thank you for forcing me to pay attention to this meeting. We have technical problems here. We plugged into a mains outlet that wasn't plugged into the mains. As an Internet user, absolutely not. It never occurs to me that this system is broken. It just seems to work. Now, as a perhaps slightly more sophisticated Internet user, I know that -- very sort of high level, I know there are fuzzy things about the domain system, that it's not terribly -- it might not be terribly reliable. And, of course, I am very concerned about that. But as an ordinary Internet user, it all seems to work and certainly the root is entirely visible. But if you were to ask me as an ordinary citizen, should somebody be responsible for this? How is it -- who takes responsibility? How is it managed? And so on, and I was told as an ordinary citizen, or if I was trying to explain to another ordinary citizen, say, my partner across the dinner table, I think I'd have a hard job of explaining how the root system works and that it's hard to explain who's in charge and how it's certain that it will continue to work. I think you've asked the only ordinary person in the street, they would be, as we say in Ireland, gobsmacked that it doesn't look like anybody's in charge of this infrastructure. >>PATRICK SHARRY: Thanks, Dennis. Now, Thomas, you come from a much more technical background than Dennis. What's the technical community response in this area, how does the technical community see the RSSAC organization and what could be different or better? >>THOMAS NARTEN: I suspect that a lot of them see the community as invisible and they don't really even understand how it works or who it is or -- other than it just seems to, which is good in some sense, because it means it's -- nothing has drawn attention to the situation, at least not in a long, long time. Beyond that, I think when you talk to people and probe a little bit and ask them, you know, what is this organization? How does it work? And how is it accountable to the community? And so forth, there are questions that get asked at times, because it's not necessarily clear, you know, how that flows, other than that the people that have been doing so have done so, you know, towards the community for a long time, and there haven't been any real issues with that so far. >>DENNIS JENNINGS: Dennis Jennings again. And putting on a different hat, when I first got involved in the Internet 25 years ago, I was 25 years younger, believe it or not. And in -- >> (inaudible). [ Laughter ] >>DENNIS JENNINGS: And in 25 years' time, if I'm alive, I will be 25 years older. And I won't be involved in Internet stuff, at least I don't expect to be. So if that is a normal progress of human experience, then the people who were 25 years younger when they started this root server stuff will in 25 years' time be 50 years older and won't be around and won't be doing it. So the succession -- as a manager, the succession question is the one. If it's not broken and it doesn't have to be fixed, then what is the succession and what is the plan and who are the actors and is there thinking about this? And those are the questions that I would have as a manager, and, therefore, as a board member with governance responsibility, I need to know who is asking those questions and are there answers coming out of the system? >>PATRICK SHARRY: Thanks, Dennis. And the next question, which leads very nicely on from that one I'll ask of Steve Crocker. Steve, the sort of things that Dennis has just said, to me, start to raise issues of security and stability. In the meeting that we had before this one, we were looking at the Security and Stability Advisory Committee. You might like to comment, if you'd be happy to do so, on the interaction between the work that the SSAC does and the work that the RSSAC does and how that might be different or better. >>STEVE CROCKER: Thank you. Yes. Let me -- I think three thoughts come to mind, and I'll see if I can count all the way up to three. The question that Dennis asked about succession and so forth are root server operation questions, but they are not have been repeatedly informed RSSAC questions. But they are, of course, the important questions that we're most interested in. But RSSAC has got this very limited, bounded role of being -- I think the word that was used, communications mechanism and so there's a difficulty of getting through this process at the larger questions that are the ones that loom. So that was one. Two, we have -- there is, of course, in SSAC a natural territory of saying, among all the security and stability issues, certainly some attention to root server issues would be relevant. And I want to deal with -- I want to respond in two very different ways on some specifics. We had an extremely produce and successful partnership working with RSSAC, looking at a very detailed question about whether there were any issues about adding IPv6 addresses for root servers to the root zone. And there was actually a somewhat surprising amount of technical detail and complexity involved in that because of priming responses and so forth. That issue had lurked and had actually impeded the introduction of IPv6 addresses for the root servers for multiple years, so there was a kind of organizational failure involved in all that. As I said, we had a very successful partnership, ran a study, looked at the details. And the output of that was a big success in terms of exposing the information and unblocking the organizational logjam. And now there are identification addresses in the root zone. So I -- And that process was a joint effort which we very specifically organized. We also have quite a lot of overlap between RSSAC members and SSAC members. So there's no strong membrane that divides us. And they have complete access into what we're doing. And they've appointed me to be their liaison to them. We don't actually have liaisons, SSAC, to other groups. So that's just -- So, in many respects, RSSAC and SSAC have a very natural alliance and shared common background, a lot of technical overlap. That said, there is a flip side to all of that, which is, there are some -- the kinds of questions that you asked, Dennis, for example, are kinds of questions that are the natural ones to bring up. And there is a kind of a restraint that -- I'll just put it in personal terms -- that I feel, in SSAC, to be respectful of the territorial boundary that the root server operators, in general, and RSSAC in particular, set, so that while it might seem natural for us to try to focus a lot of attention on those kinds of questions, we actually hold back a bit. And I'm not sure whether that's the healthiest thing, but that's sort of the pragmatic facts of it. And in a -- sort of drawing a model from the way senators might operate, we kind of respect each other's territory, and there's certain things that we just don't -- have not been as aggressive about that we might have been, for example. >>PATRICK SHARRY: That's great. Thanks, Steve. Just to welcome to the room Suzanne Woolf, who's the board's liaison from the RSSAC. It's great to have you here. And I'll find a good question for you in just a moment. Are there people here who are part of other ICANN organizations, SO, ACs, whatever, who have any experience of interacting with the RSSAC or have had experience of issues coming up within their own organizations where it would have been useful to have an RSSAC input? No? That's fine. Suzanne, I might passion the mike to you, then. >>SUZANNE WOOLF: (inaudible). >>PATRICK SHARRY: Just to talk about from the RSSAC perspective, how you see the relationship with the rest of ICANN. >> While Suzanne collects her thought, I'd like to -- >>BILL MANNING: My name is Bill Manning. I'm on the ICANN Nominating Committee. I'd like to answer Harald's, if I may, question about the communications channel. This morning, I got -- I pulled up the schedule for the day, and I saw that there was this RSSAC review on the schedule. And one of the other hats I wear is a member of the RSSAC committee. And we, as the committee, were blindsided. In fact, I think I was the first person from RSSAC to see -- to recognize and report to the RSSAC that ICANN was in fact initiating this review. So we're not getting a lot of communication from ICANN. So we're not getting a lot of communication from ICANN. As an Advisory Committee, we tend to feel that we respond to requests from ICANN for advice and input, and we don't get very many. The most recent one we received was from Tina Dam regarding IDN deployment, and we provided ICANN staff with that kind of feedback. But we tend not to go looking for things to irritate ICANN. ICANN seems to have a full plate anyway. And so as a communications channel, it seems to work. But we don't get a lot of requests from ICANN for input. >>SUZANNE WOOLF: I think that's actually kind of a good start. I have to apologize for being late. I had some other things I was juggling this morning, and I was caught a little by surprise by having a microphone sort of thrown at me. But with apologies that I didn't hear the beginning of the discussion. I think the existence of RSSAC as a communications channel and as way to get people to talk to each other and as way to define a path for people to talk to each other, I was actually with ICANN when RSSAC was formed, and one of my jobs was to make sure that RSSAC existed as kind of a channel and a way to get this extremely mysterious set of people sort of acquainted with ICANN and make sure there was a pathway there. Such a pathway doesn't have to be used frequently to serve its purpose. With that said, as Bill said, it's not always clear who has the initiative or who has the token. To my as a liaison, I'm sure to the board, certainly to -- not that I am going to speak for all the members of RSSAC, it's not always clear how that communications channel is most effectively exercised. The other thing to keep in mind that's sort of a little bit different about RSSAC is I have been coming to ICANN meetings as the liaison for a long time. I go into meetings, I talk to people. There have been a lot of times I have done formal presentations. There's the record, there's the archive, and there's always a couple other members of RSSAC that are at ICANN meetings and participate with the community in various roles, but there is still a certain sense that there is a very low profile there. And I think that's largely because there's nobody whose company or personal -- employer or personal interests are tied directly to participating in RSSAC or participating in other venues as a member of RSSAC. It does provide a contrast to a lot of the other pieces of how ICANN functions that there's no one whose specific role is advanced by participation as an end in itself, if that makes sense. So it's not always -- It's not always clear -- kind of back to the point of it's not always clear how to effectively exercise that channel. >>BILL MANNING: But it's important to have the channel when it's needed. That's sort of my opinion. If the path isn't there, and if there is a requirement to have something, then building the bridge under fire is kind of a hazardous thing. It's nice to have that path already existing. >>PATRICK SHARRY: That's great. Thanks, Bill. Any other questions or comments for the speakers we've had so far? Colin, Andy, any other questions you would like to raise? >>ANDY LINTON: I think it's sort of before useful just to be a fly on the wall listening to this stuff this morning, because these opinions are not uncharacteristic -- the interviews we have had one on one, we are seeing comments like these, this sort of summarizes at least some of the comments we are seeing. And our big interest is to get as many of those comments as we can to put this together for this. I'm guessing there may be one or two people here who perhaps have some thoughts but are a little reticent to air them in public. They are just sort of shy or just don't want to stand up here and do that, so if people want to do that with us afterwards one on one, we would be very, very happy to hear that. We will find a nice quiet corner and hide from everybody. So if there are people there -- or if this has provoked people into thinking about certain things, then that's sort of useful. >>PATRICK SHARRY: Thanks, Andy. And really following on from that, if there's no more general comments from the floor, we might call the formal part of this meeting to a close and thank Colin and Andy for their time, and also the speakers. As always, thanks to our scribes who do a fantastic job. And we might leave a little bit time. Colin and Andy will be around at the front of the room. If you would like to ask them questions or make comments or anything like that, they would be very, very happy to talk to you. Thanks for your time and interest this morning, and enjoy the rest of your day. Thank you, bye-bye.