Workshop: Protection of Registrants ICANN Meeting - Paris Monday, 23 June 2008 >>MIKE ZUPKE: Good morning, good morning. I think we are about ready to get started. Thank you for joining us. I am Mike Zupke, the registrar liaison manager on ICANN staff. And you are in the protection of registrants workshop that we are holding for you at this ICANN meeting in Paris. I want to give you just a quick look at the agenda. We have got some interesting things for you. We prepared a workshop in Delhi which was an interactive format and we look forward to doing something a little more the participatory this time as well. We would like to give you a rundown of things staff has been working on in the way of registrant protection, and then by way of an interactive part, we will have a registry failover exercise that Patrick Jones will be putting on. As I mention, we have had a workshop in Delhi, we have had workshops in the past. I think it's sort of a new thing that we are calling this protection of registrants, but actually as I thought about it, we have been doing these things for actually some years now, some of these programs have been in the development stage, and are now coming to fruition or that they are more in the public spotlight now. But there's actually quite a history of the work that we have been doing. There was a protection of registrants workshop that was put on in San Juan, there was another tutorial that ALAC and staff put on, and that was largely due to the work of the Danny Younger, and that involved the Registrar Accreditation Agreement amendments. And then our most recent workshop before this was in Delhi. So the four areas that we are going to talk about today, and we would like to share with you an update on, we have the registrar data escrow program, the terminated registrar transition procedure, which is currently posted for public comment on our Web site, the Registrar Accreditation Agreement amendments, which are also posted on our Web site right now for comment, and the registry failover plan. So without further ado, I am going to get into the registrar data escrow program. So this is something we have been talking about for a few ICANN meetings, and I see a lot of familiar faces but I see some new faces, too, so I will give you a little bit of background on the program. Essentially, the technical mechanics of it are that every registrar who registries gTLD names directly with a registry, that is they are not acting as a reseller but they are actually registering the names, is required to place their registration data into escrow with either the escrow agent designated by ICANN, which is Iron Mountain, or a third-party escrow agent they have chosen. Essentially, the data they are escrowing is a lot like WHOIS data but it also includes the billing contact information. The idea being that if this registrar's accreditation agreement gets terminated or expired without renewal, we have access, ICANN will have access to that data so it can be transitioned. Those names that were under that registrar's management can be transitioned to another registrar. This is a die component to planning for registrar failure, for registrar de-accreditation. In the past one of the challenges with de-accredited registrars has been that ICANN has not had access to this data. So through the Registrar data escrow program, we have got a much more meaningful protection in that there will be a fairly smooth transition from one registrar to another. As I mentioned, it only really comes into -- sorry. It becomes applicable upon a termination of a registrar's accreditation agreement, whether it expires and is not renewed or whether it's terminated voluntarily or whether it's terminated due to a breach of the Registrar Accreditation Agreement. We have all registrars are obligated or will soon be obligated to deposit their registration data once a week, and large registrars who have a high registration volume will be doing that once a day. Currently we have somewhere around 950 registrars who are accredited. There are 753 who have enrolled in the registrar data escrow program. 392 are currently depositing data on a regular basis. We have found so far there are 27 registrars who have no names and therefore have no obligation to escrow data. In sort of the global view, that's about 82% of all registrations are currently being subject to the escrow so that their registration data is protected in the event that registrar became de-accredited. Going forward, we plan continued compliance work in this by bringing all registrars by bringing them forward and escrowing their data. And we will have also a report coming fairly shortly where we will list the names of the registrars who are not complying. We think this will provide valuable information to registrants so they can make a decision about whether or not they wish to be with a registrar who is not complying with the data escrow program, and they can also potentially put additional pressure on their registrar to come into compliance sooner rather than later. I think that that's about the sort of nutshell summary of the data escrow program. I would be happy to answer any questions about the program, the status of implementation, sort of the specifics of the program at this time, if there are any. Do we have a microphone? >>TIM COLE: Are there any questions about the data escrow program? >>MIKE ZUPKE: So if you would, please, start with your name, and then your question, please. >> Thanks. My name is Rex M., I just wondered if, I thought it was a contractual requirement to do this. What will happen to the -- assuming you want everybody to comply, so what's the sort of longer term plan if you don't? >>MIKE ZUPKE: So there's a bit of an echo. Let me see if I understood your question. You are asking what is the compliance enforcement going to look like for registrars who are not complying; is that correct? Okay. Owe registrars who don't comply, you know, will be subject to compliance action. Initially that, will start off with, and we have already begun sending noncompliance notices to some registrars. The second step of that would be a breach notice and termination. We do have ways that we are able to effect the termination of accreditation outside the data escrow program. And, in fact, we have had two registrars that have been recently de-accredited who were not participating in the did the escrow program. One of them was obligated to and did not, and that was one of the bases for their de-accreditation. So ultimately, you know, we are serious about it, and that's the message. But in the short term, as we bring registrars on board the program, there's also this sort of public aspect that they will also face their customers, where they are customers will be informed that they either are or are not participating. Any other questions? >>TIM COLE: Anyone else? That's a good segue into the next topic, I think. >>MIKE ZUPKE: So as I mentioned, we have recently posted another document to our site called the terminated registrar transition procedure. And essentially, the issue that we were trying to solve here is how do you decide where the names of a terminated registrar go. It's in ICANN's bylaws and it's in our mission that we are to be fair and equitable in how we treat registrars, and in this regard. There could be a number of registrars who are interested in taking over a portfolio of names that a de-accredited registrar managed. So we developed this through consultation with the facility that is intended to help facilitate the transition of this more smoothly. In Delhi we had a workshop dedicated to this and we had substantial community input into the process and many of the things we received from the community have made their way into the paper. There's also a flowchart version, so if you don't care to do all that reading, it's a fairly simplified process. I would encourage you to take a look. It's posted until July 7th for public comment. And a few people have commented to me personally, but it works a lot better if you post it in the public comment forum. The goal being that we'll take those comments into consideration, make revisions as appropriate, and move it forward to the board for adoption as a permanent procedure that ICANN staff will use. In the interim, I mentioned we have two de-accredited registrars we are dealing with and we are using that procedure on an interim basis. So if there are any questions about that, I suspect there may not be, but you can take a look on our Web site and my e-mail address is also addressed to the public comment forum so I am happy to take questions that way as well. And I'm going to move to presentation by Tim Cole about the status of Registrar Accreditation Agreements amendments that are currently underway. >>TIM COLE: Thank you, Mike. Many of you in this room know that we have been talking about amending -- excuse me -- amending the contract that ICANN has with its registrars for some time now. And we have been working through a collaborative process with community input. We have had prior public comment periods. We have had workshops. We have met with various constituency groups. ICANN staff has also been in a dialogue with representatives of the registrar constituency. And as of just a couple days ago, we posted on the ICANN Web site a set of 15 draft proposed changes to the contract. I would like to clarify, these aren't ICANN's recommendations of changes for the contract. They are changes that have come out of a collaborative process and have been discussed in a variety of settings. And so they are basically a set of proposed amendments that define what has been discussed publicly with different people and with the registrar group, among others. And they are out there for people to look at and discuss and contribute their input. What I wanted to do was just go briefly through what the amendments touch on, just so that you have some idea, because the majority of them were triggered by the various discussions we have had about protecting registrants and protecting the integrity of the domain name marketplace, if you will, with regard to the registrar relationship and ICANN. We break them down into essentially four different categories. The first one is enforcement tools. Many of you may know that -- and as Mike touched on earlier, our relationship with registrars is contractual. It is not regulatory in the sense that ICANN doesn't promulgate rules, like a security and exchange commission or something or the FCC. We have a contract with the registrars, and basically right now, either a registrar is in compliance with their contract or they are not in compliance with their contract. And at least in theory, the only real resolution that we have, if they are not in compliance with their contract, is to terminate the contract. But as was pointed out in the previous presentation, that has a lot of connotations for the registrants, the people that are the customers of those registrars. So we don't approach terminating a registrar lightly, but we also felt that we needed better or more enforcement tools to make sure that short of terminating a contract, we could do a better job of making sure that what was in the contract was followed successfully. So among the enforcement tools that have been proposed for addition or for changes in the RAA is providing for a very specific terms for auditing a registrar. Probably the most visible and most talked about change is something that we talk about as far as graduated sanctions. So there are both potential financial penalties and suspension at the registry level. So in other words, if a registrar fails to comply with some provision, and after repeated notices and warnings and discussion they fail to come into compliance, we would, if this provision is adopted, we would have the ability to go to the registry and say, "Do not allow that registrar to add new registrations for a set period of time," as sort of a penalty for their noncompliance. We believe that that sort of penalty will go a lot further to getting people to follow the contract appropriately. There is a provision that looks at groups of registrars that have common controlling interest, and in some respects, if one of those registrars fails to comply and is terminated, another sister registrar or something starts to do the same behavior, they can be held accountable for the behavior of another company under the same common control. There's a provision that movies some of the fees that registrars pay, and adds a penalty for paying their fees late. This really isn't something -- again, this isn't something that ICANN is generating because we're really anxious to get their money quickly, but it's registrars who pay on time are not happy about registrars who don't, because they feel that that's an unfair playing field. So they have asked us to consider this late fee concept. There's another provision in there that is -- it's somewhat of a housekeeping thing in a sense, because some registrars will register the names under which they do business at their own registrar. And if they do that, there is a problem with them having a contract with themselves. So there is a provision being proposed that would sort of address that and provide for that -- a way to address that fairly and equitably. And finally, an enforcement tool is a change in the arbitration provision. Right now, the arbitration provision in the contract allows a registrar who is informed that they are going to be terminated to automatically have their -- the termination stayed for 30 days while they go and seek arbitration. That clause would be altered somewhat to provide for less of an automatic option for them to stop the termination. There would have to be more steps taken. The next broad category that we are looking at and that has been proposed is -- falls under what we call registrant protections. There's a provision that affects both registrars and resellers with regard to those entities that make available a privacy or proxy service at the time you register a domain name, and it's a strong encouragement that they put the underlying customer data into data escrow as well as the rest of their data escrow material. So that if something should happen to that registrar and the privacy service, that those underlying customers won't -- will still have some way of gaining control of their names, if that becomes necessary. We expect to develop, in consultation, if this next item is adopted, we would expect to develop in consultation with the community a registrants' rights and responsibilities document or FAQ or set of information that would be based on the ICANN Web site, and that all registrars would provide a link to that document on their Web site. So we have had a lot of interest expressed from the community that ICANN take a more leading role in providing educational information, information about how a customer's relationship with a registrar works and how the registrar's relationship with ICANN interacts or interrelates with their customers. And so this would be a way to provide some of that information and to make sure that all registrars provide a link to that information for their customers. We are -- For the first time, one of the amendments in this set of amendments addresses the relationship between registrars and resellers, and provides some requirements for -- in the relationship between the registrar and the resellers that would require the resellers to abide by ICANN policies and provide certain information to their customers and so forth. And so this would be the first time we would really be addressing, in the context of the content -- the contract, the relationship with resellers. The third category of amendments that are being considered is what we call promoting stable and competitive registrar marketplace. And this, I just want to kind of run through these last ones fairly quickly because they are not as closely related to the topic at hand, and I want to give Patrick plenty of time to do his piece. But the first one is that we are considering and talking about some changes that would make the change in ownership, change in the management or responsibility for a registrar more transparent. That there would be greater reporting responsibilities so that ICANN would know sooner if someone acquired a registrar, and that they would have to certify their willingness and ability to comply with the contract and so forth. There's a new testing and training requirement that, if adopted, each registrar would have to have someone -- at least one person on their staff go through a training program that would be conducted online through ICANN. And then ICANN also, in this contract, reaffirms its commitment to require, for the most part, registries to use ICANN accredited registrars. There are a couple noted exceptions that have existed in some contracts, but for the most part, it's an ongoing commitment that we believe that because registrars are held to a high standard under this contract that the registries should also be working through those registrars. And lastly, there are just a few items that are sort of bringing the contract up to contemporary -- some of the contemporary ways we are doing business. It allows for electronic notices as well as for mail. There are references in the old contract, the Department of Commerce that under our newest contracts no longer exist, so some of those are being -- it's being proposed that they be removed or replaced. And we also made some clarification on when registrars and how long they have to retain data. As I mentioned before, the agreements, these proposed amendments that are a result of community consultation are on the ICANN Web site in greater detail. You can see the actual contract language, if you like. See how these things would be incorporated into the contract, if you are so inclined. But there's also a public forum. It's open till sometime in August, I believe. I'm not sure the exact date. So we strongly encourage you to review this if this is of interest to you, submit your public comments. We also hope to have different public opportunities for people to comment as well. But I would certainly encourage you to go online and look it over and submit your comments. And with that, I'm going to turn it over to my colleague Patrick Jones from the registry department. He is going to talk a little bit about registry failure and what kind of work has been done in that area. And then we are going to get into some small groups and do an exercise on this. And then possibly also discuss some other areas that you might have interest in. >>PATRICK JONES: So for the past two years, ICANN staff has been working in conjunction with experienced ccTLD and gTLD registry operators to come up with a comprehensive plan to deal with any potential issues with technical business or financial failure of a registry operator. The overall goals of the plan are the protection of registrants and to ensure confidence in the DNS. And what that means is that the plan, which is ICANN's plan for how it would respond to a registry failure event, is to ensure that there are measures in place to protect the domain names and registration data of registrants and to ensure that gTLD registries have measures in place to ensure the continuity of the registry and that those measures help inform the community that there is a process in place for ensuring that registries are -- they have contingency measures and their planning in place. As I mentioned, a lot of work has gone into the development of this plan. There was a draft posted in October of 2007. We took public comment on the draft and then revised that draft leading into the ICANN meeting in Los Angeles. From the revised plan, ICANN conducted an internal exercise based on commonly used cyber exercise practices. And that exercise was conducted January 24th and 25th. After the exercise was conducted, we updated the plan and circulated a revised copy to a small group of ccTLD operators and gTLD registries and then conducted a consultation in the New Delhi meeting, followed by, you know, continued refinement of the plan and the language throughout the months of March, April, and May. And where we are now is that we've had a number of revisions, in fact, there's another revised draft that we will be presenting tomorrow to the registries constituency. And then, hopefully, by the end of the week, we'll have come to some agreement on the current language so that the latest version of the plan can be posted for community consultation. So what I want to do now is, I want to walk through, briefly, the failover exercise that ICANN conducted in January. Staff were located in eight locations worldwide, looked at five basic scenarios that covered the following categories. Looked at the escalation of temporary failures. So what happens when something small turns out to be a larger issue that results in a business failure of a registry. Then we looked at what might happen if DNSsec keys were compromised in a registry that was founded on being the most secure TLD on the Internet. The third scenario involved an IDN TLD that was located in a new part of the world, separate from where, you know, most current gTLD registries are located, in North America and western Europe right now, although dot Asia is the first gTLD registry located in Hong Kong, we're expecting with the introduction of new top-level domains, that they could be located in all of the ICANN regions that are not currently served by a gTLD registry headquarters. And with that, ICANN wanted to use this exercise as a chance to review internal practices and sort of crisis management training of what might happen if there was a natural disaster that then developed into the government not being able to maintain its infrastructure and doing a nationalization and government takeover of the gTLD registry. That, of course, has not happened to date. But it's something that we wanted to test as a scenario in the exercise. The fourth scenario was, you know, how staff would respond to a complex attack on a backend operator of a gTLD registry. This scenario looked at a backend provider that was providing service for a number of country codes, as well as gTLD registries. And the backend operator in this scenario was not under contract with ICANN. So that raised a number of issues as to how ICANN would communicate with the backend provider, and, you know, ensure the protection of those domain names and that the registrants in those domain names had sufficient information. And then, finally, the fifth scenario looked at, again, an escalation of events involving the bad acts of a registry operator. You know, ICANN is very comfortable with -- not saying that there are bad acts underway by any present gTLD registry operators. But this is something that we wanted to test in a scenario environment. And that's what this exercise was for. So we learned a lot from the exercise. It was very good training. And, you know, from the exercise, really, we were able to improve the plan and get it to the stage where it is now. What I want to do with this group is now turn it over to the interactive element of this session and divide up, using the model that -- from Mike and Tim's exercise in New Delhi, divide up the group into sort of small groups, and we're going to walk through a shortened version of a scenario that we covered in the January exercise. So what I'm going to do is, I'm going to present some facts. These are facts for the purposes of this exercise. And it's something that's, you know, supposed to give you an idea of, you know, what ICANN staff reviewed in the exercise, and then also get you thinking about, as we get ready to introduce new TLDs, what types of information would be good to help us improve the plan, the registry failover plan, and also, thinking about sort of what other tools might we start to think about, you know, needs to help improve the protection of registrants, not just in the areas or categories that we discussed today, but if there's anything else that we haven't mentioned, feel free to raise it after this exercise is done. So in this first scenario, there's an Urdu language, IDN.IDN gTLD. It's located in a fictional country for the purposes of this example exercise, and the TLD is owned by a commercial entity. The country where the registry is located has a large-scale earthquake, category 8.0 on the Richter scale. And, you know, this occurred not too long ago, I think it was about a month ago, in China, or maybe a little bit longer than that. So just for this example, the registry's primary data center and its headquarters is damaged by the earthquake. In this area, the infrastructure can't keep up, and the gTLD registry is knocked offline. So registrants begin to contact the registrars, trying to find out what's happened. And some registrars are having difficulty communicating with the registrants, maybe because the registrars offer the TLD but don't offer communication or they don't have the ability to communicate effectively in Urdu. So in the next set of facts, the registry is able eventually to enable a backup location and name service is restored. This outage affects the -- So those are the main facts. And something else to consider with this exercise is that the outage might also affect the registry's primary registrar, so the largest registrar for this TLD is also knocked offline. And the registrar for the TLD has not yet escrowed its data. So these are some of the questions to think about. How can the affected registrants be best assisted? When should communications to registrants begin? What if the registry cannot recover? And what can be done by ICANN to assist the registry? The registrar? The registrants? >>MIKE ZUPKE: Okay. So if we could, please, I'd like to ask you to move forward. We're going to bring you into groups. I know -- there's a bit of inertia here that we're up against. But if you wouldn't mind, please, I promise it will be worth your while. Just move forward. It's okay. If you don't yet know the people sitting around you, you will. So I think we'll assume that if you've moved forward, you're interested in participating in the exercise. And if you're not, okay, we understand. Those who are in the front will be grouped with their neighbors in order to work as a team to come up with some answers and questions, I think, at the same time. So as we do this, if we could have this group sort of circle your chairs a bit. And the same over here, if you wouldn't mind, please, just circling your chairs. >> (inaudible). >>MIKE ZUPKE: They don't move? Okay. You have to lift them. All right. Let's -- never -- never mind. Okay. In that case, well, just get cozy. Okay. If we can have you to the same over here. Got kind of a smaller group. >> How long is the exercise? >>MIKE ZUPKE: (inaudible) for those who don't mind, you can stand up, since it's probably easier than trying to break the chairs apart. Why don't we bring you guys over here, so you're in this group. And as you form your groups, you need to elect somebody to be your group spokesperson. If nobody's willing, just draft your nearest ICANN staff person. They're obligated. It's in the contract. I'm seeing two groups here. Is there more -- Is this a group? Okay. Would you like to join them? Okay. This half of the room, any interest? Okay. This is the Wi-Fi area. Most importantly, if you're interested in participating, I hope that you're in a group. If not, come this way. If you're in a group, elect a -- please designate a spokesperson. >>PATRICK JONES: As a reminder, I'm going to run back through the facts real quick that you guys are considering in this example exercise. You have an IDN.IDN gTLD. That's based in the Urdu script and language. Arabic script, Urdu language. The country where the gTLD is located has been hit by a large-scale earthquake. And the registry's primary data center and its headquarters have been damaged. So the registry's been knocked offline. Registrants are starting to wonder what's happened. They're starting to contact the registrars. And not all the registrars that service the gTLD have the ability to communicate with the registrants in Urdu. Eventually, after some period of time, the registry is able to switch to a backup location. But in addition to the outage with the gTLD registry, it's also affected the largest registrar for the registry. And this registrar has not yet escrowed its data. So it's really two issues in one scenario. So from this scenario, how can the affected registrants be best assisted? When should communications to registrants begin? What if the registry cannot recover? And what can be done by ICANN in this situation to assist the registry? The registrar? And registrants? >>TIM COLE: The small groups can choose to answer all the questions, discuss them, maybe you want to just focus on one of the questions. But we would like each group to report back some of the thoughts that you have about how -- what's ICANN's role and what do we need to be anticipating in such a scenario. >>TIM COLE: Take about five more minutes and report back as to what you have decided we should do about this. >>TIM COLE: So is each group about ready to give us a little report about what you covered in the time we had here? We would like to capture just some of the thoughts, because you probably had -- I have heard some good discussions going on. But has this group designated someone to be their spokesperson? Yes. You can report back on what you discussed. >>EBERHARD BLOCHER: Can't somebody else start? [ Laughter ] >>EBERHARD BLOCHER: My name is Eberhard Blocher, from Germany. We have been discussing a few of these questions, but basically we have had a very lively discussion going around these topics. Well, I mean, we think it's -- I think perhaps, to sum it up, we do think data escrow is a good idea to have, and, in fact, myself, I have learned that this has not been -- this has already been introduced, so that came as news to me, which is a good thing. And personally, I also feel that this is looking forward to having new gTLDs introduced, perhaps lots of them, next year. So I think this is a very -- not so much a backward-looking exercise, like securing what we have, but rather forward-looking to what might be the problems in the next year or in the coming years. >>TIM COLE: Thank you. Paul, do you want to speak for your group? Did you guys choose someone to speak? Kurt, can you -- Rob? All right. Okay. He says he does Urdu so he is not going to do the reporting here. Well, maybe I will ask Craig, then, to talk a little bit about what your group spoke about. Craig Schwartz. >>CRAIG SCHWARTZ: So we didn't get to answering the specific questions but raised a bunch of other questions. Thanks, John. We were talking about whose responsibility it is to escrow data and how does ICANN get access to the escrowed data. So we were talking about the relationship that exists now with the data escrow agreements and how that data is released. There are other questions -- Paul, what were some of your -- Was it a thin versus a thick registry? Which of course tells you what access -- how much information you have access to via directly the registry or having to go to the registrars. What else? We talked about the geographic dispersion of name servers and DNS servers, and it wasn't clear, necessarily, whether we were talking about name servers or DNS. And I think there was the comment that if the name servers went down for even a day, that it probably wasn't a significant issue. I'm sorry. If the SRS went down for a day, that it wasn't a significant issue, but if the DNS was down, that it was a much more serious problem. And we also talked about WHOIS and that also if it was down for a day or two, it was not critical, but if it was down for an extended period of time, that that was also an issue. So we mostly talked about access to service and timing. And we didn't quite get to when does ICANN step in. But we had just lots of questions amongst the group. >>TIM COLE: Thank you. We're going to do one more of these exercises, but it's not going to be up there on the board, but before we do, Patrick just wanted to just close the loop here and give you a little more information about what has been done with the kinds of information we have gathered from these exercises with regard to registry failure. So.... >>PATRICK JONES: So the next -- the next steps for this are in the following week, and at some point after that to post for community review the latest version of the gTLD registry failover plan, and then following community review and consideration, to do a real structured test with a number of gTLD registries and perhaps registrars and other participants, sometime in early 2009 as sort of a follow-up exercise to the internal ICANN staff exercise that we did in January of this year. So we'll be able to report back to the community probably not in the March 2009 meeting, but definitely by the -- sort of this time next year, report back the results of the plan and an update, if there's one that's needed. >>TIM COLE: Okay. Thank you. Now we'd like to go to a little more free-form question, but it's sort of the foundational question of this workshop, which is with the advent and the prospect of dozens, hundreds, of new TLDs coming on board in the hopefully not-too-distant future, what kinds of issues does ICANN need to be thinking about? We gave you some background on some of the data escrow efforts that have undertaken, the terminated registrar efforts, some of the new compliance and contractual provisions that are being talked about. Then we talked a little bit about registry failure, so now with some of that background, what would you, in your small groups, just talk about what kinds of things do you think ICANN needs to be taking into account or thinking about or anticipating with the advent of a large number of new TLDs? So that's going to be our last topic, and then we will come back, report one more time, and then we will wrap it up. All right? And if anyone else out here wants to participate, please feel free to come forward and join one of these small groups. (group discussions) >>TIM COLE: Just five minutes and then we will wrap it up. Five minutes and we will wrap it up. Thank you. >>TIM COLE: Okay. Let's see what kinds of ideas people have come up with. You folks didn't get to report before. Did you want to report on it? Let me get your name. It's Alan Barnett. >>ALAN BARNETT: Alan Barnett, yes. One of the issues, I think, that we have been discussing is that in times of crisis, the registrants are going to be approaching ICANN. And the thing that we have been discussing is how ICANN deals with registrants and other Internet users who are concerned about their domain name and their Internet use in times of crisis. And how ICANN reacts to those situations, whether it's an information giver or it's more of an assistant in terms of putting back the pieces in terms of crisis. One of the things we have been talking about is what role ICANN would have in putting back the WHOIS data of a failed registrar or a data failed registry. I know the group here discussed at what point ICANN would have access to the WHOIS data. The question then is what does ICANN do with it? Does it pass to another registrar? Does it pass to another registry? And you have got a lot of legal, contractual issues and so on. But I think for us, what is key is, as things go forward, is we get new gTLDs, we see more and more registrants approaching ICANN for information. And for us, we will be watching with great interest to see how ICANN presents itself to these -- the wider Internet public, and particular the registrants. >>TIM COLE: So let me use the prerogative of, so was your -- was your group interested in seeing ICANN expand its ability to deal with that? Or were you thinking that it shouldn't be ICANN's role? I didn't quite understand which position or where you were coming from. >>ALAN BARNETT: I don't think it's fair to say we have come to a consensus on that. My personal preference would be to see ICANN as -- (inaudible) a minimalist organization but an organization that was to give out information. So in this case of an earthquake, it's very much ICANN's role to give out, in the local language, information that there has been an earthquake and that there is a failure of the registry and maybe the registrars. But I wouldn't say it -- it would be necessarily ICANN's first policy to get involved at day one and start assisting the failed organization, to put Humpty Dumpty back together again. >>TIM COLE: So you don't see us establishing a call center with 2,000 employees to handle the -- all right. Thank you. So I think I will jump back to this group now. And who is going to speak for you? Karen was taking notes, wasn't she? Okay. Karen Lentz. >>KAREN LENTZ: Okay, I am Karen Lentz from the ICANN staff. I have been taking notes from the session. So a couple of things we talked about in this group are the frequency of escrow, maybe if there are more TLDs there needs to be a greater frequency of deposits. There was sort of a question about when there are -- or discussion about when there are many more TLDs, are those -- is each one operated by a unique entity? Or are there, say, 50 new TLDs but they are all basically being operated by one company out of the same place? So that has an impact on, you know, a failure situation. There's either more complexity in terms of the groups involved or there is more concentrated potential for a single point of failure. We also talked about, similar to what I think Alan said over here, that there is increased potential for people to be contacting ICANN and to be expecting ICANN to serve as a sort of coordinated center for information about what's going on in a failure situation or even if there's not a failure situation, what -- you know, the types of questions that are coming in and understanding -- doing some education up front to the registrant community about what ICANN's role is and where to go for the particular types of issues that come up. >>TIM COLE: Great. And last but not least, Eberhard, are you going to speak again for your group? Okay. Now I am going to have to get Casper's card because I will need to give it to the scribe for a second. >>CASPER THOMSEN: Thanks. This group, we talked about, a very broad perspective, like why are we doing all of this, why are we introducing all these new TLDs, whether they are generic or not. Right now there's a lot of stuff going on about location-based services on the Internet, on cell phones and so on. So we discussed what's the purpose of having these TLDs. If Google or myself knows where I am, why should I type in dot DE or dot cat or dot Berlin or whatever. So that was one of the topics. What else? >> Language. >>CASPER THOMSEN: Language, of course. We talked a bit about languages. Do we have a problem in just having English-speaking organization? And then we talked a little bit about our public view on ICANN. Will it be seen as a monopoly or is the Internet the opposite? Like is the Internet anarchy? And is ICANN a monopoly? Or will the registrants look at ICANN as a monopoly? That was it. >>TIM COLE: Okay. Thank you very much. Thank you for all of you for participating and discussing and sharing your ideas. It's great for us to get this kind of feedback, great for us to hear some of the new ideas or different ideas about what role ICANN should play. And we would encourage you to continue thinking about these issues and giving us input. And with that, I think we'll -- I'm going to give the mic back to Mike to let him -- You have nothing to say? All right. Then we're going to close this session, and let you all get off to lunch. Thank you. [ Applause ]