SSAC opening meeting. Sydney, Australia. 22 June 2009. >>STEVE CROCKER: Good morning, everybody. This is the open meeting of the Security and Stability Advisory Committee. When we were originally scheduled into this slot, a couple of ICANN meetings ago, I thought that it was like being banished into purgatory or something and we were pleasantly surprised with the rather strong turnout, and we have stayed in this slot and it has continued to be a good way to start off the week, I guess. Or maybe there's just nothing else going on and everybody is so out of phase that they can't get any sleep. But I'm absolutely delighted to see everybody. We have -- we're packed into a very tight hour, so I'm going to move right along. And I see I've already forgotten something, which is to plug in the screen. And momentarily here, things should resize. How's this going to work? Okay. Sorry about all that. We have quite a few people from the committee here. I've listed just the people on the executive team. We've been driving the executive team quite hard with the weekly meetings and monthly face-to-face meetings, all of which is basically administrative overhead of pushing agendas along and so forth. Is Ray here? >>RAY PLZAK: Yeah. >>STEVE CROCKER: Hi. Ray Plzak and Ram Mohan and Dave Piscitello and Jim Galvin. Jim's there? And Jim is in the process of rotating out, and Julie, sitting next to him and conveniently positioned to race screamingly out the door, as she understands what she's getting herself into... Good. I'm going to have a series of presentations, and in my haste to put this together, I think I left one out on orphan domain names which Ram will take in the next-to-last position, and what I want to do is just move rapidly forward. So let me -- I'm sorry. Dave will present. Let me move to Ram, and I've got all of these on here, and so you can just tell me to push the slides. Well, I'm sorry. Two more things. We're having a number of internal meetings or presentations to other groups, and then this little -- a little smaller to read than I'd like, but there are four other meetings that are of potential interest to the audience here. There's a root scaling study presentation at 6:00 p.m. tonight. This is a jointly sponsored study with the Root-Server System Advisory Committee, ICANN staff, IANA folks, and SSAC, on what happens if the root is scaled up and the various complexities of IPv6, DNSsec, IDNs and so forth all colliding at one place. There's a -- a presentation tomorrow evening at 6:00 on internationalizing registration information, a lengthy DNSsec workshop Wednesday morning -- essentially all morning -- and then a forum on the abuse of the DNS, really using DNS for other forms of abuse, I think, Thursday at 2:30 in the afternoon. All of these should be on the program printed and I'm just mentioning them here for -- to bring them to your attention. >>JIM GALVIN: Steve? >>STEVE CROCKER: Yes. >>JIM GALVIN: If I may, one update to your list there. The root scaling study is at 4:00, not 6:00. >>STEVE CROCKER: Thank you. Was I working from stale data or did I just completely get it wrong? >>JIM GALVIN: Probably working from stale data. >>STEVE CROCKER: Yeah, all right. Apologies. 4:00 this afternoon for the scaling study. Thank you, Jim. Okay. So with that -- and now what I've got to do is find the right one here. I think this is what we want, right? >>RAM MOHAN: That's the one you want. >>STEVE CROCKER: Okay. Over to you. >>RAM MOHAN: Thank you. Are you going to run this? >>STEVE CROCKER: I am. >>RAM MOHAN: Okay. Fantastic. Next slide. So we're talking about internationalizing registration data. This is not a -- what SSAC is talking about is not about WHOIS itself so let's not confuse this about WHOIS. What this is about is domain names with further internationalization. Of course at the top level, there are labels that are going to be internationalized. ICANN is going to, you know, provide an opportunity for folks, countries as well as regular gTLD operators, to get domain names in an internationalized format. But the problem space that we're looking at is that no guidelines or standards actually exist for how the registration data should be represented. This includes contact information, DNS configuration data, the name of the sponsoring registrar, the status of a domain name. So imagine a future where you have a domain name. Potentially you can type it in and you can -- you can look it up in the WHOIS, except the response that comes back in the -- as far as the registration data is concerned is all in a language that you cannot read. And there is nothing uniform about it. If you could go to the next slide, Steve. The question is: Is this a brand-new problem or are we evolving? You know, clearly internationalized registration data as a problem has existed for a while. It's not a new problem. And it does -- certainly is not caused by IDN TLDs. We're bringing it to the community's attention because we think that with IDNs getting far more acceptance and potentially more adoption, we expect that this problem is going to become mainstream. And so that's why we're bringing it in front of you. On the next slide, what we talk about is how WHOIS itself works today. Today, if you go to the WHOIS service, and if you are a user who submits an A-label -- so, you know, something that is written in ASCII or a U-label, a Unicode label -- to query the WHOIS, what happens is interesting. If you go to the command line, WHOIS Port 43 interface, well, it can only handle ASCII. So you're going to get back xn-- for the domain name for whatever label you submitted. You're not going to get the local representation. The question is: If the registrant name is in a local language, if the domain sponsor, domain name sponsor, the registrar, is in a local language, what are you going to get back? There is really no standard. There are no guidelines for that as -- at this time. As a result, what we are concerned about is that operators -- registries, registrars, resellers, the entire -- and the entire marketplace -- might end up adopting completely varying sets of guidelines and representations how to show the data, how to display the data, how to accept the data, how to store the data. And the effect of that could be significant. If you go to the next slide, which we're going to skip. And the next one and the next one, which we're going to skip. >>STEVE CROCKER: I've lost track. >>RAM MOHAN: There you go. That's the right one. What we're talking about is we're concerned about issues in three specific areas. In the user experience area, what we're wondering is: What are the -- what kind of Internet user experience is appropriate when registration data is internationalized, and when display, you know, comes through in multiple formats? And are there any general principles that the folks who store the data and display the data, are there general principles that they ought to follow? And should there be uniformity of information display in. On the next slide, we're also wondering about the issues that may come up from data reliability, accuracy, as well as operational issues. ICANN has begun a program -- and I think there's a session at this Sydney meeting about WHOIS data accuracy. That's a good thing, to check whether the WHOIS data is accurate, but that kind of makes a core assumption that one can comprehend the data that is there. And there is a possibility here that that comprehension level might go away. You know, lacking some uniformity. And for the folks who regularly use the WHOIS and who use the registration data associated with the domain name to make decisions -- and this is not -- you know, folks in law enforcement, IP folks, folks at ISPs who look up name servers, you know, to troubleshoot problems, if they cannot understand what's being -- what's being shown on the screen, and if they cannot reproduce it in their own keyboards, their own representations, what kind of reliability and operational issues might arise. And the last area on the next slide that we cover are security and standardization issues. Should there be some base standard in terms of the languages and scripts that should be permitted? You know, should there be some -- some core, you know, "all registration data must be submitted in the following way, in the following languages or scripts"? And also, we're not certain that sufficient submission and display practices actually exist for applications that bind the register domain names to information about the registration data. And, you know, we're wondering. We've had folks say, "Well, maybe some set of core information must always be submitted in U.S. ASCII," but, you know, there is, again, not any standardized methodology for it or a guideline that drives us this direction. So having looked at all of this, we're making a few recommendations on the next slide. We're asking the ICANN board of directors at this board meeting in Sydney, we're asking the board of directors to task the GNSO, ALAC, ccNSO, GAC and -- can you hear me? Okay. That was spontaneous. Does that one work? >> It was working fine. That was the problem. [Laughter] >>JIM GALVIN: We should probably keep going, though. The audio cast hasn't been working. >>RAM MOHAN: Yeah, I think it's the audio cast and for the interpreters, do they need to hear it on the microphone? >> And the scribes. >>RAM MOHAN: And the scribes, of course. Can you hear? No, they cannot hear. >> It's rebooting. >> Rebooting? [Laughter] >>RAM MOHAN: Okay. Oh, excellent. So just to recap, we're -- SSAC is asking the ICANN board of directors to -- to form a working group, to study the feasibility and suitability of introducing display specifications and guidelines, to deal with internationalization of registration data. We're certainly also suggesting that it's not only the folks up there at GNSO, ALAC, ccNSO, GAC, and SSAC, but also to reach out to ccTLD operators as well who -- you know, who may not all be represented in the ccNSO, but to actually, you know, go and pull those folks in because this is a -- this is a problem that spans, and it's beyond just the folks who are every day involved in the regular ICANN community. So that's what we're asking the ICANN board to do, and on the next slide, what we're suggesting -- and this is kind of a draft charter, if you will -- we're saying, "Should there be standardized internationalization of registration data functionality? What should it be? What are those guidelines?" And then "How does ICANN actually then go about implementing this and making sure that some level of uniformity actually happens?" The second bullet has some examples and some thoughts, but that certainly is not a recommendation from us. It's a -- a helpful, you know, jump-start for the discussion. So we're doing that. In addition, ICANN has taken these recommendations and is hosting a birds of a feather session here at the ICANN meeting, and we invite those who are interested to come in and participate. This will be, you know, a way to kick off this entire exercise. With that, I'll hand it back to Steve. >>BILL MANNING: When is that birds of a feather session, Ram? >>RAM MOHAN: Jim, can you help? >>DAVE PISCITELLO: It's Tuesday night at 6:00. >>STEVE CROCKER: Tomorrow at 6:00. >>BILL MANNING: Tomorrow at 6:00. The second thing is, Ram: Is there anything that would prevent a generic top level domain from selecting an alternate script other than U.S. ASCII? >>RAM MOHAN: As far as I know, there's nothing today that says that it cannot be using another script. Now, the contracts for a gTLD operator, a registry operator, the contracts spell out U.S. ASCII in them, but if you look at many of the registries that do offer IDN registrations, their registrars accept localized information and we don't know how exactly they are displaying it. >>BILL MANNING: Then you should probably put -- either remove ccTLDs from your list of invitees and just put TLDs. >>RAM MOHAN: You know, it -- and so the answer is yes, and the answer is that for saying both cc's and g's which kind of means all TLDs, right? >>STEVE CROCKER: Thank you. Other -- other questions? Great. Thank you, Ram. That was a great presentation. Let me move on to a somewhat different topic, and turn things over to Dave Piscitello. I'll just let you introduce the topic and move forward. >>DAVE PISCITELLO: Good morning. I'm going to talk today about an effort that's been, you know, a work in progress for nearly a year. And there was certainly, you know, significant work that SSAC did on this subject for several years prior. One of the recurring themes in -- you know, in security and in attacks against registrants is the exploitation or misuse of registration services. I think one of the first reports that I worked on, you know, when I joined SSAC was a domain hijacking report. Hijacking is one version of abusing a registration service, and attacking registrar -- registrar account portals. There are many others, but what we've found is that these attacks have become more and more worrisome and they've been escalating in the numbers and frequency have been -- you know, have been growing and become a growing concern. So we reopened this study approximately midsummer last year, coincidental -- one back -- coincidental with the attacks on ICANN at the Paris meeting and on Comcast very closely following that, in the summer 2008. At least summer in Paris time. There were several other attacks against, you know, some fairly high- profile targets. CheckFree, Photobucket, RedTube, in November of 2008, in February 2009. There was a very, very noteworthy event in April of 2009 when a registrar was attacked through a Web application vulnerability, and a significant number of their customers under dot co dot nz were hijacked and subjected to defacements of -- you know, of, you know, names under that label. So, you know, we've been monitoring this for quite some time and what SSAC, you know, has been doing in that period of time is discussing with registrars involved, discussing with the -- the targets of the accounts, and trying to put together some set of root causes or common causes and problems that might help us try to get a handle on the problem. In each incident, you could see from -- from reports in the press, report -- you know, blog entries, discussion among the user community, that increasingly -- and I'll point to the very last bullet item -- there is a perception among the broader community that registrars are often the weakest link and an easy target for attackers who want to hijack high-profile Web sites. This is not necessarily, you know, targeting the registrar as being at fault, but simply pointing out that -- you know, that when you go against a really, really formidable target, you look for, you know, a weak link. And if you're going against an organization like Disney or a financial and you don't try to get into their intranet, you try to get into something else that may not necessarily be controlled as tightly as that organization. And so, you know, based on some of these reactions, based on the information that we found, we were able to kind of get a bigger picture of what was going on. Some of this is not all that surprising, because it's the kind of picture that you see in a lot of incidents where -- you know, where an attack results in an unauthorized entry. In the case of domain name -- or domain portfolio attacks, the attacker is basically getting control of an entire domain portfolio. All the domains that a registrant holds. Through compromising a single user account and password. How did they do it? The incidents that we looked at had a variety of attack vectors. They -- the attackers either guessed or phished or socially engineered some point of contact who had access to the account and disclosed the information. In other cases, the attacker actually looked for a Web application, you know, vulnerability, a SQL insertion or some other data insertion that resulted in gaining administrative privileges to a server. The important aspect of this is that once the attacker got the account, he was able to change both contact information and DNS information of all the accounts -- I'm sorry, all the domains in the compromised account. So in the case of Comcast, as an example, while the attacker only modified DNS configuration information for one or two domains, he had access to 200. If you went to a larger company, along the nature of a eBay, we're talking six or seven thousand domains. So the potential for very, very broad harm is very, very considerable. Another finding that we -- we were able to see that was very common in all the attacks is that the attackers were fairly knowledgeable of the behaviors of the registrars. They understood that e-mail may be the only method that registrars use to contact a registrant of some form of account activity. Those of you who own or hold domains and have a portfolio, you probably have received regular correspondence from a registrar or you receive a correspondence following a DNS change or a point of contact change. The attackers know this, and what they've done when they go and they -- they gain control of an attack, the first thing they do is they modify the DNS configuration, so the e-mail can't be delivered to any account, any e-mail address within any of the domains in that portfolio. So if you are, you know, Dave@example.net and your portfolio is packed, one of the first things that the attacker will do is modify the DNS configuration or the MX record to make certain that no mail is going to be delivered to Dave@example.net. Another aspect of the DNS configuration change, or that abuse, is that the nature of the DNS is distributed. Information is often cached. And it's cached on the basis of something called a "time to live." One of the things that attackers have done in many of these incidents is taken the TL value and made it very, very high, so that the persistence of information in caches throughout the world is the maximum amount of time allowed to persist. So while the registrar might immediately detect the problem, by the time the problem is detected, information may have been propagated out to the Internet that is incorrect DNS configuration information and it may last for days. I'm going to go somewhat quickly through some of these findings because there's a fair amount that we'd like to discuss, and we have a very short amount of time. We've already talked about the fact that attackers are exploiting a single factor or password-based authentication to gain access. We already talked about unconfirmed e- mail as what appears to be an unreliable method for delivering notifications to registrants. And sort of very important -- did we lose this again? Sorry. Sort of a very important point that we're trying to emphasize as we socialize this work with registrars is that it appears the customers don't quite -- customers don't quite understand or recognize that there are differences among the kinds of security measures that various registrars provide. And so some registrars do a very, very good job of detecting abuse, of preventing unauthorized access and others may not. That's not unusual in any business. You have 900-some-odd registrars, they are not all going to be the same. But what we also see is the community does perceive, and I think there really is a need, for domain name account access to be as secure as an e-banking and an e-merchant transaction. As I said before, the threats against registration services are not unique. You see exactly these same forms of attack against financial institutions, e-merchant accounts, and corporate intranets and extranets. So the same threat model or similar threat models exist for registrars as well as all these other high-profile targets. There are also some other similarities: Scale and diversity of customers. There is also one very important similarity is that the same benefits are derived by educating the customers and distinguishing the service of one bank or one organization service and security offerings from the competition. So there is a value-add here for registrars that SSAC is going to try to emphasize, that is if you are a good business and you take this very seriously, you really should take the opportunity to make people aware of the fact that you're doing a better job than your competitors. Another important finding is that we are very careful to look at some of the mechanisms that are appearing in the financial world, in the intranet world to make it more difficult to gain unauthorized entry to accounts. Multifactor authentication methods are becoming more and more prevalent, and verification on the part of a provider identifying either the P.C. or the user by some additional challenges that cannot be defeated by automation are other mechanisms. And granule access controls to customer data distinguishing the kinds of account activity that can be performed electronically versus performed using -- or in-person or making certain that there is some way to talk to a customer or contact a customer that is if the customer chooses or if it is a default, more than simply unconfirmed e-mail. So in some cases, if you're going to automate or make a change to your contact information at a financial institution, you're not allowed to enter that account again before you receive a phone call and there's a number you have to write down when you receive the phone call and you go to a Web site and enter that number. So you have an out-of-band confirmation that is very, very effective and very hard to defeat using automation. We believe that registrars can follow suit in a number of these cases. And one of the things that we've discussed is that there are actually two ways they can do this. They can either improve the overall security baseline for all registrants and just make the service uniformly better for anyone who goes and looks to registry domains or registrars can differentiate by offering some better than baseline security for customers who just simply want more. We do have differentiation in the market today. Further differentiation might actually benefit small and medium businesses. If you're a domain (inaudible) holder of hundreds of thousands of domains, you may be the size of corporation that can afford tens of thousands of dollars for protection of your online brand and identity. If you're a small and medium business and you have one but losing that one is going to essentially put you out of business, that customer may be willing to pay more than just the baseline registration fee and the baseline services. And so I think that there might be an opportunity there. So one of the messages of our forthcoming report on this is that we believe that it's possible and it's also time for registrars to use security to attract customers. And one of the ways that we've discussed providing some form of distinguishing what you do over your competition is registrars can voluntarily submit to some sort of security auditing by a trusted third-party and indicate that, We believe we are secure and we went out and we asked somebody to test us and it is a reputable party and here's the results. And other ways that we could go and look at the SSL world and we can think about the fact that there are trusted security marks that consumers value and pay attention to in the same way that people value the ICANN accreditation mark that registrars bear on their site. So there might be some possibility for ICANN or the registrar community to collaboratively choose a trusted third-party, collaboratively choose a set of baseline security tests and audits that would allow them to say we've met the criteria to be trusted as a secure registrar. So our recommendations at this point are that we think that it's time for registrars to offer more protection against exploitation and misuse of accounts. And I've mentioned the two forms that we can -- we would suggest registrars consider. We also believe that it's very important to improve education and awareness so that the registrars who do provide secure entry and secure measures to -- for their customers are distinguished from those who do not. And we think that it may be time to think about some sort of security audit that will allow registrars to demonstrate that they have complied with some security due diligence, whether self-imposed or as an industry. Our next steps, this week we're meeting with the registrar constituency and we distributed a prepublication copy of our reports, SAC040 to the registrars to discussion and in meetings I have already attended I know several of the registrars have looked at it and have commented on it. We'll publish that sometime in July and then we're also going to start a formal process within SSAC that is some form of public comment where we reach out to the community and see what they think of the recommendations that we're putting on the table. Thank you. >>STEVE CROCKER: Very good. Any comments? One of the points that I'm particularly interested in is the differentiation in the marketplace and as Dave said, there are two broad ways that there can be improvement in terms of the offering from the registrars. one is a general increase in the level of security offered to all of their customers, the registrants, or a separation of different classes of service for different customers because it may be advantage use for some customers to pay more to protect a domain even if that doesn't cost them very much to buy it. It may cost them enormously if the registration were disrupted or hijacked. So we'll see how this plays out over a period of time. Again, thank you very much. And moving on, we're going to move to Ram and we are going to have a slightly different version that's not showing up. Why is that? Well, that's no good. You get your choice. We can switch computers or I can use an older version. >>DAVE PISCITELLO: We have a network. >>STEVE CROCKER: What? What? What? A network? I checked into V Australia and complained that the Web site didn't offer an uneasy way to select a seat. What they said to do is call us up on the telephone, and I had no idea what she was trying to say. Okay. We'll try again here. Now we're good. >>RAM MOHAN: Okay, thank you. In the meanwhile, we apologize. We're told there was some audio streaming issues for folks listening in remotely, so our apologies for that. That's being fixed or has been fixed as we speak. This presentation is about a SSAC recommendation. Again, this is going into the board but we are presenting it to the community about redirection and synthesizing DNS responses. On the next slide, we talk about the issue. We are really speaking about the wildcarding of DNS records and what it does, as many of you know, is that it provides what looks like a valid address in routing even when a domain name does not exist. So it may be an unsubstantiated domain name but when someone types that into a browser or sends an e-mail or other things, it looks like it is actually going there when it doesn't exist. It has some significant consequences. It breaks core DNS systems and legacy applications. It erodes trust relationships and creates new opportunities for malicious attacks. And the pernicious thing about it is when the attack happens the affected party or parties have no ability to mitigate the problem when wildcarding is done at the TLD level. If you can go to the next slide. Just briefly, the kinds of things that break, most basic Internet tools and applications that users have come to depend upon, they don't work as expected. E-mails won't bounce anymore. Search engines won't be able to function the way they do right now. If you run something like a link checker, it won't find any more broken links because every link is suddenly live. Every link works. There is no such thing as a broken link anymore and there are many other software applications as well as equipment that have this core DNS functionality expectation. Those will break as well. Therefore -- the next slide -- that is the advice of the SSAC to the community. The synthesis and redirection of DNS pose as clear and significant danger to the security and stability of the DNS. Therefore, we are recommending to the board that ICANN needs to take all available steps with appropriate entities to prohibit such use and to prohibit the redirection and synthesis for all TLDs, gTLDs, ccTLDs, IDN TLDs, et cetera, and this might -- there are several bullets in there. The eventual result of it, you know, might be one or more of all of the consequences there. The new gTLD guidebook has to be modified, ccTLDs have to work with the GAC, have to work with the ccTLD community and potentially go through the GNSO and the ccNSO, the appropriate policy processes to ensure that existing TLDs and the agreements there as well end up having this prohibition in place. And that is about as clear a direction as we can provide. On the next slide, if you can -- if you go to the document that is listed up there - - sorry, it is a little bit -- it doesn't -- that document lists all of the references. SSAC has opined and provided reports about this several times going back many years ago when there was the site finder issue. But we've actually provided reports after that. The RSTEP in ICANN reviewed the same issue when a registry operator requested wildcarding. So all of those are contained and references are contained online. And with that, I will turn it back to you, Steve. >>STEVE CROCKER: Thank you very much. Part of this work was triggered by the prospect of many new TLDs coming online, gTLDs, IDN TLDs, both G and CC types. So we wanted to look forward at what the rules should be for them as well as some of the practices that still exist. Does anybody have any questions or comments? Yes? >> YUNGJIN SUH: Yungjin from KRNIC. Now we are using wildcard for IDN dot kr service for web navigation system. If you prohibit to use wildcard, I'm totally all right with your idea and we are now trying to change the BIND software, modifying BIND software to prohibit this thing but we need time. >>STEVE CROCKER: Thank you very much. That's actually very encouraging to hear. Let me repeat one of the common themes that I talk about. We're an advisory committee, and we don't have the power to make a rule. Certainly don't have the power to enforce a rule. So what you're hearing here is the advice that we are giving and we fully understand and expect and appreciate that the implementation has to take into account a lot of other factors, including what people are actually doing and what the impact is and so forth. So speaking just my personal opinion, if you are moving in that direction and we are giving the sort of advice, that's as good as it gets. That's fine. And I wouldn't think that there's a big problem. I would say that's a quite cooperative position to be in. Any other thoughts? >>BILL MANNING: Yes. Like many toxic substances, in general, they're bad for you. But there are also some possible good uses or potentially very interesting things you can do with these fundamental techniques which are part of the DNS protocol. General prohibition might be good for the community at-large but there can be circumstances where these types of techniques would be beneficial and it would be useful to actually have some sort of escape clause if someone can provide a valid reason to allow redirection and synthesis to occur because I can -- off the top of my head, I can think about three things that I would use synthesis for which would not be considered, I guess, hostile. >>STEVE CROCKER: In the original work we did in 2003-2004, we took up some of that. There were quite a few presentations, and one of the places where there was a line was whether these were essentially for internal use versus a kind of open, public arrangement. And in particular, redirection in a parent zone where the relationship with the children was at arm's length was qualitatively different from a situation where the children were all sort of part of the same family, if you will, as the parent. So, for example, inside of an enterprise where you would have some sense of who -- what applications might be looking up and making references and what the scope of all this might be a qualitatively different situation. I don't know if that's one of the kinds of differences that you had in mind. But I recall from back then that it was one of the distinctions. >>BILL MANNING: Yep, that's one of them. Particularly with the advent of potentially many more generic top-level domains who are subject matter-specific. You might be able to infer similar types of relationships as those things evolve. The point being, if you have some mechanism for allowing this, even in the face of a general prohibition, if a credible case is made, I would make a temporary. >>STEVE CROCKER: I wouldn't want to hold a lot of hope out but the mechanism is there. Again, we give advice and then it has to be folded into the broader context. But at least this puts the default in the right direction and then somebody would, I think, have to make the case. Let me move on -- other, sorry, ray? >>RAY PLZAK: Yeah, I would just like to reinforce that. This committee is an advisory committee, and it certainly isn't in a position of dictating anything. However, if there is a discussion in which a rule, if you will, is bound into something such as a contract or something like that, then that would be the time to actually begin to make a case about whether or not there should be exceptions. And I would also caution that these exceptions should be very clearly identified as to scope and nature and shouldn't become something that every time someone invents something new we have to revisit this thing over and over again. >>STEVE CROCKER: Thank you. Given time and the welcome ceremony is at 9:00, I think we'll try to be quite careful about staying within the bounds here. So I will jump to the last presentation in which I will talk the review process that's underway. As I think everybody is aware, the bylaws for ICANN call for a rolling review on a multi-year basis of every component of ICANN. SSAC is one of the advisory committees, all of the Supporting Organizations and advisory committees are being reviewed. We are someone in the middle of the pack or maybe later in the middle of the pack in the process, so there has been a review of ALAC, a review of GNSO, a review of the board. There is a parallel review of the root server system advisory committee and so forth. The external review has been completed. And we took it upon ourselves to do a somewhat formal internal review so that we could coalesce our own feelings and understandings about what we've done well and where things need to change. In general, we've taken the whole concept of a time to examine ourselves and to be examined quite seriously as a healthy part of the process. SSAC was created now more than seven years ago. Essentially in reaction to the events of 9/11, every organization around the world took a look and said, "what should we do about security"? And at that time, ICANN was a much younger organization. We're now three times as old -- ICANN is three times as old as it was then and quite a lot of evolution has taken place. So we've looked at ourselves, asked a set of questions and we provided this analysis and recommendations to the board working group that is overseeing the review of SSAC. In the next few months, I think, they will come forth. I'm not sure what their schedule is exactly with recommendations about where some changes can be made. At the same time, we're taking some of the results and instituting them ourselves within the capabilities that we have to adjust our own administrative procedures and the like. So here are some of the questions that we took up. And I want to give a lot of credit to John Schnizlein who is not here who has led work within the committee. Two existential questions, so called. One question is, do we really need to exist? As I said, we were created at a time when it seemed like the right thing to do. Other institutions and organizations have grown up within ICANN. There is the RSTEP process that was mentioned. There's internal security groups, Greg Rattray is leading an effort and number of other things which is entirely appropriate. Security and stability is acknowledged to be one of the primary concerns about -- for ICANN and it's quite appropriate that it should be marbled entirely through the organization rather than encapsulated in some specific department or organization. The answer -- and I did not consider this to be a foregone conclusion, but the answer is, yes, we have a continuing role and we live in an interesting middle ground of not being instantly reactive to incidents and not being able, on the other hand, to organize super big frameworks. But we can do and we have done analysis of repeated phenomena. We try to look at the way things interact with each other and kind of do systemic analysis and give advice that is a bit removed from the day-to-day crush. And then we also looked at a number of things about how we're organized and how we operate. We have had no formal terms of membership. The only rule that's built into the bylaws that the board appoints members doesn't say anything about them removing them. Doesn't say anything about terms and so forth. We now have more than seven years of experience and although it's worked pretty well, that we can also see where some of the weaknesses are. People get burnt out and there is no easy way to bring up the subject or to do things. So we've come around to believing terms have a useful basis, useful thing to contribute. Another aspect is whether or not we should have formal rules of operation, minutes and voting and so forth. And the answer is, in brief, no. A different question is who should initiate the work that we do? We certainly are responsive to requests from the board and from others? But the vast majority of what we have done over the past several years has been initiated by ourselves based upon what we've seen. And that's -- that's worked out reasonably well. I think that we will probably look for a bit more interaction and probably some formal tasking from time to time, and I don't know what the balance will be. But it may be helpful just in terms of raising awareness to socialize the work that we're doing beforehand rather than after the fact. Some other questions about clarifying roles of membership and maybe some substructure within the committee. One of the things -- one of the messages that has come through in a number of ways, both from our internal examination and external review was increasing the visibility of what we're doing in a number of different ways: Improvement on the Web site, improvement in the way the reports come out. We had already begun translating some of our reports, and we're going to increase that and try to increase the interaction that we have with the other components of ICANN and that's one that is dependent in part on their own evolution and many of the other components of ICANN have been evolving over the past several years and reaching a much more mature state of affairs. And we're moving toward trying to provide a little more support for ourselves in meetings. When we were created, ICANN was an extremely poor organization. As it's worked out, our committee has no natural time in which its members get together face-to-face. We have members on the committee who have never met each other. We're going to try to shift that a bit. And so here's a couple of things, an annual planning meeting, a bit of travel for ICANN members to come and engage more at ICANN meetings, mainly to meet other components of ICANN and bit more staffing so that we can -- we've reached the limits of what we can do, I think, with the staff that we have in terms of the reports we're writing and the interactions that we have. So that's the brief aspect. Some of these will require changes to the bylaws or actions from the board. Some of them are things we're instituting ourselves. Let me open the floor and ask if there are any questions or comments on this aspect. That's excellent or terrible that nobody cares or everybody is completely bowled over with how well-run we are. Oh, Barbara, thank you very much. >> BARBARA FRASER: Okay. You have to have a question. I was aware of the surveys that had been done. I guess I was interested in how the board responded. I was pleased to see your role is still going to maintain the original which was to report and support directly to the board. That's not going to change, correct? >>STEVE CROCKER: Well, so a couple of things in what you've said. The process that's underway is that the board in all of these reviews has a subcommittee of current and some prior board members who oversee the process and that group is still working on building recommendations and gathering inputs. And they have not brought that up to the full board. So the first part of your question, the board actually health paid attention in sort of an objective sense. The other -- you touched on a very interesting additional point. Yes, we're tasked as an advisory committee to the board. But we're also an advisory group for the community at-large really. When we do our work, when we take on problems, we actually think about both of these aspects of providing input into ICANN as an organization starting with the board but also working with the staff and the other components but also providing advice from a -- from the -- I was going to say a neutral objective but nothing is ever neutral or objective, but anyway about our perspective what's good for the Internet and the full range of users who may include ICANN but certain to include others as well. And the intent is really to continue in the same mode. So from a relative point of view, the answer is no change but I think it really is slightly broader than the way you phrased that. And I think that brings us to the end of our time and I'm pleased to see I'm not being overrun here with hostile questions for sure. Let me thank you, once again, for coming, and I keep wondering if it's an abuse to schedule it at this hour, but apparently it works out well. So I suspect this will become our slot. So I will see you all in Seoul.