Board discussion over RegisterFly

The following is the discussion held over RegisterFly at the ICANN Board meeting on Friday 31 March 2007.

RegisterFly was also the topic of discussion for an hour at the end of the Public Forum on Monday 26 March 2007. The public forum's full transcript is available here.

Note: Although transcript output is largely accurate, in some cases it is incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.

NB: This is an edited excerpt of the full meeting transcript, broken down according to each Board member and produced in an effort to provide easy access to the substantive discussion. For the Board meeting's full transcript click here.

Broken down according to speaker:

>> VINT CERF: Many of you will know that we recently have been through a period of complex difficulty because a registrar, RegisterFly.com has, in fact, failed in many respects to fulfill its duties under the agreement with ICANN and has, in fact, been disaccredited. Paul, I would like to ask you to introduce this discussion.


>>PAUL TWOMEY: Thank you, Steve. Chairman, throughout the last -- well, months and weeks, the issue of performance and compliance by registrars and one registrar in particular with registrar accreditation agreement and the appropriate protection of registrants has been a major item both of work and of comment.

Related to that is the -- two issues, I think. One has been raised which is issues around ICANN's compliance program and also the actual specifics of this agreement of this particular registrar.

And I'm going to ask Kurt Pritz to take us through a presentation briefly on that particular set.

Chairman, there is a process going forward of that discussion and consensus building amongst the community about what are the new -- what are the new things that should be done in response, not just in the case of RegisterFly but more broadly about both the registrar accreditation agreement, other actions outside that agreement which could also improve performance of the protection of registrants and related to that a clear -- as Steve Crocker himself has made the case several times this week, a clear understanding of what is the parameters of which we are trying to solve and what is the appropriate model that we need to have and what is the appropriate boundaries or actions that should take place to support registrants and clearly understand which parts may not be within ICANN's scope or even the registrar's scope.

So I will ask -- if you would like a second discussion that's already started this week in the workshop, the board may have views about what they would like to see out of that discussion going forward.

But before we hear those, I would ask Kurt to just take us through where we are on compliance on the registrar accreditation agreement, both in a historical sense but also where are we in the case of the registry RegisterFly.


>>KURT PRITZ: I think a discussion of this sort starts with ICANN's existing compliance program and the existing registrar accreditation agreement, registry agreements and other agreements with which -- for which ICANN has compliance responsibility. There is significant action and work that can be taken in the current environment while we seek to improve the tools we have and improve the contractual conditions that will further protect registrants.


Compliance

Very briefly the existing compliance program, you can see it at icann.org/compliance, includes basically handling consumer complaints and then having procedures in place for escalating those complaints when they become serious, numerous or potential breaches of the registrar accreditation agreement, registry agreement or other agreement.

And then a sense or practice of perseverance on these issues to see them through to completion, that's where the registrant will -- will see relief or be protected. And then there is a proactive part to the compliance program, too, rather than receiving complaints and reacting to them. And that is a proactive audit schedule and that schedule is also published, so the activity would be the execution of that.

So the first -- the first part of that is responding to consumer complaints, and this is not necessarily always within ICANN's mission and the customer service levels provided by registrars.

We receive complaints through several ICANN mailboxes and a lot of phone calls, the primary source of these inquiries is the registrar info mailbox where we receive with about 650 or 700 complaints a month. Each complaint is sorted and then sent to the responsible registrar or registry as indicated in the mailbox in the case of -- sorry about that -- in the case of the registrar mailbox, it is the registrar.

Statistics described in the complaints are on the Web site. This is kind of an eye chart. I apologize for that in advance, but you can see that there's several, several issues that are the subject of these complaints. The biggest by far has to do with transfers and then the next has to do with WHOIS-type complaints, whether WHOIS data has been changed or is inaccurate and cannot be changed. That's a sort on the complaints in the year 2006 that ICANN received. Like I said, it's posted.

The other activities are more pointed to ICANN's mission and that is to follow up on compliance concerns and issues. Obviously we have an internal escalation process so that we can determine those issues that should be prosecuted, particularly by the ICANN staff. Maybe when there's a number -- complaints are numerous or they're serious.

So for an example in the last 20 working days, ICANN has followed up on 40 cases that have been escalated personally with registrars and interceded on registrants behalf to some sort of resolution. So that 90 active compliance actions in one month of working days is fairly typical. It has been fairly constant. I think last month it was higher than that.

The 90 complaints just for information were about 42 different registrars and there were four significant reasons for complaints that could be RAA related. One is failure to transfer according to the transfer process. That's the largest. The others are problems with WHOIS information, customer service and particularly problems with a reseller of an ICANN accredited registrar.

The last part of the compliance program is the audit process. There is audit schedules posted for both registries and registrars. Recently, we completed a registry WHOIS audit within the past fiscal year. Also, there is audits of registrars as they go through the RAA renewal process to bring them into compliance, and presently there is a registrar WHOIS Web site program going on.

So with a backdrop of that existing compliance program, here came RegisterFly and its behavior.


RegisterFly background

RegisterFly, this is just some background. It has always been a reseller, and then having not gained an accreditation through the ICANN process obtained one through purchase. There were continued complaints about RegisterFly, mostly about customer service levels. A lot of complaints, questionable whether they were violations of the agreement.

Nonetheless, ICANN undertook an audit and requested a lot of information and got involved with RegisterFly in mid 2006 and the number of complaints dropped. But then they rose again and included chargebacks that occur when customers don't get what they pay for, unauthorized WHOIS changes, underfunded registry accounts and transfer policy violations.

Now we're going through -- as everyone knows, a deaccreditation process that's clearly defined in the RAA. Through the process, we have been doing a few things with the big ICANN community, registrars, registries are facilitating transfers. There is a lot of ICANN involvement on a personal basis on hundreds and hundreds -- to facilitate hundreds and hundreds of transfers. And registrars are providing advice and technical support to RegisterFly to help them make transfers and help registrants.

There has also been a coordinated effort among registries to prevent deletions of names during this time so that the rights of registrants can be preserved until the situation sorts itself out, and we're also working to escrow timely data, including proxy data, that data that underlies the privacy registrations.

And finally, we are working with registrars and registries to develop a coherent predictable method so that registrants can transfer their name away from RegisterFly in the event of termination.


Data escrow

So one of these issues was escrow of data. A case study always teaches you more and this is a very fact-specific situation, but I think every registrar and potential registrar failure will be a very fact-specific situation.

We've learned that escrow data is very important, and we have a program in place to complete that program and implement it, but there's other issues that are very important, too. And, that is, the whole issue of proxy data. So if we have escrow data, the people who have registered privacy registrations really don't have their data escrowed anywhere and they are not protected in the event of failure. Should proxy data be escrowed or should registrants be using a proxy service to take on a higher level of risk?

And then there is -- once you have the data, what do you do with it? And how can you use it? At one point in a termination process or a breach process can ICANN use the data and act in a way to protect registrants? All the parties have rights. The registrants, the registrars and so under what circumstances can the data be used or transferred?

I just want to talk a bit about the data escrow program. This is a program to implement data escrow pursuant to the ICANN registrar accreditation agreement. So there's -- the implementation plan really has five steps and that is to write a technical specification and a draft of that is done. It is going to be submitted to registrars and others in the community for technical review. And then to secure the surfaces of a he is -- services of an escrow provider. Or in the case of registrars that want to secure their own data escrow, a process for approving third-party providers. And then the last two parts of the implementation will be a development of the audit procedures and a test. So those are pretty straightforward. That program plan is going to be prosecuted within with the community.

At this meeting, in a meeting with registrars, the registrars -- the gTLD registrars appointed a team or task force -- I don't know what you call it, but a bunch of good people to work with ICANN to accelerate the implementation of a data escrow program. We're also redefining the project to include these issues that have been raised -- that have been raised due to this set of circumstances. And we've also agreed to accelerate the plan significantly, and we're going to publish the final schedule next month.

So Mr. Chairman, I'm just going to take a couple more minutes, if it's permissible, to review the discussion we've had with registrars here at this meeting and show progress and then I'll be done. But these are the issues that Paul Twomey raised in his posting to the community regarding improvements that can be made in the relationship between registrars and their -- and the community, their registrants, and potential changes for the RAA.


Registrar discussion

The discussion with registrars first went to, you know, some of these things can be done right away and we can discuss them right away, and some of them require a change to the agreement. So I've italicized the items here that require some change to the RAA, and so that change would be on the critical path to actually getting some of this stuff done.

I've also -- I've already talked about data escrow and I think there's a -- there's a clear plan and I'm going to refer to my notes here, to make sure I've captured the gist of what was said in the meeting, but I think I've clearly stated what we're -- the path forward on data escrow.

The problems associated with proxy registrations were discussed again, and, you know, we discussed a proxy registering service that can be certified. One that could take the privacy data and actually store it at a third party and release it, then, under certain circumstances. So that idea is being pursued.

There's extensive discussion about the rating of registrars. It's something that can be done, but something that's done that's accurate, meaningful, and available to registrants might be problematic. It's an area where resources could be expended without real benefit, so there's enthusiasm for discussion of it, and moving forward with it in a way that would be beneficial.

ICANN's looking at the system of affiliated registrars and group ownerships. Affiliated registrars have common ownership or control over -- you know, among many registrars, and currently ICANN requires a separation of affiliated registrars when they apply for accreditation in a way that might inhibit this. So ICANN has an action to take up with its general counsel's office to determine how this can be best pursued.

Stronger or additional compliance enforcement tools were discussed in detail. There are some that could be invoked or implemented without a change to the RAA, such as publication of breaches or publications of bad behavior. Others, such as escalated sanctions, one might be suspension of ability to register names for a period of time would require a change to the agreement. There are brief discussions -- and I'll tell you why -- about changes to the transfer policy, and that is that that effort's already ongoing. ICANN staff had furnished a report to the GNSO Council on experiences with the --

>>VINT CERF: Kurt, I'm sorry. Can you slow down a little bit, please?

>>KURT PRITZ: I'm going to try. So -- it's not my nature. I'm sorry.
[Laughter]

>>KURT PRITZ: So ICANN has turned a report to the GNSO Council suggesting reporting experiences and suggesting changes to the transfer policy, and as -- since that report, furnished clarifications and a list of policy issues. That's a draft document, and so we want to energize those discussions and when I say "energize," I mean provide staff support for those discussions to continue on discussion about the transfer policy.

We discussed the idea of registrar certification of staff. This seems to be a straightforward thing to do but again, to do it in a meaningful way that's just not an administrative burden to registrars is important, so that discussion will continue.

There is an opinion that accreditation by purchase is difficult to prevent at first examination, given the M&A process and the M&A environment, and -- but we did discuss several measures to prevent problems due to transfer of ownership. Such as higher levels of scrutiny by ICANN in the case of a change in contact information or a change in entity. So that -- that part of the discussion is ongoing, and then how the accreditation by purchase might be prevented is a deeper legal discussion.


Registrar Accreditation Agreement

And then we discussed reseller liability under the RAA, and each registrar went around the table and took complete ownership of the behavior of resellers, and so that was -- that was -- that was essentially the extent of that discussion. Registrars committed that issues regarding resellers and reseller compliance would receive sufficient resources and attention to assure better accountability by resellers to registrars. To registrants, rather.

And then there was quite a bit of discussion about the process for amending the RAA and we'll have to -- there's more of an investigation that has to occur there. It has to be according to the agreement in some consensus based process, so I think that provides quite a bit of opportunity for moving forward on a rapid basis.

So Mr. Chairman, that was quite a bit of material, and I'm sorry for taking up so much time and talking fast but I wanted to provide some background for the discussion here and then after we leave here, too.

>>VINT CERF: Thank you very much, Kurt. I would suggest when you have a lot of material, that it should not cause you to speak at 900 words per minute. In deference to the hard work of our scribes.

I'd like to make an observation about what Kurt has just reported. The first one is that the ICANN staff have actually been very much involved in compliance in various ways over the course of some years, so the RegisterFly matter, although it is by far one of the most visible of the problems arising is not, by any means, the only one. And for many people who might not have known, staff has been actually quite engaged in dealing with problems of this sort, trying to respond to registrant protection through the compliance mechanisms. I'd like to suggest to you, though, that the board has an obligation to discuss -- if not here, then at another time -- the extent of the obligations that we have to registrants. I mean, my belief is that in general, our whole role is to assure that the registrants are able to register in their chosen domain names and that the system will continue to serve them. To the extent that we can assure that through contractual means, through compliance and the like, I think that's very important, but we should have a fundamental discussion about how far we can go.

For example, if a registry fails, are we responsible for turning into receivers to operate it? If a registrar fails, how far do we go to reconstitute the operation?

The data that is needed may not be sufficient to reconstitute operation precisely in the same way that a particular registrar has been functioning. I'm thinking that the -- the databases and the user interfaces and the like for each registrar may be quite different.

So we need to find some guidelines for the degree to which we are able to offer various protections for -- for registrants.

So I think we should have that fundamental discussion. I don't know how to make the metric, but clearly it has to be feasible, it has to be affordable, it has to be scalable, as more and more registrars and more registries are created.

So I put that on the table as a potential discussion, if not now, then later during the course of 2007, as we try to lay out what our responsibilities are.

I would suggest that we will have similar kinds of discussions with regard to new TLDs, again, trying to identify the limits of our responsibilities in order to permit additional TLDs to be created.

Are there any questions and comments? Peter?

>>PETER DENGATE THRUSH: Thank you, Vint. First of all, I'd just like to thank Kurt for the presentation, and I and I think other members of the board are probably very grateful to know that that work is going on in compliance. Mostly invisible to me, I'm sure to many other members of the community. So thank you for exposing all of that good work that's going on. Secondly, I'd like to support Vint's call that we do need to have a fundamental policy discussion about the extent of all of those issues.
We're talking about a delicate balancing in a fairly contested commercial climate of the rights of registries with registrars and registrants, and that is something that we may find from time to time that we change the balance as conditions move. So we need to keep up with that.

The other thing that we do need to do is complete the obligations in the contracts for preparing an escrow compliance -- an escrow program, but at the same time we recognize the message that came to us from the registrar community that even full escrow would not necessarily solve the RegisterFly situation. Obviously, it's an important step to have in our compliance and backup program.

So I think really Kurt and Paul, it's a call for an appropriate timetable for completing that escrow obligation in the contracts and get that done in a timely but complete sort of way.

And then run, Vint, your requirement for a full policy discussion about all the other things that we need to have to complete that picture.
So I don't know how we -- those seem to be the two things that we need to set up. One is reasonably rapid to be honest with you effective completion of the escrow issue and a full policy debate on all the other issues that are required.

>>VINT CERF: Any other comments? Yes, Vittorio.

>>VITTORIO BERTOLA: Yes. Well, the first thing that I want to say is that this is a really important matter for the at-large and for registrants in general. I think much more important than dot xxx or any other issues that -- on which we have been spending a lot of time. The At-Large Advisory Committee has released a statement. It was presented briefly yesterday at the public forum. But basically, we agreed that it is important to enforce the current contracts, and escrow specifically, but I think that -- I mean, I agree with you that we need a discussion on where ICANN needs to stay into this environment, and especially what kind of provisions it has to add to the contracts to protect the registrants. And there's a number of situations where this is actually necessary. Maybe not many of them, so I'm not thinking that this should become a heavily regulated market, but for the market to be a market, there needs to be a basic level of competition. And so as a minimum, registrants must be actually free to move from one registrar to the other.

So, for example, we have suggested that there are some provisions in the contracts that require registrars to supply an easy way for transferring domains away. Compatibly with security, of course.

So in general, I think we need to have that discussion. Maybe other things could be obtained by nonbinding measures, so I think -- I really think that most of it could be a discussion between the registrars and the registrants, the at-large, and anyone else about practices. Perhaps there's the need to write down some things. I mean, one of the most usual complaints I see is people registering a domain name and then discovering that it's -- I mean, in the WHOIS system, the registrant is actually the reseller, not them, so they cannot get back their domain if they want to change their Web hosting company, for example. And this is clearly outside of the purview of ICANN directly, but at the same time, I don't think that there's any documents stating anywhere that in the DNS it should be you that gets the ownership of the domain and not the reseller. So maybe just by agreeing on some best practices like this, we can provide some registrants a way to show that they have a right when they have to discuss with their suppliers. So I basically look forward to this discussion. I don't know how to do it. Maybe it's just as in -- the registrants just have to arrange it separately, but I think it's something that we really need to have.

>>VINT CERF: Just a reminder, Vittorio, that was very rapid-fire delivery. A reminder to board members, please slow down. Steve Crocker.

>>STEVE CROCKER: Thank you, Vint. I just want to add from the perspective of the Security and Stability Advisory Committee, equal emphasis and shared purpose in exactly the focus of protecting registrants. This is a general topic that we have spent time on before. I think we have shared purpose across different segments of the community here. We stand ready to work cooperatively with at-large or with any other portion of the community, and in particular, our view of security and stability necessarily includes the entire system that is involved, not just narrow operating components of a particular service, for example.

So I would like very much to see and applaud the efforts that Kurt has described and the staff's attention to using the mechanisms that exist and exercising them to full measure. And at the same time, a broader discussion about what our objectives are, what our values are in this area at the board level, and at the community level, and then eventually translating those thoughts and decisions into perhaps new mechanisms or additional mechanisms that make the whole system work quite effectively. I think we all subscribe to the general notion of a free and open market. That is a nice embracing concept. There is no market that operates completely unfettered by some sort of constraints. Those that do rapidly -- often, anyway, rapidly run into -- off the deep end somewhere where they're totally captured or they have some other flaw in them. So I don't see it inconsistent with our general mandate to have a vibrant, free, open marketplace with equally a set of carefully selected and well-crafted protections built into the marketplace in order to make that marketplace continue to function vibrantly. Thank you.


>>VINT CERF: Thank you, Steve. I'd just like to make one other observation about all of this.

We have perhaps -- or could have an overly simple model of this market. The connection between a registrant and these things we call registrars and registries can sometimes be quite distant. If you wanted to get a Web site, you might go to a hosting company which will undertake to register a domain name for you, to provide you with host services and so on. That party might go to a reseller in order to perform the registration. There are a variety of linkages that connect or potentially connect a registrant to the system with which we actually have contracts.

The result is that trying to protect a registrant is going to be, if not a distant goal, at least a complex one, and I think under all circumstances, we will be unable to provide the protections that Vittorio, the at-large community, might expect simply because of the variety of ways in which registration can occur.

I don't say this as a way of trying to inhibit ICANN from trying to do the right thing, but I would say we should be conscious of the fact that our only tool for compliance today is contract, and that we don't actually have contracts with every component of this complex marketplace. So we should not be surprised if there are some cases that don't work. The comment that in the case of RegisterFly, perfect data might still not have solved the problem, because we couldn't get our hands on it or the party wasn't cooperative or there was a dispute within the company as to who was in charge of it and who could make agreements, those are all the kinds of real-world physics that get in the way of the virtual models that I wish that we could actually work with.

As a mathematician and a computer scientist, "virtual" is very cool, but as a pragmatist, I understand that sometimes it doesn't apply.

Are there other comments on this particular topic? I got one from Janis. I'm sorry. Did I see Susan? No. Janis, and anyone else? No. Janis?

>>JANIS KARKLINS: Thank you. And I think the issue you raised concerning consumer protection or registrant protection from Government Advisory Committee perspective is a very valid one. That is a public policy concern, and I would like to agree that implementation of that principle may be difficult, but the absence of the provision in the contract which obliges registrars ensure that customers do not suffer as a result of some kind of collisions. That is not acceptable. The provisions should be there, and I think that this is the minimum ICANN can do in order to follow this the principle of consumer protection.

>>VINT CERF: So this term "customer" introduces a potential hazard here. Because the customer of a registrar might be a reseller. The customer of a registrar might be a hosting service. We would have to, in our further deliberations about where our responsibilities lie, we might, for example, have to insist that the ultimate registrant has to be exhibited in the data tables. I don't know what the ramifications of that are, and I don't suggest that we have the debate now, but I'm fond of observing that Einstein once said that "things should be as simple as possible but no simpler," and that is to say, let's be careful that we don't try to design and build a system of compliance around a model which is, in fact, inadequate to reflect the real world.

If there are no other -- there are two. One from Susan and then one from Peter.

>>PETER DENGATE THRUSH: Thank you but I've just been drafting an easy resolution, but if Susan has another comment, I can defer.

>>SUSAN CRAWFORD: Oh, just very briefly. We have a lot of soft power here that we can use, informational -- getting news out to registrants and other actors about what it means to register a domain name and what their rights and obligations and who to call. We can do a better job at that, I think. Also, I think it might be helpful to rapidly convene a group that amends this contract to include these lesser-included things that we need to protect registrants. You know, ultimately this is a matter of customer service, in a sense. Our service to the Internet community and the registrars' service to their registrants. And if we can help with building in escalation procedures short of de-accreditation, I think we have an opportunity now to seize this moment and amend the contract and get registrars working together with all of us to make this a better situation for registrants. But I wouldn't discount the communication/education function that ICANN can serve in this regard.

>>VINT CERF: Thank you, Susan. I see Peter's hand and then Paul's. Peter, if you're about to introduce a resolution, normally my practice is not to do resolutions on the fly, but I think we should hear what you have in mind to do, so please go ahead.

>>PETER DENGATE THRUSH: Thanks, Vint. I'm just trying to be helpful, going forward. I suggest that we direct the president to report to the board in San Juan on progress with developing a program for escrow as provided in the RAA, and on stimulating a policy debate to create policies for the appropriate protection of registries, registrars, and registrants. Reporting in San Juan on those two issues. One, escrow; and two, a policy debate. Which hopefully would lead to Susan's and JANIS' issue about amending the contracts.

>>VINT CERF: A procedural suggestion might be to record a sense of the board with these two things are designed, as opposed to a formal resolution. I'm not trying to rule out that at all. I would like to get some comment from Paul on this, since he had his hand up anyway, and Alex after that, and we'll come back, Peter, to the proposal.

>>PAUL TWOMEY: Yeah. Thank you, Vint. I'd like to support what Susan said a hundred percent. I think she's right on the money. And I think to come to what Peter suggested, I think there's -- there's potentially four options, four avenues we have here. One is, we should report back on the existing obligations on, for instance, the escrow policy. So that's the first item.

The second one is: There are -- I think Susan is absolutely right. There are a series of actions that we could encourage registrars to do and which ICANN itself could creatively do which do not require a change to the RAA and which could improve some of these -- some of these aspects. So I think we should report back on that.

Thirdly, on -- when it comes to the accreditation agreement itself, very importantly, the wording of the agreement for its amendment, it calls for consensus, not for consensus policy. And as we know, that issue is fairly significant, because we could well, for the speed of time, convene the sort of working groups, the cross-constituency working groups and feels if the board that is a consensus approach by Sao Paulo -- San Juan, should I say, for amendment to the contract. If there are specific things that then need or require consensus policy -- in other words, they have to go through a PDP through the GNSO -- then they could be identified as well. So it's not to exclude out things that would go through the -- the GNSO PDP, but it may not necessarily -- it may not be -- for the sort of amendments I'm hearing the registrars now just talking about, we may be able to implement those amendments without necessarily having to have the PDP.

>>VINT CERF: I was signaling you to slow down, Paul. Did you -- have you finished?

>>PAUL TWOMEY: That's it.

>>VINT CERF: All right. Let me get Alex and then we'll come back to Peter's proposal.

>>ALEJANDRO PISANTY: Vint, I share with many the concern that registrants, individual small business owners or nonprofit organizations are left hanging by things like the RegisterFly and many other potentially occurring failures now or in the future. I would urge this board and the community not to get carried away before studying also what the consumer protection role is.

Consumer protection is something that varies widely among countries. There are countries which have very strong organizations which are mostly grass-roots citizens organizations which have been well-organized and funded and can put up a lot of pressure on providers who fail consumers. There are countries where this is a government function. There are countries where this is basically a wild west or a jungle. And one could try to -- one should be very careful and get information and advice from the GAC as to how to better implement a consumer protection function that scales globally, that scales cross -- across jurisdictions, judiciary traditions and so forth, and that doesn't put ICANN again in a nontechnical coordination role.
I am baffled and surprised and I would like to look in more detail to make sure it's not exactly the same people who make claims against ICANN overstepping its technical coordination role, that as soon as they see a flap occurring in the market,some outreach -- some outrage, sorry, to make my pronunciation specific for the scribes -- that immediately are turning ICANN into something that also exceeds the technical coordination mandate which would be sort of the consumer protection agency of cyberspace.

This is a dangerous path, and I would insist in first studying the implications. I think that the call by JANIS and several other of the people present here, board members and liaisons, are valuable. Careful study is required. And I insist we should not get carried away and suddenly saddle ICANN with an unmeetable function.

>>VINT CERF: Okay. Thank you, Alex. Let me suggest, Kurt, that it's okay for you to stand down now. I'm sorry that I left you standing up there. And thank you, again, for that report.

There are several people who have asked to speak. Rita had her hand up. Let me ask you, Rita: Do you want to speak to something which would have an influence on Peter's proposal or can I proceed with that first? What's your -- what is the topic that you'd like to cover.

>>RITA RODIN: Vint, I'm sorry, I don't remember Peter's proposal. It's just a quick comment on something that Alex said.
[Laughter]

>>VINT CERF: Go ahead.

>>RITA RODIN: All right. I just wanted to echo something that Alex said. I think it is important, as everyone has discussed, to deal with the protection of registrants in a situation of registrar failure, because it is important to keep the Web running. But I do want to echo what Alex said, that there shouldn't be this notion that anyone -- you know, as a U.S. lawyer, I know that it's impossible to draft a perfect contract to protect someone, and I do want us to just be temperate in terms of looking at contracts and dealing with too many burdens on registrars and trying to think that there will never be any issues that will come up in the space.

>>VINT CERF: Peter is trying very hard to get something done. Alex, I hope a brief comment?

>>ALEJANDRO PISANTY: It will be a footnote to Rita's comment saying it's not only the Web. There's 65 535 ports out there. Not just port 80. This is the Internet, not the Web, the Corporation for Assigned Names and Numbers.

>>VINT CERF: Thank you, Alex. Peter, let's come back -- Rita, the proposal that Peter made was to ask the board -- I'm sorry, ask the staff for a report on where we stand with regard to compliance and to engage in substantive discussions about the compliance questions and our role in it. Peter, would you like to repeat the proposal?

>>PETER DENGATE THRUSH: Thank you, Vint.

Directing the president to report to the board in San Juan on progress with developing a program for escrow, as provided in the RAA, and on stimulating a policy debate on policies for appropriate protection for registries, registrars, and registrants. If I can just speak to that, I put that on a slightly wider context at the end than simply registrants' rights in the case of registrar failure, which is the particular event which has stimulated this. It seems to me that we are at a nexus, and we can't tweak -- we can't pull one part of this without having regard to what that does to the rest of the balance, and that the debate really needs to take that all into account. The trouble with that, I recognize, is that it opens it up to a much wider scope, so depending on the urgency, we may -- we may choose to limit it, and deal with it in chunks.

>>VINT CERF: I think those issues, though, don't necessarily influence the basic request that you're making. Paul?

>>PAUL TWOMEY: Thank you, chairman. I think this is a good thrust. May I suggest, just for good housekeeping, that we just take the wording on notice and perhaps we could move to the next item and come back to the wording, just to allow Peter to consult with the normal people we do consult in resolutions, the general counsel and others, just to make certain the wording is fine. It might just be an opportune thing to do.

>>VINT CERF: Peter, is that an acceptable path?

>>PETER DENGATE THRUSH: Yes.

>>VINT CERF: All right. So we will ask counsel to work on the actual wording of this proposal and move on to the next topic, as Paul suggests.