ICANN Meeting Workshop: Protection of Registrants San Juan, Puerto Rico Monday 25 June 2007 >>PAUL TWOMEY: So this is -- as we are bringing people up onto the panel, -- and I'll do my imitation of a rock star, and I will eat the microphone -- can I -- that's about as far as I go in imitation of a rock star, by the way -- I wanted to welcome people to this session, which is incredibly important. And perhaps just make a few opening remarks before we move on to the heavy work of the panel. As I said just half an hour ago, I'm very pleased by the initiative taken by the registrars and others to really look at the set of questions that have been posed and to see a way of, you know, how do we move forward. And I am a very firm believer that looking an consumers and offering good service to customers are not diametrically opposed principles there. Actually, there's a reflection of good business. So I think there is an alignment of interests here, which is important. Perhaps I could make some observations. What we have up on the screen now is a statement that I issued on the 21st of March 2007, drawing from our sort of common experience of the RegisterFly situation, but more than that, also drawing on other discussions that have been in place for some time and reviews of the RAA being -- coming up for their time anyway. And I just want to remind us that there are a range of issues here that I think the board and certainly I am very concerned about. And I -- this document on the 21st of March is a challenge to the community. It's a challenge to all of us. It doesn't necessarily have answers in it. So I don't want to give the impression that this is sort of a prescriptive document in terms of what the answers should be. But nevertheless there are challenges here, and perhaps I'd remind all the members of community that this is still a set of questions that we need to consider when it comes to the protection of registrants. Perhaps I'll ask Tim to scroll down a bit -- bit too far, Tim -- scroll down to the very end. That would be good. I'm not going to go through all the questions in detail. But I just want to point out the headings, really. So some of the, you know -- we've got some key questions and issues that we need to work through. What is, actually, the purpose of the registrar accreditation policy in the agreement? I'm actually now having trouble reading my -- the document. Thanks very much, Susan. You know, either issues about how to -- are there ways in which consumers can understand easily -- we talk about transparency and accountability in the ICANN context. But is there transparency for consumers of their understanding of the value offered by different players in a competitive registrar marketplace. And so that's sort of the heading called rating of registrars is supposed to cover that real issue of the transparency. Is there transparency and ease by which registrants can actually choose combinations of value and benefit and cost in their decision-making. There's clearly a big issue about affiliation and group. And related to that, it's a question that Elliot Noss has made several times, and it's a very key one, also the question of distribution channel and accountability across those issues. So, you know, what is the accountability to the delivery of service, which is about just a single legal entity called a registrar which has an accreditation, versus, actually, a much more economically realistic concept of what's the accountability for, you know, groups and related parties in delivering service. So I think that's a very important issue. This issue about additional compliance and enforcement tools and the necessity about that, the discussion, I don't know whether that's true or not. Very importantly, the transfer policy, not just what it should be, but how is it being interpreted now and what is the application of the transfer policy, particularly in the periods of towards the end of a registration and the -- at the very end of the cycle of a registration, how is that operating. Registrar skill testing. Should we have some process around skills accreditation? The point being made to me by many people is that Microsoft won't let you sell a product unless you're accredited to be able to use their product. Is there an issue about accreditation or should there be any skill requirement about the policy requirements, about the things that are involved. I know from some of Stacy's work that it's interesting when you talk to some registrars how little they actually do know what their obligations are, understanding the obligations that they have. That's a very small minority. I want to make that very clear. But, nevertheless, it does appear in the compliance work. Accreditation by purchase. I think this is a related -- by purchase -- I get an accreditation -- That was what we saw in RegisterFly, of an entity that failed to get accreditation when it applied for it but managed to get accreditation by buying an existing accreditation and should that be a valid process or not. There's an issue which moved around proxy registrations and ease of knowing about that. I know that's a topic that will be discussed. Resale liability. This is the issue, I think, Elliot talks about in terms of the channel, how does the channel operate. The master-servant relationships that might exist between registrars and resellers. I think that's something, certainly, that at ICANN staff level in compliance I think we see quite a big level. So that's an issue I think we need to keep talking about. Data escrow is obviously a topic that will be discussed today. And also clarification of what ICANN's responsibilities and options available to registrants are. I think we should not -- there's many things we can discuss here in terms of compliance. We can discuss here in terms of provisions, we can discuss here in terms of interpretations of transfer policies, that sort of stuff. But I think one of the things we should also be talking about as a community is just how do we communicate, how do we communicate our common understanding to the registrant. You know, where in marketplaces will people make decisions about the purchase of a domain name which is something that they do -- there are sophisticated purchasers, but there are many who are not and they may only purchase once every two years or they purchase once and their registrar reaccredits them. So I think there are important issues about communications and what do we communicate, I see that with ICANN about clearly communicating our role. There are also options available to! the registrant. I think that's an issue we should think about that and how that can be done potentially in a way that reinforces the relationship between the registrar and the customer. You know, there might be ways of how that gets incorporated. I'm just reminding people of these sets of questions that we set on March 21. I don't think there's an expectation that they're all going to be answered at this workshop. And there's been some prioritization. But I just want to reconfirm that I think we have an opportunity in front of us to really look at a range of issues and look at the responses by ICANN and by other players to try to address this. So thanks very much. >>KURT PRITZ: Thank you, Paul. This workshop is born out of a desire of many people on the dais here and others in the community to improve the environment for registrants. And it's also born out of a board resolution that was passed in the Lisbon meeting that asked ICANN to provide a report on the status of data escrow compliance to ICANN's current agreements and also propose a process for public discussion on the creation of a policy for appropriate protections in the gTLD space. So this is in partial compliance with that provision. So everyone on the panel here -- and, Tim, if you can go to the slide. Thanks. Everyone on the panel here I think is passionate about creating an environment that's beneficial to registrants. As Paul pointed out earlier in his president's talk, that business interests and registrant interests often align. And, actually, that's where the most benefit is to be found. So I think our discussion here is about how to get these things done and how to get the improvements done, not whether. I think we're all in agreement on a lot of the whether. So very briefly, our topics of discussion today are the registrar data escrow program. Since the meeting in Lisbon, a lot of progress has been made in reaching a process, procedure, and then ultimate compliance of this provision in the registrar accreditation agreement. And we want to report on that, and then there's key issues surrounding that. Then we also want to discuss the potential RAA amendments that Paul just described. We want to discuss a process for reaching agreement on amendments and making them effective in a timely manner. And then also I'll briefly describe, again, some of those amendments. After that, Patrick Jones and Chuck Gomes will discuss the registry failover program that ICANN is undertaking with the understanding that there will be new gTLDs shortly. We wish to certainly put into place a program that understand that registries may also fail and how can ICANN and the ICANN community form rules and procedures in way that best protects registrants but also fosters innovation. And then finally, Stacy Burnette will provide an update as to the status of the contractual compliance program. We've conducted several audits over the past several weeks between the Lisbon meeting and this time. And also she'll discuss plans for future audits and the actions of that committee. So let me introduce the panel members. With the exception of me, I'm pretty impressed. Susan Crawford is our moderator. She is a member of our board. Vittorio Bertola is the ALAC liaison to the board. Beau Brendler to my right is a let me of ALAC. Chuck Gomes is a member of the registrar constituency. Rob Hall to my immediate -- >>CHUCK GOMES: Registry. >>SUSAN CRAWFORD: Raise your hands. >>KURT PRITZ: I'm sorry -- a member of the registry constituency. Rob is a member of the registrar constituency. Jon Nevett is the chair of the registrar constituency. Rob, you are an officer now, too. >>ROB HALL: Vice chair. >>KURT PRITZ: Stacy is a member of the ICANN staff, the director of contractual compliance. Patrick Jones, a member of the registry liaison staff. There you go. Okay. Thanks. And then finally, Mike Zupke is a member of the registrar liaison staff. So I think we have managed to line up purchase in the order of battle. And our purpose here is to discuss each one of these topics and then indicate a key issue for discussion after that. And Susan will solicit community participation in that. So Susan, if you would start. >>SUSAN CRAWFORD: Thank you all very much. My name is Susan Crawford. I am a member of the ICANN board. The purpose of this workshop is to provide information about the state of play. Following the failure of RegisterFly when tens of thousands of registrants lost control of their names, there was an uproar. We need to deal with registrar accreditation and the procedures by which we accommodate registrants. So this workshop is an attempt to update you about what we're trying to do and get feedback from you about further progress. There has certainly been a lot of online energy and comments on the blogs about these topics. And I hope that in the room, we can have a good dialogue here as well. I was a little saddened to see only one comment at the public forum. So I know there are people who care about these issues. I hope we can get more interaction here. Kieren McCarthy, our manager of public participation, is looking for online comments. So he will solicit those, too. So we have four subjects. And the first one is data escrow. What's escrow? The idea is when two contracts -- two contracting parties make an agreement about data or source code, they will often invoke a third party and say that we'll deposit that data with a third party. And upon certain triggering events, the data will be released. Now, this is important to registrants. We want to be able to reconstitute a registrar if it fails so that registrants can continue to have access to their domains and be able to work with them. So here we're dealing with the possibly of the failure or something close to failure of a registrar. And the current agreement, the Registrar Accreditation Agreement, we're going to call that the RAA, but we mean the Registrar Accreditation Agreement, does contain a data escrow provision that requires registrars to escrow gTLD registration data by depositing it with ICANN or an approved third-party escrow agent. Now, for a variety of reasons, this escrow term hasn't been implemented, even though it's been in the agreements for several years. It put a burden on ICANN to receive data, so the cost was all on ICANN. And until recently, there wasn't a budget item for the registered data escrow program. As Doug Brent made clear in his presentation a few minutes ago, there now is money in the budget for this. And apparently we haven't asked registrars to bear the cost. There are three questions. How is data escrow being implemented? The second one which we won't deal right now, but we will later in this workshop, what should the event be that triggers the release of this registrant data? What's the moment that registrant data should be released? And the third one is what data should be deposited into escrow? And we're going to get to that third question in detail in this segment on data escrow. But first, I've asked Jon Nevett of the registrar constituency and Mike Zupke of the ICANN staff to describe the current state of play when it comes to registrar escrow. So Jon. >>JON NEVETT: Thanks, Susan. I will speak real briefly and turn it over to Mike who has some slides describing the escrow program. As Susan mentioned, an escrow program is a tripartite relationship essentially in this case between ICANN registrars and then a third-party escrow agent, where we as registrars would deposit our data with a third party and then upon certain triggering events, the escrow agent could provide that data to ICANN. And that would be in a recovery mode. People mentioned RegisterFly. That's the kind of situation that would -- that could occur. While Susan mentioned that we haven't been asked to bear the cost of this program historically, most -- or many, I should say, registrars have taken that burden on regardless. It sounds like RegisterFly did not, but certainly I represent Network Solutions here, we have a program that's similar to this where we have a third party holding our data in case of a disaster or anything like that. That data could be recovered. One issue that we're still dealing with is when ICANN receives the data, either through verification or upon some kind of a triggering event, we want to make sure that data is protected and that ICANN takes the appropriate measures to ensure this customer data, because there is a lot of privacy information in this data. We want to make sure that ICANN takes that seriously as it has indicated it would. And add some kind of representation that it would protect the data, because that's obviously an important thing for registrants. So we as the constituency pulled together a group of folks to work with ICANN on finalized this data escrow program. We had seven registrars involved. We met since Lisbon somewhere in the six to ten times, somewhere in that range. And you may have seen the public announcement -- what was it? About 30 days ago? Where there was a call for approved data escrow agents and an RFP for that process. I believe a number of companies have applied, and ICANN is going through that process now, reviewing those applications. But the registrars think that this is very important, as a constituency. It's an important issue. As an individual member, it's obviously -- protecting the registrant and the data and the information is of vital importance to all of our businesses, and we're very appreciative of ICANN for pursuing this and working with you on that. >>SUSAN CRAWFORD: Great. All right, Mike, can you tell us how the project plan is going? >>MIKE ZUPKE: Certainly? >>SUSAN CRAWFORD: Speak right into that mike. >>MIKE ZUPKE: So the project, the implementation project for the data escrow program involves primarily three phases, I guess you could say. The first phase is development of the technical specifications for the project or for the program, and that would involve specifically in what format the registrars will be submitting data, the method that they will be doing that. The second phase would be ICANN retaining an agent to actually receive deposits on its own behalf. This is what the RFP was for. We began that on May 21st. The RFP closed on June 8th. And then the third phase, at least in sort of broad strokes, is the third-party provider approval process. Under the data escrow provision that's currently in the Registrar Accreditation Agreement, registrars have the option to either deposit their data with ICANN or with an approved third party. So this third-party provider application process is what this is about. It's about giving registrars the option who feel that they don't wish to use the ICANN service, to use one of their own election at their own expense. Under the current data escrow provision on the RAA, there are several fields that are required for registrars to deposit. Among those are essentially basic WHOIS fields. You've got registrant, admin contact, technical contact, billing contact, name servers, expiration dates. So it's -- I think when the provision was drafted, these were the elements that were believed to be critically necessary to restore the functionality of a registrar. So I'd like to talk about, then, a little bit about that process of drafting the current specifications, then, I guess. The fields that are required to be deposited have been set out by the accreditation agreement, and this is something that because ICANN is constrained by contractual abilities, we cannot necessarily broaden what fields are required, but this would be an issue for further discussion as we talk about amendments to the RAA as we go forward. As I said, the second phase of this project involves retention of ICANN's data escrow agent. And in true terms, it's not actually an escrow agent, but it's an agent of ICANN who is going to receive deposits on our behalf. Because escrow, by its nature, involves a third party and an agent acting on our behalf is not actually a third party. So we put out a request for proposals on May 17th. We received seven from a pretty good variety of applicants. There were escrow companies who are already in the electronic escrow business. There were three registrars or companies that were affiliated with registrars who indicated an interest, in addition a registry also put in an application to become ICANN's data escrow provider. We received applications from five different countries, so there was a pretty good diversity among the applications that we received. We're currently in the process of meeting with those applicants who have requested meetings and will schedule meetings with any additional applicants who have not who we feel need for additional clarification for their proposals. We hope to have an agent selected by early next month. And as we said, we will be open for business by the end of July. That doesn't necessarily mean that deposits will begin, but we will be able to begin invoking the provision in the RAA that requires registrars to deposit their data. >>SUSAN CRAWFORD: Thank you very much, Mike. We have a specific issue to focus on with respect to escrow that I want to direct our attention to. This workshop is only -- it's not even two hours long, so we have to sort of focus our discussion. This one is the issue of proxy data. Many registrars use -- or let's put it this way. Many registrars and unofficial resellers and other third parties like attorneys act on behalf of registrants in offering some form of proxy service to prevent the public display of contact information for registrants. There are also services called WHOIS privacy services which display some registrant information such as registrant name, but conceal other identifying information like address and telephone number. So as you heard from Mike, pursuant to the Registrar Accreditation Agreement, the RAA, the Registrar Accreditation Agreement, registrars are obliged to submit registrant, administrative, technical, and billing information for each gTLD name to ICANN, or an approved escrow agent. The question is whether registrars should be required to submit additional information, such as that of the beneficial user of a name when that user is taking advantage of a WHOIS privacy or proxy service. In the case of these kinds of registrations, the contact information of the beneficial user may not be escrowed, it may not be available in the event the registrar has some problems, if their accreditation is terminated or they fail or come close to failing. On the other hand, the registrar may not know whether they are dealing with a proxy registration or a straightforward registration from the actual user of a name. So it's a very interesting question, how much information should the registrar be obligated to require to deposit into escrow, and how should we balance that against the privacy interests of registrants who have chosen to use a WHOIS service in order to prevent onward transfer of their private information. We have two representatives of the ALAC here on the panel, and I would also like to solicit comments on this particular subject from the crowd, but Vittorio or Beau or anybody else on the panel, if you would like to talk about this precise question, let's have a conversation. Vittorio, you want to start? >>VITTORIO BERTOLA: Yes. I think I need to make a premise first. I heard that (inaudible) three-part activity and this is incorrect because at least in my activity -- >>SUSAN CRAWFORD: I'm sorry, I didn't understand, Vittorio. >>VITTORIO BERTOLA: I heard that escrow is a three-party activity between ICANN, the registrar and the escrow provider. Actually it is a four-party activity because there is the registrant who is the actual the legal owner of the information when it is an individual registrant or when it is an individual contact for a legal entity registering domain name. At least in Europe. In the other parts of the world where you have that kind of data protection laws. So actually, I hope that the homework was made to check that what ICANN is proposing to do is legal and the various data protection regulations, because otherwise we might be creating another WHOIS style problem. And again, the issue of proxy services is similar. Proxy services are the wrong answer to a fair domain for privacy. So actually if we had a correct policy on WHOIS information that allowed people to have their degree of privacy, then people wouldn't seek for alternate ways to hide their information. And so you could have people actually supplying their accurate information and this information being escrowed by not being publicly displayed. So I think that now it's a difficult situation also because whatever you might do might be seen also as an attempt to influence the discussions going on in the WHOIS field. So I'm sure some people will complain about that. I have already seen some people standing up from the floor. And so I think that one solution could actually be -- I mean, there is a special case, which is when the proxy service is provided by the registrar itself. Because if the proxy service is provided by some other entity, then if one fails, the other is unlikely to fail at the same time. Whereas if it's the registrar that also provides the proxy service, then you might have the need to ask the registrar or require the registrar to escrow the information as well. >>SUSAN CRAWFORD: Now, can we separate out -- I want to call on Jon or Rob, whoever wants to go first. Can we separate out WHOIS and escrow in your minds and help us figure out a way towards a solution in this instance, if it's possible. >>JON NEVETT: Let me address that. A number of registrars, because there's a market demand for additional privacy due to the WHOIS situation currently, there is a very strong market demand for privacy service. So some registrars have what's called a private or privacy service or private registration. Other registrars actually have a proxy service where an affiliate of the registrar becomes the actual registrant. So there are two different styles of privacy services. One is a private registration where you still have the registrant information being the same, and then one is a proxy service where you actually change the registrant to the proxy service provider. >>SUSAN CRAWFORD: So when it comes to escrow, what should we do in the registrar's view? >>JON NEVETT: From an escrow standpoint, based on both of those models, every registrar on the panel that we pulled together all agreed that to the extent they have either a privacy service or a proxy service, the underlying data would be supplied to the escrow agent. That is not publicly available, so it doesn't impact the privacy rights of the underlying registrants, but it is available in case there's some kind of a disaster or a failure of the registrar. So it protects the registrants without giving any additional privacy. Of course, that was just the seven on the committee that voluntarily would agree to that. I personally would agree to some kind of change to make that mandatory because I think it's the right thing to do. But that has not been discussed generally yet. >>SUSAN CRAWFORD: We're going to get to a whole segment on changes to the Registrar Accreditation Agreement. So what Jon has said is that, for those registrars in his group of seven that actually have access to beneficial user data, they would agree to escrow that data so that you could put the registrar back together again in the event of a failure, and someone else could run those registrants' information. But that the information put into escrow would not be made publicly available. The WHOIS debate is about making information publicly available to anyone on the Web. But I saw Wendy Seltzer coming up. Come to the mike and tell us who you are and what your reaction is here. >>WENDY SELTZER: Thanks. Wendy Seltzer, individual on at-large. And to me, the issue of escrow is an issue for the benefit of the individual registrant. And so the question should really be asked to the individual registrant, do they want their information put into escrow so that the domain name can be kept with them in the event of a disaster or do they value their privacy or anonymity even more strongly than that continued connection with their domain name and so would they prefer never to have their name associated with that domain name, even if an escrow service? >>SUSAN CRAWFORD: Can you imagine the educational challenge of telling an ordinary registrant the difference between escrow and WHOIS? It's an honest question. Could we actually communicate that clearly enough so that people could get that? >>WENDY SELTZER: I think we could. I think that there is admittedly a small pool of people for whom that's going to be the critical issue. But I don't think we should be putting something into the contract ostensibly for the benefit of end users that's going to be against the interest of some of those. So it's more a plea for flexibility and provision of information, not mandating any specific response to potential data loss that's going to end up going against the interest of some registrants. >>SUSAN CRAWFORD: Okay. Other responses from the panel. Rob. >>ROB HALL: Susan, if I may, the issues of escrow are actually larger -- excuse me, issues of a proxy server are actually larger than we have been talking about. So we often see law firms acting as a proxy, where the registrar would have no knowledge of who the beneficial owner would eventually be. The other big one is hosting companies that register on behalf of their hosting client. And I would submit that they fail far more often than ICANN registrars, thankfully. But that causes problems. The interesting thing is with a proxy service, who owns the asset? So if you turn your mind for a second to think that the proxy service is often a separate company that is the registrant of that name and would have that as an asset, and if there was ever a lawsuit against the proxy service, that could be claimed by a receiver as an asset of that proxy service. If you turn your attention to the RegisterFly instance, even if you have been successful in knowing who the underlying beneficial person end-user was, we would need contract changes and perhaps a court to say take it away from who the registrant is being that proxy service and give it to who we think or who we know through our escrow process is the beneficial user. So this is not as simple as it may seem on the face of it in that we may end up with third parties not being registrars. So while ICANN can certainly govern how a registrar behaves we often have third parties today and we have to keep in mind that they are actually the owner of that service of the domain name and that causes additional difficulties, unfortunately. But I do like the suggestion of allowing -- if we are to escrow, and I think most would do it voluntarily, most registrars would do it voluntarily, I'm not sure we could get law firms to do it, to the registrar, I do like the idea of allowing a user to opt out of that. >>SUSAN CRAWFORD: I have a second -- a function here which is not only to moderate but also to be the time keeper. And so we have to -- we may have to cut off this segment after the next comments. We need as much input as possible. So I'm going to ask for questions, the people at the mike who care about this issue, proxy registrations and escrow to talk to us and then we're going to move on to the next topic which is amendments to the RAA. Big topic. >>JEFF NEUMAN: I am Jeff Neuman with NeuStar although this comment is on my own behalf, not on behalf of NeuStar. I would think almost everybody in this room has a cell phone. And when someone has a cell phone, they get a phone number, and they give the cell phone company all of their personal information. In fact, much more than that which is required for a domain name. And it's hard for me to fathom that there are privacy arguments here as to whether one should have a right -- or privacy concerns. Because maybe unbeknownst to you but all of your data is kept by the cell phone company, and most of the reputable ones escrow that data. And that is for a person's protection and to make sure that that data is not lost. So it's hard for me to -- if you are going to try to make comparisons to -- at least in the United States. I can't speak for other countries. But if you are going to talk about privacy, let's make analogies to the world outside of domain names because there's a very large world, and there's lots of data that's given and lots of data that's escrowed, and not displayed. So it's very important to consider. >>SUSAN CRAWFORD: Thanks. Next speaker. That was a voice for paternalistic realism. Moving on to Michael. >>MICHAEL PALAGE: Mike Palage. Actually, to build on Jeff's comments about looking at other models in the world, I'm encouraged by the comments of Jon Nevett about, if you will, escrowing the underlying proxy data and I think this is important because one of the things I have seen recently within the legal context is people beginning to argue over the ownership of domain names. I was recently contact to a law firm prior to making a large acquisition and they said how can we guarantee that these domain names that we are about to acquire for a large sum of money are in fact owned by the people who are representing to own them. So when one wants to look at protecting the rights of registrants either current or future, we need to look at having some type of accountability or title to be able to track back. And just again -- >>SUSAN CRAWFORD: Title, wow. >>MICHAEL PALAGE: -- not being pessimistic but looking forward, once this proxy date probably does get escrowed, when some of these disputes regarding ownerships of domain names which are rather substantial in value, it's most likely that, through discovery, people are going to try to have access to this limited data to see who owns it. So again, just being forward thinking, this is likely what's going to come. And perhaps in looking at protecting registrants we may want to look at trying to account for that as far as ownership rights in this particular asset. >>SUSAN CRAWFORD: That's very interesting. And it raises other wrinkles for the proxy question, too. Who really was supposed to be in control of that asset. And why would a registrar necessarily know, as Rob hall has pointed out. Next speaker? >>STEVE METALITZ: I'm Steve Metalitz with the intellectual property constituency. And I just want to mention two other provisions of the existing registrar accreditation agreement that may relevant to this question. One is section 3.7.7.3, which provides that in some circumstances, and I won't go into what they are, when there's a proxy service -- proxy service is acting as a licensor of the name and the beneficial user is the licensee, then the licensor has to disclose the underlying data when presented with reasonable evidence of actionable harm. Now, it wasn't really intended for this purpose, I suspect, but I think could you make a pretty good argument that in a registrar failure situation, ICANN would be able to show a reasonable evidence of actionable harm. So that might be another factor to take into account here. The other provision I wanted to mention is 3.3.4, which talks about the situation -- the circumstances under which registrars would contribute data to a centralized WHOIS database. And I'm wondering if there are -- if any consideration has been given to moving beyond the centralized escrow system and taking the data that is there and using it in the centralized WHOIS database. It seems like a very opportune time, as long as you're setting up a system in which exactly that data is going to be deposited in exactly one place, to also think about whether that could lay the groundwork for what the RAA has set out as the goal, which is a centralized WHOIS database. >>SUSAN CRAWFORD: I want to look over at the panel, see if there are any responses to the first set of comments. Kurt, did you want to say something so far? >>SUSAN CRAWFORD: Let it go still? >>ELLIOT NOSS: I think the centralized WHOIS database is probably right there with the $100 million DNS fund. We'll kind of put that off to the side. I'd like to make a comment -- >>SUSAN CRAWFORD: Are you providing us with a $100 million DNS -- >>ELLIOT NOSS: No, I believe that was VeriSign. I'd like to make a comment that, you know, as Rob mentioned, there are millions of names where the admin contact is the Web hosting company, you know, I've mentioned this before, but I think it's very important to inject into this conversation at this time, that is a historical practice that has been one of good behavior on the part of the hosting companies and ISPs and complicates this issue, because that's overwhelmingly done to protect registrants from the confusing world that is domain names. I think one of the things that we have to be very careful about is to see any practice that insulates registrants from their domain names as just, you know, all things being equal, a bad practice. Overwhelmingly, that is done to provide better service and to simplify the use of domain names. And so I want to make sure that as we are considering what we do here, we take ample notice of the fact that Web hosting companies and ISPs are the entities that almost without exception are the ones that are helping end users actually use these domain names that we provide. Thanks. >>SUSAN CRAWFORD: Thank you, that's a very useful comment. >>KURT PRITZ: Elliot, can I ask you a question? It actually goes to the comment I was going to make. In my mind, the data escrow program is meant to eliminate a single point of failure. So the registrars escrow their data with another entity. In the case of proxy registrations, where the registrar is holding that data, if that's escrowed also, the privacy data, that would eliminate that single source of failure. But if it was a different entity, such as a hosting company or an attorney, then there would have to be two failures. So it seems that it might be reasonable to have, you know, one layer of, you know, privacy escrow that's -- privacy data that's escrowed. >>ELLIOT NOSS: It might feel clean. But I don't know that it's reasonable. Let me give you a great complication that you're going to be facing very soon. AOL has a program right now where they give out free domain names. The catch is, AOL owns them. They'll do all sorts of marvelous things, take this domain name, we'll let you register 100 e-mail addresses free against those domain names. I guarantee you, Kurt, at a minimum, 60, 70, 80% of the people signing up for that program don't know they don't own that domain name. It's going to be six, five, eight years from now when those people try to change their service, the e-mail their family has been using for five years and they find out they don't own their domain name that you're going to be confronted with exactly this, you know, kind of data protection issue. And by the way, you know, that's very clean. It's AOL; right? You've got that kind of easily escrowable data. But I think it's the difference between kind of legal and beneficial interests here that we're talking about with this escrow that -- you know, it's just -- we can't just wish it into the corn fields. It's just not a simple point like that. >>ROB HALL: It's even worse, I believe they are a registrar but don't -- >>SUSAN CRAWFORD: Which is another topic. One final comment here on this. >> J. SCOTT EVANS: Just to Kurt's point -- my name is J. Scott Evans from the International Trademark Association. I think we're all ignoring the reality here. The reality is, the information does need to be escrowed at some level. We cannot protect every person in the world who has a contractual relationship with some entity that is providing a privacy service. They are going to have to have some sort of care of their own interest in this relationship. And to make sure that the law firm, the registry service, the registrar, or whomever they use is reputable and is taking the necessary steps. But as far as ICANN is concerned, and the registrars are concerned, that information does need to be escrowed so that in the form of a failure such as RegisterFly, that the majority of those names can be switched over. And if there are glitches and problems that seem unreasonable, then the registrant's going to have to take that up with whoever they contracted with, and we just have to have commercial reality here. And to allow someone to opt out of this is absolutely ludicrous. It's not done in -- if the information is private and there is -- there are market reasonable proxy services and things for people to keep this data off the public database, it should still be escrowed so that the system can work and that it would be to the benefit of the Internet community as a whole that we can minimize the disruption that these failures can cause. >>SUSAN CRAWFORD: Thank you, Jay Scott. So Rob and others have pointed out that our relationship -- ICANN's relationship extends only to registrars, and those registrars have access to only X amount of data about registrants. The question is, what should ICANN's role be in mandating escrow. I think we're all agreed that some form of escrow should be mandated. How far does that reach into these other commercial relationships? And our chairman has a final comment. >>VINT CERF: I just wanted to say that the comment that there are many different relationships between the ultimate end users and institutions between them and the mechanics of the domain name system is a really important observation. Often when you get into disputes about solutions to things, it turns out it's because you had a different model of the problem that you were trying to solve. So I'm sure -- I missed some of the early parts of the discussion, so perhaps you've gone through this before, but it seems to me we might need to codify some examples of cases of particular sets of relations, how does this user end up with a domain name, and with which parties is their relationship? We might be -- find ourselves confined at ICANN to reproduce information only within a certain boundary of our contractual relationships and not necessarily be able to reach very much farther out beyond that. We certainly can't boil the entire ocean. But it's important for us to recognize that there are a wide range of different relationships and models for linking people to domain names and that we shouldn't accidentally pick one model and assume that represents all of them. >>SUSAN CRAWFORD: Thank you, chairman. Our second topic for today's workshop is amendments to the registrar accreditation agreement. The RegisterFly situation prompted considerable concern about what that document actually said and what ICANN was empowered to do with respect to a registrar. Back in Lisbon, as you heard from Paul Twomey, the board and Paul called for a review of the RAA. And they said -- we all said we wanted to make sure that this agreement gives us the ability to respond more strongly and flexibly in the future. And he listed several topics that he wanted us all to deal with. We have two sets of issues for this portion of the workshop. One is, what process should we use to amend the RAA? There seems to be general agreement that it needs to be revised for the 21st century. Given the amount of energy and anger and momentum associated with this issue right now, we could just lock the registrars and ICANN staff in a room and say, "All right, come up with an agreement and we're going to put it out for public comment, we're going to change a lot of it and get everybody involved in commenting on the agreement and then start fresh with a new RAA." That's one route we could take. Another route will be suggested by Kurt Pritz, which would involve only taking a few topics at this point and fixing the RAA with respect to those few topics and moving that through a consultation process with the GNSO council and thence to the board. So that's one subject for this portion of the workshop, how to do it. The next subject is, what should we do. And Kurt is going to outline six issues that he's focusing on particularly in the RAA. So, Kurt. >>KURT PRITZ: Actually, I think Rob is going to introduce the topic. >>SUSAN CRAWFORD: Okay, go ahead. >>ROB HALL: I should mention -- and I'm speaking personally here not as the vice chair of the registrar constituency. So my thoughts and what I speak about today are my personal opinions. I've been asked to talk a bit about the history and changes to the RAA. It may come as no surprise or some surprise to some of that you we're actually on our third version of the RAA. It's been amended twice in the past. The original version was published in '99, it was amended later in '99, and further amended in 2001. So this is actually not the first time we're trying to amend the RAA. In the old days, we had no RAA and we had a monopoly registrar. And a competitive level called registrars was introduced to solve the monopoly problem. And they have different business models. However, the interesting thing that they all have is, they have the exact same contract for every one of them. So unlike the registries, who have different contracts, the registrars are all on the same contract. I think that's very important. Even though they have different business models and serve different communities, they're still all governed by exactly the same contract. Registrars also have two different types of contracts. We have the RAA, which we've been talking about here today and will continue to discuss how to change. We're also governed by RRAs, registry/registrar agreements. And these change much more often. I think we've had a couple changes to the COM one, the net one, and the org one -- I'm sorry, the dot biz one, over the last several months. So these contracts are ongoing and in flux, and, unfortunately, are negotiated by the registries on our behalf sometimes. I agree with the comment earlier that registrants are concerned and don't often understand that a domain name is governed by these contracts, given that a domain name is a service. So these contracts are key to how a domain operates and functions to a registrant. It's interesting that recently at a domainer conference, they produced what they call their bill of rights, wanting basically to assign property-type rights to a domain name. So there's many different opinions and many different registrants' opinions of what should be a domain name and what should govern it and how should it be governed. And we've talked about one already, privacy versus anonymity. We will be discussing later the changes ICANN would like to put forward to the actual contract that we now have. And I'll hold my comments on the specific ones until then. But I should point out that some of them that we'll talk about today may have broad registrar consensus, and some of them clearly will not. The registrars haven't had a chance to meet and discuss this yet, and I suspect that in tomorrow's meeting, we'll begin to debate the issues and discover what concerns registrars have with the existing contract that they would like to see changed. So we've heard and will hear today what concerns ICANN has, and certainly the registrars will begin to discuss what concerns they have. I think most registrars are open to negotiation changes to the contract. We realize there's been deficiencies in it. We've learned over the past six years since the last change what we may need to do to change it to make it more effective for ICANN and enforcement issues. Right now, they have, as we've talked about in the past, the blunt hammer approach, or the nuclear option, I think, as Kurt likes to describe it, of they can deaccredit. But there's no graduated scale that they can implement. I think most registrars would like to see that. I personally advocate a public posting and review process for all contracts. And although I was loudly screaming about this when it was the COM contract, I'm going to have to stand up and say I approve it for this as well. I think it should be publicly posted and reviewed by the community. It should not be done behind closed doors and then signed. It is a give-and-take process. And I think it could be done quickly, given the right incentives, and implemented in months, not years, through a PDP-type process. So I think it's very possible ICANN and the registrars could agree on a limited set of changes, and registrars could voluntarily sign that contract. So our contracts renew every five years, and rather than waiting for that renewal time, it's possible that ICANN and the registrars could come up with a contract that's better for both, and both want to immediately move to it. Now, you may not get all of them, but you certainly would get the vast majority of them, I think, if the right incentives were in place. I think it's also -- we have to look at not just the contract, but the accreditation procedure and process. We'll talk a lot about the contract today, but we have to remember there's also a process and procedure that we go through to get accredited in the first place and that's reviewed on renewal of contracts every five years. RegisterFly seems to be a platform-driving change, but in a competitive environment, we're going to have failures. The systems are belt that registrars are by nature competitive. I remember John Kane of eNom at one registrar meeting saying his greatest joy would be to put us all out of business so he has it all. And that's what the system should be doing. So we are going to have failures, and we have to find a way to deal with it. In the case of RegisterFly, by and large, although with some pain and we can improve it, the system worked. The asset that RegisterFly had was sold to another registrar who is now operating it and taking care of the registrants. So although there was pain involved and although it took way too long, ultimately, the right thing happened. And ICANN should be congratulated for how they dealt with that, because it was a system and a process put into place that didn't really contemplate that. And that's what we need to change. It's important, I think, not to knee-jerk and focus on only one or two parts of it. These things are very complicated and tend to have effects that we don't understand if we're not careful. So we can shoot at one specific thing and say I'm going to fix that, but the possible side effects to a solution that cause unintended things, we've seen that happen many times in ICANN. And we certainly want to be sure we're not doing that here. We must also keep open minded about different business models. The whole point of the registrars are to foster competition and bring creativity at the registrar level, but maintain equal treatment for all registrars. And I think that's very important. So we treat them equally from an ICANN contract point of view, but we still encourage their differentiation and competition amongst them. I'm confident we can find a way forward and I look forward to participating in the process and the debate that will follow later today after Kurt presents. >>SUSAN CRAWFORD: Thanks. Kurt. >>KURT PRITZ: Thank you, Rob. Thank you, Susan. So as Rob indicated and other presentations have indicate, there's two issues here, really, what we're going to do and how we're going to do it. So what we're going to do would take the form of amendments to the RAA or actions that -- and agreements that don't require amendments to the RAA in order to improve the environment for registrants. Secondly, how are we going to implement these changes, what's the process for doing that. The RAA specifically calls out a consensus policy process for making amendments to that agreement. Now, I have consensus policy in quotes, because it's not the policy development process that many of us are familiar with. And this term "consensus policy" in the RAA actually predated the development of the present policy development process. So it's specifically defined in the RAA. We should look at that definition and requirement in the RAA and determine how best to implement changes that meet that requirement and do it in a timely way. So thus far, ICANN staff and the registrar constituency met in Lisbon to discuss potential amendments. And we spent some time on each of those that I'm going to describe in a minute and that Paul described very briefly at the start of this presentation. Not surprisingly and as you've heard, there's enthusiasm about moving forward and making improvements. There's a split among the constituency members and us on the panel and ICANN staff and ICANN board and people in the community on how we're going to do that. What ICANN's done and what's posted are sort of one-page summaries on each of the amendments we're going to talk about here. They attempt to reflect the potential benefits and potential risks associated with each one of the amendments. And I think at this meeting the conversations that Rob mentioned and also additional conversations the registrar constituency will find an effective way to work with ICANN, taking into account community input. So whether that's locking us all in a room and not letting us come out until we're done or making incremental changes on a regular basis or some other form, populated by some other -- some members of the registrar constituency and ICANN is to be determined. So, really briefly, the amendments that were proposed by ICANN's posting last March 22nd I think it was have these titles. And I'll only say two or three sentences about each one. But the first is intended to address the responsibility of apparent owner manager when there's one or more in a family of registrars that fails to comply with ICANN requirements. So this might be a tool to -- where potentially negative practices could be discouraged or that ICANN could have additional compliance tools in its quiver. The second has to do with the contractual relationships ICANN has to do with resellers. I'm only going to say the words "RegisterFly" a few times during this presentation. But RegisterFly was at one time a reseller. So if there were an amendment here, it would be intended to augment the responsibilities placed on registrars with regard to their relationship with resellers. And the thinking behind it is that registrants could benefit from enhanced reseller compliance with ICANN policies or that some sort of reseller accreditation terms would avoid problems before they occur. And I suspect that many registrars essentially have these safeguards in place already in their dealings with resellers. Hopefully the last time I'm going to mention the word "RegisterFly" is the discussion of accreditation by purpose. The good news sort of is that RegisterFly did not get an ICANN accreditation, even though it went through the accreditation process. It did not succeed. But the bad news is, it acquired an accreditation by purchasing an entity with an accreditation. So this amendment would be intended to govern the terms under which a registrar can be -- or an accreditation can be sold and continue to retain its ICANN accreditation. And the intent here would be to ensure that all entities being ICANN accredited registrars meet the same requirement. The next amendment is intended to require operator skills, training, and perhaps certification for ICANN-accredited registrars. So it could establish a common standard of operator performance or ensure some level of competency on registrar staff. And, again, I think that most existing registrars would place out of this process by demonstrating the competency and skills on their staff already. Private registrations and registrar data escrow requirements has been discussed already. So I'll skip that. But it's a very important discussion. And then, finally, amending the RAA to include additional enforcement tools. The thinking behind is that is that graduated sanctions would provide more measured responses to less-serious breaches, and that registrars that breach the agreement could be penalized without potentially penalizing or hurting registrants. So that's the discussion of amendments. I certainly agree with Rob and others here that other amendments are required, because the environment has changed significantly through 2001. And part of our discussion is about how we want to do that. And so -- >>SUSAN CRAWFORD: Would you take us -- take us through the process that you're suggesting for them in the RAA. >>KURT PRITZ: Okay. So as a preamble to that, if it's okay, the change process in the RAA requires this quota consensus policy has been one barrier to change. And the other barrier is, all these issues lumped together seem to generate a reticence to attack it, because there's just so many issues that we don't want to miss one in this once every five- or seven-year exercise in order to update the RAA. So the process I want to discuss, Susan, would meet that definition in the RAA and also be -- implement a process that regularly or periodically examines the RAA so that we're not afraid of missing the boat; there's going to be another round next time. So the requirement as it's understood in the RAA requires a consensus process or a consensus policy, as it states, that requires a supporting organization vote, a board vote, and a final report. And so this requirement could be met by taking public input, community input, and synthesizing that input into a synthesis of issues document, probably not unlike the ICANN strategic plan that starts with a -- not unlike the ICANN strategic plan that starts with an issues document that's posted for public comment. Then draft proposed amendments could be written by the registrar constituency members and ICANN. And those also could be submitted for public comment. Proposed amendments could be reviewed. There would be another bite at the apple for suggesting additional amendments. And there would be sort of a do-loop there iteration to settle that out before there's a final draft that would be submitted to -- for a sort of up or down vote by the supporting organization and the board. So this is probably an eye chart. Not that bad. I just want to call out that -- in this process, there's significant opportunity tore public input and if you want to look at this chart, it's posted online, and comments later as part of the blog or public comment forum for the whole ICANN meeting. >>SUSAN CRAWFORD: Okay. Great -- >>KURT PRITZ: Wait, wait. I have one more slide on this. >>SUSAN CRAWFORD: Well, I think we should start talking about -- go ahead, go ahead. I'd like to get the debate going here. >>KURT PRITZ: Let's start talking about T so the benefits and protections, I think, of such an approach are that it provides a timely method for getting things done and it provides multiple opportunities for public and community input. The regularly scheduled nature of it would mean incremental improvements could be made rapidly, and we can go back and visit other issues again. GNSO up or down vote on a proposed slate of amendments does not preclude the ability for a Supporting Organization or other part of ICANN that's empowered to start an alternate process. And I think, too, that there's a motivation that know alternative process will be launched if significant process is made. So these are the benefits of that approach. Is that it? Yeah, so the time line for going forward is to work with a registrar constituency on this while we debate this process, make headway and make some proposals in Los Angeles. >>SUSAN CRAWFORD: Thanks, Kurt. And I'm sorry to be pushing you along. It's just that we have a lot to discuss. Two big chunks of topics here. One, the how. How do we amend the Registrar Accreditation Agreement? Second, what? Are these the right topics to start with as we change this agreement? The ones that Kurt has outlined. I'd like Vittorio or Beau, if you want to comment on either one of those questions and we will focus on the up with you choose. >>VITTORIO BERTOLA: Actually, I have comments on both. >>SUSAN CRAWFORD: Fine. >>VITTORIO BERTOLA: Maybe let's start with the first and then we'll discuss later on the other issues. The process. I start by saying that this issue of the amendments to the RAA is fundamental to registrants because actually the RAA is the instrument that defines the market. It's the license that allows registrars to operate, to sell domains, and it defines really what can or cannot be done in the relationship with the registrants. And so after the RegisterFly case, there are really high expectations that this contract will be revised because there is a long list of areas where it is shown that it is inadequate. So this is why I'm really unhappy about the proposed process. I think that the process that is being proposed is entirely unacceptable, because we would expect the contract to be discussed between both sides of the market, the supply and the demand side. So to have a working group including both including both the registrants and the registrar users to discuss what needs to be changed. To me, just having the registrars agreeing on a new contract, it's like if a regulator of the telecom system asked the telecom operators to agree on the new terms of licensing. It doesn't really work. It really looks crazy to me. So I think there's an advantage to registrars themselves to discuss this at the early stage with registrants because actually registrants have a lot of on the field experience as well. So it's like having a free focus group for your next products. And it's actually easier to get it right rather than just having a new contract developed among registrars with the support of staff and then maybe have some public comment that you never know how it's being taken into account and then just try it in the field. So I understand also that -- I mean, I understand that for registrars, this is the base of their business. I understand concerns about possible extra courses have to be incurred to support any new features of the contract. I think we can be quite reasonable. I don't think we are going to say anything really impossible. But actually the argument that we have been waiting for six years to make changes so there is such a backlog that we cannot deal with the problem is also ridiculous to me. I agree we need timely amendments, and need a regular process, but exactly because there is such a backlog and there have been such problems, we need to have a deep look at the entire contact and try to bring it up to the reality as quickly as possible. Thank you. >>SUSAN CRAWFORD: Beau, did you want to say? Vittorio, I didn't mean to cut you off. >>BEAU BRENDLER: Yeah, actually, the good news is I am going to basically scrap the entire set of slides that I prepared. >>SUSAN CRAWFORD: Thanks. >>BEAU BRENDLER: And the other good news is I am, in fact, not going to mention it either, at all. So what I did want to say is the consumers whom I represent -- when I say "I represent" -- >>SUSAN CRAWFORD: Be close to the mike so we can hear you. >>BEAU BRENDLER: When I say I represent, I work for consumers union which basically its constituency is 7 million or more consumers in the U.S. or Canada. And it strikes me basically that the primary concerns of the people who I talk to and work with are simple issues like spam and phishing. The simple issue for people who we talk to and work with are not issues on this level at all. It's really preventing fraud, preventing or curbing Spam and dealing with phishing issues. So stepping back and looking from that, I went through the Registrar Accreditation Agreement six points that Kurt went through and kind of the same issues keep coming out which is from the perspective of the consumers who I talk to and hope represent the most, those kinds of measures that increase compliance are good. You know, there may be some sort of system that ICANN could seek or work with a second party to create some kind of ratings, objective ratings of registrars or create a process where guidelines for best practices for these organizations are disseminated and talked about and then the organizations are held to. I actually agree with what was said earlier about public posting and publicity but along with that is if you are going to talk about these kinds of things to the public, you have also got to publicize them in a language in which they will understand and I don't think a lot of what is being talked about here is understandable to the kinds of consumers and folks who I know from my work. I guess I would also say some other things you might want to consider is I know there's an audit going on right now of the 900 registrars. Maybe make that audit data public so that somebody could take a look at it or consumers could look at it or somebody could help consumers interpret it in order to make choices. >>SUSAN CRAWFORD: That's very valuable. Thank you, Beau. Beau is suggesting ratings, which is one of the suggestions made by Paul Twomey in his March list of topics. Guidelines for consumers, much more publicity, much more information going out to consumers. And also transparency of information about registrars so that we can compare and see what has happened with registrars. Now, there are countervailing arguments on many of those points. Let's stick right now with what goes into the agreement and move on the process secondarily because I think Beau's comments are really interesting. Does anybody on the panel want to respond on the "what" issues, what should be amended in the RAA. Chuck. >>CHUCK GOMES: Sure. One point in particular that's required in the RAA right now is the Supporting Organization approval. I personally think that's -- and I'm speaking for myself as an individual, not for the council and not for the registry constituency because we haven't discuss this had. But I think it's not consistent with the role of the GNSO to approve contracts. I do believe that it is the responsibility of the GNSO to develop policy that if it's consensus policy would be included in those agreements. And so I think that is a correction that should be made in the RAA. >>SUSAN CRAWFORD: Okay. That was a nice self-referential comment. It's a comment about how to do that should be put into the RAA. Chuck is saying let's change how the RAA reads so the contracts really come from ICANN and the contracting party and aren't approved in their first iteration by the Supporting Organization except through the engines of public comment. But that amendments, changes, later to a contract that fall within the picket fence of consensus policies would be subject to Supporting Organization review. That's kind of inside baseball, but it's a nice suggestion to have here, and an interesting one. All right. But let's stick with the what. Kurt gave us six, Beau us gave us some more which were not on the six. Vittorio, you want to say something? And I also want to give the registrars a chance to respond. You go first, get it out on the table and then we will go to the registrars. >>VITTORIO BERTOLA: I just wanted to add three more areas that were pointed out by the ALAC in the statement we made in Lisbon on this. >>SUSAN CRAWFORD: Okay. >>VITTORIO BERTOLA: That I think should be discussed when revising the RAA. The first is transfer away fees and procedures. So how do you transfer away your domain name from a registrar that is not providing an adequate level of service. Which partly might be an issue of the RAA, partly of policies. But still this is the basic break of the market. It is not a market if you cannot switch your supplier easily. So actually a lot of problems in the RegisterFly case would have been avoided if the registrants would have been actually able in practice to take their domain names away when it was start to go fail. >>SUSAN CRAWFORD: So you are suggesting we avoid lock-in effects by registrants by making easier, lower fees to transfer names. >>VITTORIO BERTOLA: We should provide provisions for that effect. And the second area is information. So having a clear statement of the rights and what registrants can actually do with their domain names so that they know what to expect. So I think that registrars should be provided -- should be required to provide that information to the registrants so ICANN could have maybe a simple text in many languages. A bit like, for example, airport operators are required to post passenger charter of rights and duties. So registrars could try to make the information easily available. Just some Web pages, but it could really be of help to registrants. And the third area is (inaudible) official language and I am not a lawyer but we have one on the committee and it's about how we can enforce the contracts actually in a court. >>SUSAN CRAWFORD: Oh, third party beneficiary is the last topic Vittorio is raising. Whether someone who is not a party to the contract, not one of the two people, ICANN or a registrar, could bring a claim based on a breach by the registrar of its obligations to ICANN. Right now, the agreements say that there are no third-party beneficiary obligations or rights created under the contract. Okay. So we've got lots of whats there. Time to respond. Jon? Rob? Rob. >>ROB HALL: I'm sure Jon will chime in. I will take first crack at it. From a registrar point of view there are many things that could change in the contract and I don't want to speak to all of them but two I think of off the top of my head would certainly be fees, and I know it's a hot topic with registrars -- >>SUSAN CRAWFORD: You want them higher, rob? >>ROB HALL: Yes. But just for Jon. [ Laughter ] >>ROB HALL: The other thing is you mentioned the term picket fence and I think that's very important. Right now our contracts allow any consensus policy whatsoever to effect us. And I think if we were to put a fence around the type of consensus policies that could effect us, registrars would certainly appreciate that. I think if you looked at auto renewal provisions, like the registries have in their contract where there's -- I'm sorry, not an auto renewal but a presumption of renewal that's in the registry contracts currently, registrars would love to have that. So there are many things I can think of off the top of my head that registrars might like to see changed in it that we haven't yet discussed. Interestingly enough, this has turned into, a bit, and I think we have to be very careful not to let it become let's throw every pet project we can into the RAA discussion. So I heard someone mention two things I want to talk about, a change in transfer policy, which does not mean any changes to the RAA. The RAA currently says if the transfer policy is changed we are all bound by it because it's consensus policy. So to right a transfer policy specifically into the RAA is probably not the method and we should not be discussing that as part of the RAA. And the use of a domain name, again, these are things that I'm not sure registrars should be trying to define how someone uses a domain name. >>SUSAN CRAWFORD: What does that topic mean? What do you mean use of a domain name? >>ROB HALL: I believe Vittorio said we should be telling the users what they can and can't do with a domain name. >>SUSAN CRAWFORD: Did you say that? >>ROB HALL: And make it clear to them. >>VITTORIO BERTOLA: But it was more in terms of rights. So you are entitled to transfer, for example, your domain name. Giving them information on -- not what they can use domain names for. So not about making a Web site or using it for e-mail, but -- >>ROB HALL: Okay. >>SUSAN CRAWFORD: Forget it. >>ROB HALL: I apologize. I misunderstood then. But the other interesting thing is ICANN -- >>VINT CERF: Rob, I'm sorry to interrupt. You are going too fast for our scribes and I will ask you to slow down a little bit because we don't want to miss content. >>ROB HALL: I have to apologize to them because they did come and speak to me earlier. But Susan is going faster faster and the scribes are going slower, slower. >>VINT CERF: Don't let enthusiasm get in the way of communication. >>ROB HALL: I believe we already have clauses we have to pass on to our users and our registrant contract in the registrar contract -- >>SUSAN CRAWFORD: Slow down, slow down. >>ROB HALL: Sorry. I believe -- [ Laughter ] >>ROB HALL: I believe we already have clauses that registrars are required to pass on. So perhaps it's a chance to review those, and that would ally some of Vittorio's concerns. >>JON NEVETT: If I could just jump in. >>SUSAN CRAWFORD: Jon, yes. Slowly. >>JON NEVETT: I think we have to be careful not to use this endeavor as a way to make new policy or change existing policies. I think many people in the community raise that concern when the various registry agreements were considered over the past couple of years. There's a significant policy-making development process. And it's becoming more effective as we go on, as Paul Twomey mentioned earlier. If we try to make and change policy as part of this contract, we'll never make the important changes that we want to make quickly. And that would protect the rights of registrants. For example, the transfer issues. There is a transfer policy. There's a transfer review process going on right now in the GNSO. We should let that process work. If we try to change the RAA to change WHOIS policy, for example, it will get bogged down in the same debate that the WHOIS working group and task forces have been bogged down in. And I think we should try very hard to avoid that and let the policy development process work independent from the changes of the RAA, so we could actually change the RAA in this decade. >>SUSAN CRAWFORD: How would you suggest going about changing the RAA? What process would you suggest be used, Jon? >>JON NEVETT: I mean, if we want to move from substance to process -- >>SUSAN CRAWFORD: Yes. >>JON NEVETT: -- I am a firm believer in public comments. I specifically asked that the board change the bylaws of ICANN to ensure that any contract with a material impact on a third party would be up for public comment. That change has been made, but that -- certainly that change has been heeded, and that has happened since the dot net experience. And we appreciate that. We still -- I still think there should be a change to the bylaws, but as long as we're going along with that process, that's fine. What's good for the goose is good the gander. I am fully supportive of a public comment period and getting significant input ALAC and from the other GNSO constituencies on changes to the RAA. With that said, I think it will require a working group of the registrar constituency and a group of ICANN staff members to actually put pen to paper, come up with a proposal that folks can comment on. And so tomorrow, at our registrar constituency meeting, I will ask for that kind of working group to be set up and to work with ICANN to try to achieve those kind of changes. >>SUSAN CRAWFORD: Thanks very much. I want to call on Kieren McCarthy now to see what kind of comments we have -- watch out. You are plugged in -- coming in from online. Do you want to use this mike, Kieren? >>KIEREN McCARTHY: I'm fine here. Hello. Yes. Okay. So we have on the public participation Web site we have a meeting page for each page and there's a chat room there and you can post questions. And there's been quite a lot of discussion going on. Some people in the room, some people outside of the room. A few comments. One from the third world, is there anything that's going to protect registrants in third world countries? Because obviously we are in a first world country here and this is all being done in English as well. And it's going to become a bigger and bigger issue and we need to approach the third world with this, make sure people are informed early on. You have a choice to get informed in the U.S. and Europe. TLD agent wants to say -- wants to raise the question about the RegisterFly buying the accreditation by buying another company. He wants to know what's going to be done with that, how we're going to stop that from happening. Danny Younger is with regard to the process by which we sort this out, doesn't think the traditional ICANN PDP is the way to go. He thinks the streamlined approach that's been suggested is the right way. Another question from SNS, I think it was. Has ICANN addressed the breaches in the current contracts with respect to RegisterFly? I.e., could the RegisterFly situation happen again? Have we dealt with it? If so, what are we doing? And Dave's point, this ties in with a point of mine, one of the problems with this, I think, is that the people that are affected, as Beau was saying, are the individual people out there, the individual registrants. And they don't even understand, they don't even know ICANN exists let alone sit through these meetings, let alone understand the wording. Dave Butler, this is going to be a bit of work for me, he would like a report on what we discuss here to be posted in plain English so people out there can understand. I think that's a good point, and I'll do that. I think the important point, while we move on with this, will be what happens with that report and how do we tie that into the process if we're going to involve people. >>SUSAN CRAWFORD: Thank you very much, Kieren. I would like to ask panel members for responses to, in particular, two of those inquiries. How are we going to protect registrants in third world countries? And how are we going to get the news out to individual registrants in plain language, in words they can understand, explaining what a registrar's role is and what their rights and abilities to contest treatment are. So those two questions, 30 world countries and helping communication. Rob. >>ROB HALL: I think the current model of having registrars as competitors at a competitive level exactly goes towards doing the outreach to third world countries and making sure they are taken care of. It allows registrars to operate in languages other than English. It allows registrars to educate registrants, and I would -- I think given Doug's earlier announcement of the translation that's being done of actual ICANN policies and meetings, you will see more participation from third world countries. But I think it's exactly the structure we have today that allows registrars to deal locally with local clients in their language and help educate them. So I would hope registrars can help provide the solution here to the concern that third world countries may have. >>ELLIOT NOSS: There's an interesting intersection between Rob's point and the earlier point about potential accreditation for resellers. I promise you, boy, if you want to accredit resellers, we'll be sending you to some corners of the world that will make the ICANN meetings look like they're taking place in airplane hotels. Because we and others like us have resellers in the most remote regions of the world, and in numbers. And that's exactly how those users -- those registrants at the edge get their services in local currency and local language, et cetera. I think there's a very important point, though, around the communication part that I'd like to really challenge Vittorio with. Vittorio, you said, if I heard you correctly, hey, here's this great informational role that ICANN can take. There is no -- I said that very quickly, that there is this -- yes, perfect. Well done, thank you. >>SUSAN CRAWFORD: They're used to your voice, Elliot. But do slow down. >>ELLIOT NOSS: There is no -- not only more material or substantive contribution, but more-on-point contribution that ALAC could make than to take on the challenge of creating the consummate registrants' educational information package, translating that into, boy, every language that was possible through the ALAC, and communicating that. And I'll tell you that, you know, personally, or on behalf of Tucows as an organization, we would love to participate in an ALAC-sponsored exercise of this nature. I think it is a problem for me when I hear you expecting that or requesting that of ICANN. I think that is exactly the type of work that the ALAC should be doing to make a greater contribution. And so I want you to hear this comment in a very positive way and, you know, to sort of both be challenged by taking on that work and to also hear that we're very, very happy to participate. >>SUSAN CRAWFORD: Okay. Two more comments on this, and then we're going to move on to the third of our four topics. >>DHARMA DAILEY: Okay. I don't know if this is specific to this direct part of the conversation, but my question is, what recourse do registrants have if a registry goes belly up? >>SUSAN CRAWFORD: Great segue, that's our third topic. That's our next section. So we'll talk about that. Yes? >>IZUMI AIZU: Yes, I'm also with the ALAC and also from the non-English-speaking countries. Just one example, perhaps, of making it plain, simple language is, instead of using the words such as "escrow," which is fairly a jargon for me, and so making something like the third-party guarantee or I don't know if it exactly fits, but to sort of convert these jargons into everyday language for many. And, of course, ALAC is, as Elliot said, pretty much willing to, if we can, devote our energy to make dummy's guide or something like that. Even the dummy's guide is very much American. >>SUSAN CRAWFORD: So the how and the what of what -- how we're going to change the registrar accreditation agreement, neither one of those questions has been answered in this session, I think I could safely say. Your input is very valuable to us, and we will be hearing about this as the week progresses, how the registrars decide to react, what ICANN staff decides to do. We need now to move on to a third topic. For years, we thought we needed a process for failing or failed registries, the wholesale part of this chain. We are making progress on this. I've asked Patrick Jones to describe the program for establishing best practices for new registries. And I've also asked Chuck Gomes of VeriSign to provide his comments on business continuity in terms of crisis and contingency management for all of ICANN, as well as responding to the specific topic of registry failover. So, Patrick, are you ready? >>PATRICK JONES: Thank you, Susan. And I want to thank the question -- >>SUSAN CRAWFORD: Speak up. >>PATRICK JONES: Thank you, Susan. I want to thank the question for being raised about what the protections for registrants are in the event that a registry fails. This project was included in the 2006/2007 operational plan. I've had the description on the slide. And it's, ICANN is to establish a comprehensive plan that would be followed if there's a financial, technical, or business failure of a registry operator. And what we've done since the operational plan was published last year is, we've conducted significant outreach with registries, registrars, with ALAC, SSAC, the ccTLD community, data escrow providers, just a wide variety of people in the ICANN community. We've studied lessons and examples from the gTLD registries and the ccTLD registries. And we've taken the principles that the GAC released in their new gTLD principles that were published in the Lisbon meeting back in March. And the next thing that we're doing is, you know, taking all of these inputs and putting them into the new gTLD process so that there are provisions for registry failure, registry best practices and testing as new TLDs are added in the future. In -- June 1st of this year, we published the first comprehensive report on the registry failover project. And in that report, we looked at the critical functions of a registry, examples of TLD transition, and for the first time that I've seen it anywhere, really detailed analysis of potential failure scenarios of what could happen with a registry. This project is for gTLD registries, but we really made an effort to work and learn from the ccTLD community. And as we work on creating this comprehensive plan, we want to make sure that ICANN learns and communicates with the -- those established registries that have done continuity plans and that we incorporate those lessons into our work. I really welcome comments. There is a comment period on this report. But, really, at any time, you know, please send in comments either to registry-failure-report@ICANN.org, or you can e-mail me directly. And I'd love to get anyone's feedback on the work that we've been doing. And, finally, I want to cover -- I'm going to raise two more things -- I'll be really brief. What I'm looking for frequency the community is, you know, in the event that there is a registry failure, what is ICANN's role? And should TLDs -- to what extent should TLDs be perpetual if a registry fails? Should there be a process to provide ongoing operations until a successor operator can be found? Or should there be a notice period for registrants and the community and then a process -- an orderly process for removal of a TLD from the root zone? And the next steps in the project is to move towards implementation and testing in this upcoming fiscal year, continuing to work with the gTLD registries and learn from the ccTLD community, explore the formation of a joint advisory group that can receive some advice in the event that there is a registry failure, and conduct research on areas that we need further information on. >>SUSAN CRAWFORD: Chuck. >>CHUCK GOMES: Okay. I'm going to greatly reduce my presentation. Tim, if you can go to slide 3, I'll start there. The comments I'm sharing are from VeriSign's comments that were posted to the ICANN Web site, the comment forum that Patrick was just talking about. So if you want to see them in detail, they are there right now. Let me start by saying, one more -- let's see. Was that slide 3? Okay. The slide titled "the goal of continuity plans." Okay, there we go. We all know, this has already been said, the primary objective is to protect registrants. And it's important that all the key players have failover plans in that regard -- registries, registrars, and ICANN. But it's not enough for each of us to have individual continuity plans. We need to have a holistic plan that integrates all of it together and makes sure that we're able to work together to make sure we have business continuity, again, to protect registrants. Go ahead and skip past that one. gTLD registries have been at the forefront in this area individually and contractually since the very first registry agreement. Escrow has always been required. It has always been implemented by registries. We as a company go way beyond escrow in terms of what we do. And I won't go into the details of that. But we've invested hundreds of millions to make sure that there are lots of things like redundancy and zone servers all over the world, et cetera. Go ahead. At the same time, even though registries and we as an individual company, you know, have done a lot in this regard, we absolutely are supportive of this effort of approving registry failover practices. And, very briefly, I will give you some suggestions that we recommend, some of which, really, the team that Patrick's been heading up there has already accommodated. Again, as I already said, registry failover plans aren't enough. There needs to be registrar failover plans. They're not going to be the same as registry failover plans, because it's a different situation. There needs to be ICANN failover plans. And if you read the document that Patrick referred to, they're taking steps in that regard. There's good work going on in that regard. And then again, we need to have that holistic continuity plan for all of us. Failover plans should be prioritized in terms of urgency of need. What we're saying there is that, you know, we've got a lot of work to do. There's some that's been done, but there's a lot of work to do. Let's make sure we deal with the most urgent ones in a higher priority. To the extent that they all can be done at the same time, great. That's really good. But let's make sure we get the most urgent things done. Next, failover plans should differentiate between critical and noncritical functions. We as registries do lots of things that probably aren't critical. Let's make sure we identify the ones that are critical and make sure there are failover plans for those. Failover plans should be based on the most current information that's available, because things have changed a lot since we first started escrow of registry data back in 1999. Best practices for registry failover plans should scale. There are some good guidelines, as Patrick notes in his document, about the root server emergency failover plans. But most registries have to go way beyond that and make sure they scale not only for their existing needs, but for attacks and everything else. So scale is very important. This is a really important one, and Patrick has already captured this in his document based on input that he received from the registries. And that is is that plans need to be exercised regularly so that we can learn from them. And, of course, ultimately, so that we can find out whether they really work. Escrow does us no good if we're not able to take that escrow and use it effectively in a failover situation. With regard to IDNs, failover best practices should include escrowing of any essential IDN data, such as IDN tables, very important. And Patrick addresses that briefly in his report as well. Failover plans should define the need for confidentiality of critical data. Again, Patrick addresses this in the report. It's one that we don't want to miss, because you're dealing with a lot of sensitive information in regards to escrow and so forth, and it's just important that that be continually recognized. >>SUSAN CRAWFORD: Thank you, Chuck. A key question in this context is, what should ICANN's role be? Should a domain name being perpetual? Should ICANN undertake the obligation of guaranteeing that a domain name will always work, no matter what? It's a topic on which we could spend an entire workshop. We don't have time today to expand much on it. But if any of the panelists have reactions to that question, I'd be very interested in hearing them. Rob. >>ROB HALL: So you're suggesting buy it once, never pay again, it's yours for life? >>SUSAN CRAWFORD: No, no. Buy it once, never pay again. I don't see why. Buy it once, never -- you mean the registry, buy the registry once? >>ROB HALL: What I'm suggesting is there's no renewal of it. Once you have it, it's yours. >>SUSAN CRAWFORD: That's not what I'm suggesting. I'm saying if a registry has trouble, what's ICANN supposed to do about it? How deeply should ICANN get involved in ensuring that registries keep going? Our chair may have something to say about this. >>VINT CERF: Yes. Susan must have been reading my mind. Let me start out by reminding everyone that I pretend to be an engineer, and so my views of these things often have a kind of engineering flavor to them. This is a problem of resilience, basically. And I think there are two pieces of it. One of them -- this is very much in line with what Chuck was saying -- we need to design our registrars' and our registries' operations to be resilient within themselves. I'm not sure to what degree we can absolutely enforce this, but I think we want to create conditions in which it's attractive to build resilient systems. So replication of information within the registrar itself, replication of information within the registry operation. That's one kind of resilience. Then there's the other kind, which contemplates the possibility that the registrar or the registry will, in fact, fail to operate, for whatever reason, a business failure, maybe it's a total disaster, a natural disaster. In that case, we need resilience across the system. Building resilience into a system is -- forgetting about physical stuff for a moment, just thinking about a system as a system, building resilience in requires some careful design. ICANN, I think, is not in a position to make an absolute guarantee that under no circumstance will someone's registration somehow disappear. I think that's probably just asking too much. On the other hand, I think we also can't guarantee within our own resources that under no circumstance or under few circumstances would that information disappear. There is a model, of course, where ICANN could build up central facilities, possibly, distributing them for resilience in order to be the ultimate backup. I'd like to suggest as another perspective that we try to design a system that encourages the private sector to invest in the resilience that's needed. The implication of that from my point of view is that we need to identify the -- at least the minimum set of information that would have to be available to each of the components of the DNS to recover from loss. And that is a technical design problem. If a registrar, for example, offers a set of services to a registrant that exceed this minimum set, it's entirely possible that we cannot absolutely guarantee to protect all of that registrant's interests in those services. In fact, the registrars may be offering these services as a way of differentiating themselves. But there needs to be some core information that assures the likelihood that a known registrant will be able to protect the conditioned resolution of his or her registered name. The discussions earlier about exactly what do we know about who is the registrant, Elliot's comments, I think, are -- should be well taken, because the scenarios for how things get registered and who appears to be the registrant actually vary quite a bit. And I think there probably needs to be boundary conditions that we agree to, we, the community, agree to beyond which we don't make guarantees. So I realize I'm going on and on, so I'll stop and just try to summarize that I think we have a question about the information, the minimum information that has to be available to a replacement registrar or to a replacement registry to function, and we have to have -- if we don't have them, we have to have standard interfaces that convey that information back and forth in a way that can be used to recover. I don't think this is a simple task, but I think it's a vital one. And it's one that I'm glad to see there's so much interest in trying to move forward on. >>SUSAN CRAWFORD: Thank you so much, Vint. Appreciate that. This last part of our program is actually in the form of an update. Contractual compliance is obviously key. I have asked Stacy Burnette of the ICANN staff to tell us about a recent and planned audit, including some results of the audits recently concluded. So this is more in the nature of a report, but I thought you would all be interested in this. Thank you. >>STACY BURNETTE: Thank you, Susan. Good afternoon, everyone. I welcome this opportunity to share information about ICANN's contractual compliance program progress. And while the program is new, we have made significant progress. But because the program is new, there is room for continual improvement. And I'm looking to you to provide comments and suggestions as to how we can continue to improve this program. I wanted to briefly go over what I plan to say. I'm going to give you the purpose of the contractual compliance program, a summary of the audits we've completed to date, and the audits we plan to complete before the end of the year, and then a brief conclusion. The purpose of the program is to ensure compliance by ICANN and its contracted parties with the terms of their agreements. And I'm saying specifically the registrar and registry agreements. I realize there are other agreements that ICANN has with other entities. But I'm charged with making sure there is compliance with the registrar and registry agreements. And complete info -- information regarding the contractual compliance program can be found on our Web site. I'm charged, and the staff that I work with, we're charged with monitoring contractual compliance by engaging in regular registrar and registry audits, by investigating and pursuing noncompliant parties, by developing and implementing consistent procedures for handling compliance matters, by attempting to resolve disputes between ICANN and contracted parties before pursuing litigation, and also, we're responsible for providing useful information to registrants via our Web site concerning common problems and how they can resolve those problems and get resources to assist them in resolving those problems. If you go to our home page today, there's a little icon on the right side of the page that says, "Have a registrar problem?" And then you click there and it gives you information. And one of the things we want to do going forward is to help registrants help themselves when they have a problem that does not really concern what's within our jurisdiction to address. And also, as part of the program, we will publish regular reports concerning our compliance activities. And I heard the gentleman say earlier, you know, "I understand you're involved in an audit. Why haven't you published what happened with the audit?" And we're going to publish twice a year. And the first publication will take place in July of 2007. And then another one at the end of the year. And that will give semiannual updates as to all of the audits we've conducted, the findings and recommendations to the community. So I wanted to share some of the preliminary findings concerning some of the audits we've conducted thus far. And the first audit that we decided to conduct concerned updating primary contact information. Because it became abundantly clear when we've decided to conduct audits that our audit efforts would be thwarted if we don't have contact information so that we can send notices to the registrars. And so we engaged in a primary contact update audit and we sent notices to all of the 860 registrars at that time. And that was in February. There are more since then. And we received information from 57 registrars updating their primary contact information. Another audit that we engaged in concerned a Web site audit. And that took place in March of 2007. And this audit assessed whether registrars who were currently managing active registered names had working Web sites and whether they had WHOIS service available for public use. And of the 881 registrars that were audited, 19 had nonworking Web sites;20 had no working WHOIS service available; 28 cured the cited violations that they were informed of; six are still working on violations; and five haven't responded. We're going through a process to try to get in touch with them. Because apparently we either don't have correct contact information for them or they're just not responding. So that's ongoing work. Another audit that was recently completed concerns registrar payment of invoices. This took place in April of 2007, and after reviewing our accounts receivable, we determined that there were 192 registrars with invoices that were 30 days or more overdue. And so we sent debt letters to all of the registrars who had these outstanding invoices. And after sending those debt letters -- and the debt letter simply said "pay your invoice within 30 days to avoid further compliance action." And if you, indeed, to make payment arrangements, please contact us. And 165 registrars made payments or either made payment arrangements with ICANN. And then after we didn't hear from certain registrars, we sent breach notices. And we sent breach notices to 27 registrars. After sending the breach notices, nine registrars either made payment or made payment arrangements with ICANN. And of those registrars who didn't make payment or payment arrangements after receiving a breach notice, we are considering termination for those registrars. And this audit resulted in an additional -- I won't say additional but $750,000 was collected in bad debt and $400,000 will be collected based on payment arrangement promises. Another -- We're calling it an audit but it's really a regular report that's done every year. It's called the WHOIS data problem report, and reporting system report. This report provides statistical and narrative information on community experiences with the WHOIS data problem report system. And we believe this system remains a useful tool for reporting inaccurate and incomplete WHOIS data. And this year, approximately 34,029 unique domain names were the subject of WHOIS data problem reports. And this full report can be found on our Web site. And I wanted to quickly share some of the audits that will be conducted before December of 2007. We are going to engage in a registry code of conduct audit, which is actually underway as we speak. And this audit ensures that registries are not engaging in conduct that would give the appearance of impropriety. An example of that might be in certain registry agreements, there is specific language that says that the registry cannot employ the same employees employed by a registrar. And so there are these specific things that registries have promised they wouldn't do in their contracts. And we have requested that an officer of the registry certify that they are not engaging in this conduct. And then notarize the certification and send it to us. We're also going to be engaging in a registry performance specification audit. And in all of the registry agreements, there are standards for availability, for outages, for processing times and updates, and we are going to look at the reports that are given to ICANN on a monthly basis regarding their performance and measure that against what they promised to do in their registry agreement. We'll also be engaging in a registry WHOIS accessibility audit. We're checking whether registries are providing appropriate access to WHOIS information. We will be engaging in a registrar data retention audit, which is actually underway as well, where we are assessing whether the registrars are complying with their data retention requirements as set forth in their agreements. We will be conducting a registrar insurance verification audit. All registrars are required to maintain -- I think it's $500,000 in general commercial liability insurance pursuant to their agreements. And we will request documentation to verify that they are maintaining that insurance. The inter-registrar transfer policy compliance audit, there are several consensus policies, and we will be conducting audits for different consensus policies at different times. And this year, we're going to address the inter-registrar transfer policy. And while this -- the specifics of this audit are still under development, we are going to aggressively pursue complaints concerning the inter-registrar transfer policy as part of that audit. We will be engaging in a WHOIS server accessibility audit and a WHOIS data accuracy audit, and both of the details concerning those audits are on our Web site. And it's part of the report concerning the WHOIS data problem report. And full information is on the Web site. And so in conclusion, I would like the contractual compliance program to serve as a resource for the Internet community to address noncompliant behavior. Not that we're the Internet police, but I think people need to have place to go when they are aware that there are actions going on that are outside of the requirements of the agreements. And so we want to serve as that resource. And we want to encourage compliance to enhance ICANN's ability to preserve and enhance the operational stability, reliability, security and global interoperability of the Internet. Thank you. >>SUSAN CRAWFORD: Thank you so much, Stacy. Do you have an e-mail address you commonly use? >>STACY BURNETTE: Yes, it's S-T-A-C-Y dot BurnettE B-U-R-N-E-T-T-E, @icann.org. >>SUSAN CRAWFORD: You receive complaints for the contractual compliance department. >>STACY BURNETTE: Yes, I do. >>SUSAN CRAWFORD: Any comments on Stacy's report? Reactions to it? Yes, coming in. >>ELLIOT NOSS: Thanks, Susan. This is an issue that is very important to me. I was heartened to hear your comments. There's one specific thing I would love to call out for that I think would help all of us in the community. There are -- you know, a lot of these policies, first of all, deal with some pretty arcane subject matter. Second of all, tend to be delivered in language that is sometimes open to interpretation. Certainly the transfer policy is one that has suffered from -- or has suffered from those characteristics. And I would really encourage you to, whenever there is ambiguity, to be the interpreter and to very clearly state your -- when I say "your," your organizational view of the policy to remove that ambiguity. I think that one of the things that has really constrained the compliance effort so far is, frankly, people engaging in what I would call cheap lawyering in an effort to cloud what should otherwise be some pretty clear stuff. And so I think -- I really, really strongly urge you to just -- much as happens all the time with regulations underneath statutes, to just clearly tell the community your position and how you are going to both interpret and enforce it. Thanks. >>SUSAN CRAWFORD: Okay. Elliot. Go ahead. Two more comments and then we will come to a close. >>BERTRAND DE LA CHAPELLE: My name is Bertrand De La Chapelle, I am the French GAC representative. And I would like, if you don't mind, to address the previous section on the continuity of registries, because we moved to the next subject. >>SUSAN CRAWFORD: Mm-hmm. >>BERTRAND DE LA CHAPELLE: I think it's a very important issue that I wanted to comment upon, because the question of failure of registries is of the highest importance for users. The failure of a registrar is already something that is very bad. The failure of a registry is of a higher importance. And I want to address a sort of underlying assumption here that is connected to the notion of failure in a market. There is some understanding, I sense, and correct me if I'm wrong, some understanding that is very linked to the economic theory that a market is not efficient if a minimal level of failure does not exist, because if a certain number of failures do not exist, then that means that you are not pushing the market to its most efficient functioning. This is very classic economic theory. The problem is this can apply to very competitive environments. But I would like to underline one very important thing, is any registry that will be created under the new gTLD framework might be in potential competition with others. But any gTLD creation is actually the creation of a new, de facto, monopoly. And as a de facto monopoly, on a common public resource, in the full spirit of the RFC 1591, there is a general function of public interest in the management of a TLD. And I would here like to make a clear distinction between the policy management of a TLD, the level of the policy management, and the operational level of the registry. I am absolutely convinced that as the number of gTLD grows, the whole industry of registry management services will emerge. And this is absolutely good. Because as the number of TLDs will grow, economies of scale will kick in and it will make absolute sense to have some large providers, completely commercial, that will be providing outsourcing services of registry operation that are already emerging to a lot of actors who will basically want to serve a certain community and will want to handle and devote all their time to the management of the interaction and the policy development to serve this community best and not to the day-to-day management of the registry itself. So I just want to call very, very strongly to your attention that the failure to -- the first element to prevent failure of registries is in designing a process for the introduction of new gTLDs that makes them as safe and as sustainable as possible. And we'll come back to this issue on another forum. >>SUSAN CRAWFORD: Yes, thanks so much. And last, Kieren if you have any comments from online. Then we'll wrap up. >>KIEREN McCARTHY: Yes, some comments from -- and I don't think I mentioned the addresses, San Juan 2007.icann.org. There's a couple of comments tying in with the previous discussions with Stacy's compliance aspects. One which I think is worth raising because it educates people, one TLD agent is asking why ICANN provides credit services. So I know some of the reasons why but I won't put words in your mouth so maybe that's useful to explain. Danny Younger makes an interesting point that was expanded on by other people about the role that registrars actually play in the sense that registrars aren't just registering domains for individuals. They are also registering domains for themselves. And he complains that ICANN adopted a consensus policy that said that when a domain expires it's supposed to be returned to the pool of names so anyone can re-register it. Many registrars have terms of service agreements that force you to transfer a domain upon expiry to them or their associates for auction purposes. And I don't think that's been raised. That's quite important. Another comment, at the end of the day, mention should be taken so registrants should not be penalized if the registrars have not been compliant. And I think we may lose track. That's actually the main point. And TLD agent complains that registrars have no interest in their registrants -- I don't think that's entirely true -- that their financial interest is more directly related to building portfolios of monetized domain names. This is a problem. >>SUSAN CRAWFORD: Thank you very much, Kieren. Well in a sense, there has been a little bit of a moderator failure here. We are 15 minutes over time, but I thought it was worth it to encourage as much comment as possible. The board is watching all four of these issues very, very carefully. And I hope that you will attend every meeting on these topics, if you are interested. We'll be looking for advances in escrow, changes to the registrar accreditation agreement, encouragement to the compliance office and encouragement to the registries as they develop failover plans. Thank you for attending and please continue to send in your comments to us. [ Applause ]