SSAC Review ICANN Meeting - Cairo Wednesday, 5 November 2008 >>PATRICK SHARRY: Hello. Good morning, everyone. And thank you for coming here today for our SSAC review workshop. In a moment, I'll introduce the reviewers. But before I do that, I'd just like to say that the purpose for our meeting here today is to provide an opportunity for members of the ICANN community who haven't had the chance to interact with the reviewers in other forums, they've talked to the SSAC people, they've talked to the GNSO and a number of other groups, but today we're here to provide a forum for those people who haven't had another way of hearing about what the SSAC reviewers are doing. Most importantly, for making their views known on these issues. On that note, I'd like to introduce Jeff Schmidt and Bill Yang, who are the reviewers for the SSAC. I'll let them introduce themselves in more detail, give us a little bit of their background. And I think what they're going to do is just speak a little bit about the way that they're going to handle the project and then really turn the microphone over to the floor to have a more interactive session with people, so that you can let your views be known on some of these issues. So thanks again for your time. Jeff and Bill. >>JEFF SCHMIDT: Great. Thank you. And good morning. Thanks for bearing with us for a couple of minutes while we have the first session of the morning jitters. My name is Jeff Schmidt, and I'll be leading the review of the SSAC with the rest of my team, Bill Yang, who will introduce himself in a minute. And then we have a third member of the team, Mr. Dan Distelhorst, whose contact information is up on the board. Just a real quick version of my background. I am a longtime security guy in the technical realm that also became involved later on in the business side and the policy side, running several companies, and running the security testing for Microsoft Corporation back in their first major security push in the mid-'90s. And I'm glad to do this very interesting and very important review. Bill. >>WILLIAM YANG: My name is Bill Yang, and I am here as a governance analyst. I have had a number of roles through my career. I consult through industry, academia, and government. I think probably the most relevant experience that you'll be interested in is that I was the security strategist for the state of Ohio prior to starting as a consultant. >>JEFF SCHMIDT: Just to round out the time, Mr. Dan Distelhorst is a long-term big six or big five, it seems to be shrinking -- consulting on information security audit and compliance issues for 20 years. So with that, we were engaged as of around November 1st to perform the SSAC review. So I want to stress that it's very early in the cycle right now. The methodology for the review will be as follows: For the time between now and approximately the end of the calendar year, we will be in data collection mode. So we are soliciting any and all feedback from any and all vectors and any and all parties that we can get feedback from. To create, really, what is going to be the findings portion of the report. Next year, in preparation for the draft presentation of findings and recommendations at the Mexico City meeting, we will begin analysis in a structured fashion of the data that is collected over this period. For that purpose, we've also engaged an academic expert in organizational behavior to help lend objectivity to what is a rather subjective analysis. So that being said, we are in data collection mode at this point. You have our contact information up there. I would encourage you to feel free to reach out to any or all of us at any time with any additional commentary, thoughts, concerns, issues, observations, that you may come up with. And I guess, first, I'd like to ask if there are any direct comments from the floor, anybody itching to get on the record and kick off the conversation. Otherwise, I'm more than happy to seed some discussion. >>PATRICK SHARRY: Just as that's happening, I just found out we don't have, in fact, a roving mike. I'll try to remedy that in a moment. And for the sake of Laura, who's scribing the session, it would be very useful until I get a roving mike if we can come and take this one to make comments. It makes it much easier for the scribe to understand what's happening and get the input correctly. If anyone would like to make a comment, please use the microphone. >>JEFF SCHMIDT: All right. So between early morning shyness, fatigue, and post-Obama hangovers, I will seed the conversation here a little bit. In the methodology that we're using to approach this, we first need to identify the stakeholders or the customers, if you will, of the SSAC. And so I guess, quickly, by a show of hands, I'd be curious who views themselves as a customer of the SSAC's products, research, documentation, et cetera? Okay. A couple. Okay. So, sir, up front, if I may, who are you and how do you see that as a part of your role? >>GEORGE SADOWSKY: I'm George Sadowsky. I'm an Internet user. >>JEFF SCHMIDT: Okay. >>GEORGE SADOWSKY: And everything that the SSAC does that can help improve security and stability helps me. >>JEFF SCHMIDT: Okay. And -- yeah, go ahead. >>PATRIK FÄLTSTRÖM: You want us to go around the room, like, all of us? >>JEFF SCHMIDT: No. Actually, the gentleman behind you, I think it's ram, raised his hand. So I was -- I know you're a -- >>RAM MOHAN: Yeah, I'm a member of the SSAC. But the constituency that -- or the company that I work with and the registries themselves find a lot of the SSAC work quite useful and direct applicable in, you know, what we do in our business. >>JEFF SCHMIDT: Show of hands, how many of you are directly familiar with an SSAC product, having read, reviewed? >>STEVE CROCKER: You might ask how many are SSAC people here, because we're -- (inaudible) -- we're overwhelming, perhaps. >>JEFF SCHMIDT: Yes, actually, that's a good point. How many are SSAC members? Oh. [ Laughter ] >>JEFF SCHMIDT: As usual, outstanding observation, Steve. Thank you. So of the half -- >> (inaudible). >>JEFF SCHMIDT: Of the half of the room that self-selected as not the SSAC members, how many have direct familiarity with their products? Okay. The multiple products -- can you -- can I ask some commentary on the non-SSAC folks that have familiarity with the products, which ones? What your observations, commentary, thoughts, why you became involved with them? -- two hands there and there. >>WILLIAM YANG: As an observation for the transcription, these are non-attributed comments as part of our analysis. So we can make sure the names do not appear in a transcript. >>JEFF SCHMIDT: Maybe -- this is -- this is an open session, so I guess, if you have comments that you want to have in a nonattribution basis, feel free to e-mail us. And we will make sure that they're in a non-attribution basis in the report. So -- is -- is anybody that has reviewed an SSAC report interested or willing in commentarying on the rationale for their review and the comments about the quality of the report, usefulness, applications? Okay. All right. >>WILLIAM YANG: Obviously, the government users in the room are unfortunately. >>JEFF SCHMIDT: Right. Okay. The SSAC members in the room, the -- the procedures that are used for generating commentary and generating the SSAC products, like some thoughts or seed some discussion on how individual members of the SSAC feel they have contributed, been heard, have reviewed, have buy-in or signoff on the products that have come out of the SSAC. Anybody? Okay. This might be a long morning if it's just me talking. Okay. Would someone from the SSAC like to describe the process for generating reports? And how the products of the SSAC are produced? Steve. >>WILLIAM YANG: Come up and join us, Steve? >>STEVE CROCKER: I suppose I can do that, too. This wasn't planned in advance. This was nonscripted. This wasn't planned in advance and might look scripted here, but it's not. I truly didn't have a sense of what was going to happen here. But the -- and I'm a little bit reluctant to speak too much, because I'm clearly on the inside of this process and have shaped it quite a bit. So my view is skewed by, you know, looking at it from the inside. The committee was formed with the idea being a set of outside experts that would be able to respond and comment on whatever security and stability issues might come up. In practice, we have focused on one topic after another, usually around incidents that some event externally that's happened. Much less have we focused on a strategic, broad vision. We try, every once in a while we do that. But the vast majority of what we've actually done has been focused around very specific, I'd say event-driven, situations. And the participation from the committee has been relatively little, I would say. We have 20 or so people. We usually only get a handful of people, at most, responding vigorously, and only briefly. And then for the past few years, we've had the benefit of having an extremely strong staff person, Dave Piscitello, do a tremendous amount of work, both the research and the writing. And I've been heavily involved in trying to guide those reports, and pretty strongly, almost uniformly, editing and reviewing and so forth, so that -- but the consensus has been a lightweight process, if you will. Now, once in a while, there's enough discussion where there is serious interaction and sometimes differences of opinion, in which case we tend to take a conservative approach and try not to exceed the bounds of what the comfort level is with -- excuse me, within the committee. I don't know if that's enough of an answer. Feel free to push again, if you want. >>JEFF SCHMIDT: Any commentary from the committee members on the formulation process? >> Security work tends to be close (inaudible). >>PATRIK FÄLTSTRÖM: You have to go to the microphone. >>JEFF SCHMIDT: It's -- >> Sorry. >> Bob Hutchinson. Security work tends to be closely related to events. And the people who have knowledge of things and the ability to communicate them in a technical way are very close to those events. And the SSAC has leveraged, I think, that relationship into a positive thing for ICANN with finding the right experts and getting them to produce reports which are a value to the ICANN community. I've learned a lot and understood a lot more about phishing attacks and fast-flux attacks. I mean, the list is fairly extensive in terms of what has been covered in the last three years that I've been listening to SSAC reports. So you really have to understand the security community and the nature of the technical work in order to understand, I think, the process that the SSAC has kind of bottoms-upped into in order to -- it's not something that, typically, you could put out a request for comment on the ICANN Web site and get quality information. There are certain areas of what SSAC does that you can do that. But, typically, Steve and his group know the people or know people who are close to the security breach problems, and they to a very good job, I think, of bringing that information to ICANN. And without coloring it too much, getting the information to ICANN and the people who are interested in that information, communicating in a non-finger-pointing fashion. >>STEVE CROCKER: Before you go away, one of the things I think is absolutely vital in this process is to find out the limitations or the deficiencies or missed opportunities. I mean, I'm -- I can say without any hesitation, I'm quite proud of what we've accomplished and the things that we've done. And having said that, I want to just dispose of that and not dwell on that, because I think the real focus is -- and the purpose of this external review process and independent review process is to ask the hard questions rather than just try to focus on the positive accomplishments. So what things would you, if you could imagine better or different or more, would come to mind? >>BOB HUTCHINSON: I think the full stem-to-stern review that you're starting now is a very good approach to providing a framework for people to understand the kind of panoply of security issues for ICANN and the Internet in general. I don't believe anybody has done that. And that, I think, will go a long, long way if there is some, like, overall backdrop to -- a way of cataloguing the security issues, a way of speaking about them, sorting them, figuring out what the relationships are with the other organizations. That's a huge thing. 'Cause if we're talking about, say, for example, phishing, okay, the number of security organizations -- and just Google antiphishing, for example -- the number of security organization in the world who could be involved in information about antiphishing is probably pretty significant. And you look at all of the different security, you know, holes in the hull, so to speak. There are a lot of private groups that have grown up over the years that work in these areas. And I don't think any of us know them all. I mean, we know them kind of by -- by fiat, by event, okay. And -- so I think that's a really good place to start in terms of, you know, having structure to the whole thing. I know Steve many times has said, "We don't address the whole thing. But it is not clear what we do address and what SSAC is sort of, you know," -- you know, where they're a chicken, where they provide an egg, and where they're the pig and they provide the entire ham, okay, where they're committed to -- [ Laughter ] >>BOB HUTCHINSON: -- to things. Okay. >>JEFF SCHMIDT: Clarification. Are you suggesting a product or a line of research from SSAC in this holistic sense? Are you suggesting a change or amendment in charter or focus? To be more broad? What.... >>BOB HUTCHINSON: (inaudible). >>PATRIK FÄLTSTRÖM: You have to use the microphone. [ Laughter ] >>STEVE CROCKER: I think there's other people beyond this room that we're also speaking to. We're going out on the Web. >>PATRICK SHARRY: And being scribed as well. >>STEVE CROCKER: And being scribed. >>BOB HUTCHINSON: I guess my experience with looking at SSAC reporting and so on, so forth, is over the last three years, it has become much broader and much deeper and much more helpful in terms of the communication of what are the risks, what are sort of being done about the risks, and the advice that's being given to the ICANN board. So I think Steve does have a right to be very proud of the way that SSAC has been -- has grown over, you know, my -- I don't know what it was before. So I guess, you know -- I think it's headed in the right direction. But, you know, organizationally, if you wanted to -- there is always the problem with the information that the SSAC is dealing with, is that they only are the court jester. They only can communicate the information. They don't really have any organizational back. Maybe Steve can address this. Because I don't really understand how you actually get things to happen. But it's more like, "Here it is." And then people are expected to do the right thing with that information. >>STEVE CROCKER: Just on that small point, one of my standard lines, you know, introduction is, emphasizing the advisory role that we have, and that we put out the advice, and then it's for others to pick that up. More recently, there's been, internally, some question about whether we could improve that cycle, measure the response or do follow-up sorts of things. But there's no mechanism in place. And so that's a legitimate and, I think, helpful area to shine a light on and to ask some questions about, structurally, whether or not there's enough pieces in place or whether more should be done, or whether or not having kind of an open-loop process that is inherent in the fact that we just give advice and there is no requirement for anything to happen beyond that is maybe as healthy as, I mean -- now getting into philosophical issues about how you design organizational systems. >>HARALD ALVESTRAND: So I am Harald Alvestrand. I've been an ICANN board member. And after becoming an ICANN board member and consumer of SSAC's input, I also got co-opted into being an SSAC member. I just point an oddity in the way that SSAC does things, which is that SSAC tries to identify I think, security issues that are -- have some relationship with ICANN. But the way it does it is to identify security issues, and then try to figure out where it has a relationship with ICANN. So a lot of what I have seen SSAC talk about has a limited applicability in that after we talked for a while or after SSAC has produced a report, a conclusion might be that, okay, this is a problem. It's not ICANN's problem. I think that's actually a right way of going about things, because it's hard to know when starting to investigate an issue whether it's ICANN's problem or not. And, you know, ICANN has a lot of contacts. So sometimes things can be ICANN's problems without being ICANN's problems to solve. But if I were to take issue with the quality of SSAC output, the things I've read through as a consumer, not a member, it will perhaps be that it needs -- I would like to see some clear identification of ICANN actions to be taken and where and ascertaining that those actions suggested are, indeed, within the scope of ICANN's mission. Information is very good to have. Quality information is even better. And SSAC's reports are made public and available to others outside ICANN who can sometimes take action. But as a function for ICANN, reporting to ICANN board, we perhaps need a little tougher advice on exactly what is it ICANN is supposed to do about it, or identify clearly that ICANN can't do anything about it. It can bemoan and exhort and ask other people to behave sensibly but can't do anything. It's an oddity, and it's something that can strike people as an oddity in the way that SSAC operates. And I think it's an okay way to operate. But it needs to be taken note of. >>JEFF SCHMIDT: If I may ask a follow-up. It is it your observation that policy recommendations are being made and not followed or not being made? >>HARALD ALVERSTRAND: I would hesitate to say that there's a yes-or-no on this one. There are certain issues. My favorite issue is WHOIS, where for reasons that are entirely outside of the range of what SSAC is supposed to be involved in, ICANN is behaving -- well, a polite way to describe it would be like a chicken that has a head cut off. And that's a polite way. And on those issues, the problem is not that we don't have advice. It's that we are incapable of, as ICANN, incapable of coming to -- incapable of reaching political conclusions that are rational. So the biggest problem is not that we don't get policy advice from ICANN. In case of executing, the problem is sometimes that we are unable to follow it for other reasons. Was that an answer to your question? >>STEVE CROCKER: Let me offer a comment or two. The WHOIS, I share your vexation, and you and I as board members have some common cause to try to get the chicken oriented. And from an SSAC perspective, we have watched this process -- this evolve, and have looked to see where we might be helpful. There's a forceful statement brewing, and we'll come back. But I think your other remark is worth a little bit of illumination. Without any sense of being defensive, I want to shine a light on what we think we're trying to do and invite you to, with the community, to look very closely, because I think this would be very helpful. In form, at least, our reports have a descriptive area of section, and then they have two definite sections, one called Findings and one called Recommendations. And the recommendations are, at least in principle, at least by what we think we are trying to do, have not only action items but also a specific audience in mind. So although we're chartered by the board and, in principle, give advice to the board, there is common understanding up and down through the system, and particularly understanding within the board, that the board itself is not the actor -- it can receive this, but mostly what the board would do is pass things on. So we aim our advice towards specific audiences. So we might in a particular report say we recommend to the registrars the following, we recommend to registrants the following, we recommend to registries the following, we recommend to different communities. And the general response from the board when we haven't done this is to say, well, who should we send this to? So there is, at least as a matter of attempted structure, is to say where things are supposed to go. And we're attempting to tighten this up a little bit. But I think a really helpful thing would be to get some feedback in this process on how effective that's been and whether there's any ways to improve all of that. And I'm sure there are. I can think of several, and so forth. I think that's a helpful comment. But I would want to emphasize that the relationship we have with the board is a sort of de jour one of that's who we report to. But in all practical terms, we actually speak broadly to the full spectrum of ICANN components to the staff, to the supporting organizations, to other Advisory Committees, and, indeed, even outside of the ICANN official structure to the broad Internet community when it's appropriate. >>JEFF SCHMIDT: I would like to invite additional comments on the topic of . >>GEORGE SADOWSKY: On the topic of what? >>JEFF SCHMIDT: On the topic of the format and packaging of advice. But whatever you were going to say would be just fine. >>GEORGE SADOWSKY: Well, I should preface this by saying I am not an SSAC member. I am not a security expert. I have been in this business a long time, and I have some sense of what ICANN is trying to do. I would hope that your terms of reference which we have, and we haven't talked about, would be somewhat liberal and elastic in terms of your ability to address the entire issue of ICANN's goal of achieving security and stability of the Internet. To put that in context, ICANN does a lot of things. One of the very major things it does is provide what I characterize as soft regulation of the domain name industry. And it spends a lot of time doing it. A lot of its budget is allocated to that. A lot of issues that come up come up because of this industry structure which I guess is an unanticipated consequence of the whole Domain Name System. On the other hand, the SSAC and direct security issues seem to occupy a much smaller part of ICANN's consciousness. And I would hope that you would look at the importance of what the SSAC does relative not only to internally what it does and how it does it under its current mandate, but what it might be doing under a different allocation of priorities within an ICANN context. And even within the entire issue of cyberspace and cybersecurity. I don't have any issue with the quality of what comes out. It's the question of should more be done. Should the approach be different? Should ICANN impute, I'm not sure in what ways, but should it impute more importance and more significance to the output of the SSAC or an expanded SSAC or a different SSAC? How important is this, and are we really doing enough in this area? >>STEVE CROCKER: So don't be bashful. Go beyond that from the question side in generic form to what specific kinds of things come to mind. >>GEORGE SADOWSKY: Steve, I don't have specific things. But what I see is that this looks almost like a peripheral organization to ICANN whereas the domain name industry gets a lot of attention. I think this should get all the attention. >>JEFF SCHMIDT: It's an interesting comment. So as a -- In your role as an Internet user, do you perceive SSAC as external to ICANN, operating independently of ICANN, internal to ICANN? Where are you on that scale? >>GEORGE SADOWSKY: It's clearly internal to ICANN, but what I don't see is there isn't -- the focus is less on this part of ICANN's way of achieving its goal of security and stability and more on the industry, the registries, the registrars. Now, they are important, too. But the -- There are numbers of -- how do I say this? There are quite a few issues in security and stability of the Internet that should be addressed independent of the structure of the DNS and this domain name industry. I'm not sure that people who made up ICANN impute the same value to the output of security groups like SSAC as I do. And I would really like to -- I hope that you would have elastic enough terms of reference so that you could look at that question directly and ask is ICANN paying enough attention? -- This is not the way you would phrase it, but is ICANN paying enough attention to the technical issues, to an examination of the technical issues within security and stability, independent of the other parts of its concerns. Steve, does that get to your point or not? >>STEVE CROCKER: No, there's more to be said, I'm sure. >>GEORGE SADOWSKY: You can say it better than I can. I leave it to you. >>JEFF SCHMIDT: Yeah. >>DENNIS JENNINGS: Dennis Jennings is my name, and I would like to speak as an ordinary Internet user. I'm on the board, and I'm very interested in security, and I try and work closely with Steve. But back home, I sit at my PC and I'm an ordinary Internet user. And I have a frustration about the system, whatever it is, that seems to talk a lot about security and talk about how difficult it is to deal with these things. Yes, WHOIS is difficult, but we have to do studies, and I'm saying yeah, but I think it's risky. I don't trust it. How difficult it is to deal with Spam, and apparently that's something to do with Fast Flux, but everybody says that is difficult, and so many things depend on it, we can study it. I just have a sense of frustration as a user that the world has gotten very unsafe on the Internet and no one is doing anything about it. Now, as an ICANN board member, I recognize that's not necessarily ICANN's job. But as a user, I am frustrated, well, who is doing about it, who is providing leadership, and how are these problems going to get fixed? I have a concern that organized crime has won the cyber world battle before we even know there's a battle taking place. >>STEVE CROCKER: I think you are, in a way, following up on the points that George was making. I'm going to succumb to the temptation. I agree with you completely about the sort of lassitude and difficulty of getting from recognition of a problem to some useful action. And so succumbing to the temptation, I can say I long for the day when I or somebody can sit in a place like this and say, "Yes, we can," instead of, "Gosh, I wish we could." [ Laughter ] >> (inaudible). >>STEVE CROCKER: Yeah. >> So what is SSAC's role in addressing that? >>PATRIK FÄLTSTRÖM: Patrik Fältström, SSAC member. I think one of the problems that I feel as a member of SSAC that we end up into is that people say, "Oh, we see this problem with the Internet and my Internet doesn't work. Can you please write a report why my Internet is broken." And of course if you get that kind of question every week, that's kind of frustrating because you would like to write reports on more focused things. So one of the issues might be how do we get from those overall requirements -- for example, "Fix the Spam problem" -- to maybe write a report on what is Fast Flux, what kind of impact might Fast Flux have on the Spam problem. And I think the latter is something that it could be like -- that's what we are sort of trying to write about, from my point of view in SSAC; reports that are related to the work of ICANN that has to do with the security and stability of the Internet. So it is frustrating, of course, to have to say no to people who want to get help, so maybe there can be 15 other different kind of SSAC groups in the world that people can contact. But the work in SSAC, I think, is more effective when we can focus, really write reports. All of us members have other day jobs, which means that our time resources are limited. We have excellent staff that help us do the actual work, but still, working on few reports, trying to create them, push the reports out the door and then start with the next one. That is from my point of view the most effective one, effective thing. And to a certain degree that we are discussing, how do you decide what kind of reports SSAC is going to right. And that's a discussion that maybe we should have a little bit more. >>JEFF SCHMIDT: So parsing the last several comments, I'm observing a commonality that there's an observation that the scope and the breadth of SSAC should be increased. I've heard various flavors of help desk for the Internet to solving all cybersecurity problems. Is that a fair observation, just from the flavor of the room here, that there's a general consensus that SSAC should be doing more, for lack of a better term? Have a broader scope? >>PATRICK SHARRY: Dennis, I will bring you a microphone. Dennis Jennings again. Well, yes and no, Jeff. Yes in that I think those -- the advice part should be broadened, but no -- the SSAC is advisory. It's a committee of volunteers. There is something missing when you try and parse what we are talking about, our concerns and what SSAC is, there's clearly something missing. We can't expect SSAC to have a broad a remit as I would like. The question is, should the issues that SSAC provides advice on be broadened? And to the extent that's reasonable and possible, I would say yes. But I think there's some other missing elements. I don't know what they are, but I think there are missing elements. >>PATRICK SHARRY: Thanks, Dennis. >>JEFF SCHMIDT: Missing elements from an SSAC perspective or from an ICANN perspective or from a global Internet perspective? >>DENNIS JENNINGS: Well, I think George is going to answer it, and I would like to get George to do it rather than me. >>GEORGE SADOWSKY: Certainly the kinds of things that SSAC are doing now, the quality of what they are doing, is not the question. I think it's the quantity and the support that they are getting. SSAC is, as Patrick notes, a collection of volunteers. But with one very good staff person in ICANN. And a question I would put to Steve or other people on the SSAC is, if you were to collect all of the security concerns that were really relevant to ICANN's goals and functions, how many staff people like Dave would you need to be able to address them adequately in a timely fashion? It's a resource question. >>STEVE CROCKER: I actually can try to respond to that. We have had some discussion, actually, about that line. The asked the question as a pure, sort of homogeneous, quantitative kind of question, which is a perfectly reasonable question, but let me broaden it slightly that there is also the qualitative issue. One of the perceptions that I have is that many of the security issues and stability issues that come into being have an economic or game theory aspect to them that come directly from the way the rules have been crafted. Not necessarily intentionally. Sometimes they are just unintended consequences. One example is the add grace period which was intended to be a way of helping users who made typographical errors. It turns out to be a loophole that caravan trucks have gone through. And from a stability point of view, it's caused orders of magnitude more registrations to be added on the registration side of registries. Now, the main registry that is involved, of course, is VeriSign's operation, and they have elected to staff up for it and bulk up for it rather than push back. But standing from my perspective of just looking at this from a system stability point of view, it's absolutely crazy to put 100 to 1,000 times the load on something and then expect it to remain stable and without any additional revenue associated with it. That's something that is intimately tied to the way the rules the written and not to a sort of intrinsic issue there. So when I think about SSAC structure and who is on SSAC and the way with things, it's occurred to me, and this is just a point of discussion, whether we ought to have micro-economists, for example, a totally different skill set. Taking the same theme but in a much narrower sense, there are issues of IDNs where we haven't had the breadth of skills that would have been helpful to have to respond more fully. So the question that you are asking about more staff, I think the answer is yes. If you ask me to come up with a number, maybe three. Two certainly would be a huge change. And would I want a very large staff? Then would be getting into a very different sort of thing where we would have sort of a standing bureau of writers. Having diversity for all sorts of reasons of just stamina and internal biases and so forth would certainly be good. So qualitative change would happen if we had two to three people like Dave instead of just one. >>GEORGE SADOWSKY: So, in fact, you provided a partial answer to Dennis's question. >>STEVE CROCKER: Yeah. >>JEFF SCHMIDT: So we have just a couple of minutes left, and I wanted to ask specifically for -- Ram, you had your hand up. So I want to ask specifically for recommendations. How can we make this better? What would you like to see in the report? What strings should we pull on as we continue this investigation in the time that we have left? >>RAM MOHAN: Thanks. This is not specific to your question, but I just had some quick comments to add on the record. I have heard several organizations and constituencies comment that SSAC should focus its attention on the domain registration process quite a bit more and less on how domains get used after they are registered. Several constituencies are on the record stating that issues such as phishing or Spam should be left to the general security community and should not be part of SSAC's remit. So I am just communicating it rather than stating it as my own point of view, by the way. Other groups have also commented that SSAC ought to watch a recent trend where some folks within the ICANN process take some of SSAC headline -- the headlines from SSAC reports and then try to implement policy rather than necessarily follow through on the SSAC recommendations within the reports. And one of the examples that was brought up just a couple of days ago was the Fast Flux policy development process when, again, the comments indicated the SSAC report itself did not say that Fast Flux was a universal threat. So in summation, I have heard several policy-oriented individuals inside the ICANN community suggest that one of the key distinguishing factors in the kind of work SSAC ought to do should be based on whether the problems that SSAC is looking at are part of the domain registration process or are they a part of the domain use process. >>JEFF SCHMIDT: Any other commentary that.... I'd like to ask specifically, are there any additional thoughts on the point that was just raised about scoping of domain registration versus domain use? Any specific comments or thoughts on that. >>PATRIK FÄLTSTRÖM: Patrik Fältström. I think lately I heard more and more people talking about the domain use and security regarding those kind of events. And while earlier there was much more discussion about domain name registration. And that might be a change that we are currently seeing. More and more businesses and domain name holders are worried about losing their domain name, for example. That wasn't something I heard so much about five or ten years ago. >>PATRICK SHARRY: Jeff, can I suggest that we might just take any general comments from the floor for the last minute or so? >>JEFF SCHMIDT: Yes. >>PATRICK SHARRY: And then it's about time to wrap up. So if there are any other views that people would like to make known. You might like, while we're doing that, just to get your e-mail addresses up on the screen there again. So thank you very, very much for your time this morning. Thank you, Steve, for hopping on the stage there and helping us out. That was very useful. Thank you very, very much. A reminder that we are really only at the beginning of this process; that Jeff and Bill and the rest of the team will be looking for inputs over the next few weeks. On the screen there we have their e-mail addresses. As you have seen this morning, they are very reasonable and approachable people. They would be very willing to have a conversation. If you would like to arrange an interview time or something like that, they would be happy to do that too. And we do look forward to their work over the next few months. The plan is that they will have a draft report for us to discuss at the Mexico meeting. And then the working group will move forward after that time to consider recommendations and implementation. So again, thank you very much for your time this morning. Also, as always, thank you to our scribes who do a magnificent job. And I hope you have a good day on this very wonderful day.