Public forum discussion over RegisterFly

The following is the discussion held over RegisterFly at the ICANN public forum on Monday 26 March 2007. The transcript for the entire public forum can be found here.

RegisterFly was also the topic of discussion at a Board meeting on Friday 31 March. A hyperlinked version of that discussion 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.

Broken down according to speaker:

Questions from the floor

>>VINT CERF: We now move to the discussion about RegisterFly and all the implications that that swaying holds for us, to say nothing of the work ahead to try to improve our posture with regard to preventing damage associated with registrar failure in the future.

So Kurt, I see you moving up to the lectern, so I take it you are going to walk us through this discussion as well. Is that right?

>>KURT PRITZ: That's right, but I'm going to ask for some help. So with your approval, there are some people here that are going to participate in this discussion.

[Panellists introduced]

>>KURT PRITZ: This is somewhat of a hastily convened group, and now that I look at it, it's quite an august group, so thank you very much for agreeing to participate on short notice.

Again, this is a two-part presentation.

I am going to briefly describe recent events having to do with the gTLD registrar name RegisterFly. And some of the facts surrounding that. But then what's coming out of that more importantly are a set of more general issues regarding ICANN -- regarding ICANN and the gTLD community.

And these people have agreed to comment on some of the initiatives we might undertake to chase down some of the larger issues that have developed coming out of this -- or have come clear coming out of this.

So very briefly, this is one slide describing a situation with RegisterFly.

It's a compilation of a ten-page, single-spaced report describing ICANN interactions with RegisterFly over the past couple years, and the questions raised, questions answered, actions taken, audits undertaken, and responses.

So very, very briefly, and I'm happy to answer questions about this later, RegisterFly is an organization that's been an ICANN reseller for some time. There's always been a history of relatively high complaints.

They didn't receive an accreditation through the ICANN accredited process. In fact, there is an application for accreditation that was never granted. But in fact, obtained an accreditation by acquiring another entity.

There continue to be complaints and then ICANN undertook -- there is a lot of interaction between ICANN and RegisterFly, almost on a weekly basis. So this isn't meant to be a one-time -- ICANN interacted with RegisterFly one time, but ICANN undertook an audit of RegisterFly due to the level of complaints.

As a result of that, complaints dropped in the middle of last year, but then late last year, complaints about RegisterFly increased again.

Complaints

Those complaints include charge-backs. Charge-backs are when somebody asked their credit card to refund their money because they paid for a service but didn't get it. So a very high number of charge-backs indicates that people were paying for services they didn't receive.

Unauthorized WHOIS changes. Underfunded registry accounts. So registrars have accounts at each registry so they can register names there. If that account goes negative, obviously they can't do the job that is required of them under the agreement.

And then transfer policy violation. So these complaints were escalated to RegisterFly and others in the community.

Finally, there's a very well-defined process in the RAA, the registrar accreditation agreement, that exists between ICANN and gTLD registrars. In accordance with that procedure, ICANN provided a notice of breach to RegisterFly. On February 21st. And that has a 15 business day right to cure. And at the close of that cure period, ICANN issued a notice of termination.

Then there is a process that goes on from that. But there's a 15 calendar day period after the notice of termination is issued, after which ICANN can terminate the accreditation.

There's some protections built into that process, though. So RegisterFly has a right to arbitrate that termination.

So that process could extend out. And ICANN's following the process as it's defined in the RAA.

So given that background, ICANN and many others at this table and many others in the community have worked hard to protect registrants during this.

So RegisterFly has 850,000 registrations, approximately, and the primary focus, of course, in all this work is to protect registrants and their registrations or Web sites.

ICANN response

ICANN staff -- Several ICANN staff work full-time on this, and we don't have customer service departments like registrars have, and so aren't as equipped to do this, but have intervened on hundreds of registrant requests to transfer their name away from RegisterFly and have had some success in personal intervention.

So that numbered in the hundreds.

Registrars are also working with RegisterFly to make sure they provide advice, make sure their systems are working, and facilitate changes that facilitate the issuance of authorization codes that will result in transfers.

We, ICANN, has also coordinated registry efforts in this regard, so that if you can picture a registrar not functioning well anymore and not being able to renew names, then when names expire, there's a risk of them being deleted, and registrants losing their name.

So ICANN registries and ICANN accredited registrars and the gTLD registries and ICANN worked together to put in a temporary plan to not delete any RegisterFly registered names for a period of time in order to protect their rights until this situation is resolved.

We have received from RegisterFly, they have escrowed with us a set of data that lists all the registrants. So that will enable ICANN to -- in the event that operations are terminated, transfer -- bulk transfer the information to another registrar.

A very important part of this is proxy registration.

So many registrants use a privacy sort of service to register their names. That sort of information is not usually in data that's escrowed with an outside agency.

RegisterFly has attempted to provide us with the privacy data, too, so that when the names are transferred, it will not only protect those registrants who have registered data and put their WHOIS information in in accordance with regular transfer techniques, but also those registrants that have registered privacy registrations.

It's not to say that we are sure that the data we have is accurate. The data we have received from RegisterFly is somewhat aged, and we continue to prosecute the receipt of accurate data so that in the event that the data is bulk transferred to another registrar, it will be done with all registrants and not just most registrants being protected.

And then finally, we need to promote an understanding of ICANN's mission. ICANN has a narrow security and stability mission and a promotion of competition and choice.

So there's an understanding that not all consumer complaints are for ICANN.

So there are some big issues that have come out of this.

Data escrow

One is that there's a data escrow program that's currently being executed that needs to be accelerated. Complete escrow of data is one protection for registrants in the event a registrar ceases operations.

Another question that's arisen, though, is escrow of data doesn't completely protect registrants on a couple points. One is there are privacy or proxy registrations, and what is the role for ICANN and what is the role for the data escrow program there.

Should privacy data be escrowed or be escrowed in a way that it can be recovered in the event of registrar failure? Or should -- or registrants that register through a proxy service understand that in the event of a registrar failure, there's a risk that their registration might be lost.

So that's a balancing for, I think, all of us here to do in deciding the completion -- how the escrow data program should be completed.

And then another thing we have learned from this is having escrowed data doesn't mean we're done.

So in this case, say we pretty much have the data. What do away do with it now? At what stage can ICANN or another entity make use of escrowed data?

A process needs to be put in place for the coherent bulk transfer of that data to another entity, and for determining at what stage in the process that should be done.

Tot today, RegisterFly is still an ICANN accredited registrar.

Under what mechanisms or under what set of circumstances, under what set of approvals can ICANN take that data and provide it to somebody else in order to protect the interests of registrants?

This might be termed by many, including me, as a fairly black-and-white case where the behavior of this registrar is bad.

There may be, in the future, gray areas, and that's why this mechanism and process needs to be developed on a communitywide basis, I think, or at least in a consensus sort of way.

And then finally, given ICANN's mission, what is ICANN's role in the face of poor customer service?

In facilitating the development of a market, there are certainly -- in a market there's a place for, say, a high cost -- whoops, sorry about that.

High cost, high service providers and low-cost, low service providers, and each provides some sort of benefit to the marketplace. And ICANN's role is certainly to facilitate the market. And at what point it gets involved in customer service might be problematic.

Possible RAA changes

So recently, Paul has -- Paul Twomey has posted an opinion about this that highlights the importance of this issue to the community. And in that, he suggested a number of issues for consideration by the community in improving registration processes, and the registrar accreditation process.

And so finally, I'm talking way too much, but I've asked this group of people to join us to consider these issues that are posted, and next steps we should take in order to act in a way that continues to protect registrants and improve protection of registrants in the face of a market that continues to develop and will continue to create new businesses and choices for consumers, but will also naturally see the failures of some businesses.

So I've -- in three slides here, I've listed the proposal set out by ICANN for community discussion.

The first is the purpose of the registrar accreditation policy and agreement. Is it a compliance tool? How can it be strengthened to protect registrants.
Secondly, should there be an independent rating of registrars. This wouldn't be an ICANN rating. This would be some outside function either to rank order or provide a set of approvals for registrar operation.
A third topic for consideration is affiliated registrars, those who are familiar with this marketplace know that individual -- I don't know why it keeps doing that -- individual entities sometimes own several registrars. So should the performance of one of those affiliated registrars, should that entire entity be held responsible for that.
How can we augment the RAA to include additional compliance tools? Is there a graduated form of sanctions or something like that? What mechanisms can we put in place to ensure timely action so that registrants can be protected, that the bulk transfer of names can be accomplished in a timely manner but not too soon.
Are any elements of the transfer policy need to be reformed? How can ICANN or the rest of the community facilitate transfers in the face of a noncompliant registrar.
Registrar skill testing is about -- operator skill testing is about not having a certification or accreditation just with an entity or a business entity but also with individuals. So should each registrar have certified individuals working for it that demonstrates skill in technical aspects of this market area in and if that accreditation is transferred, then that new entity would have to have personnel with those same skills, or the same certifications.
And something that's happened in this case is that RegisterFly got essentially accredited by purchase. And what can be done in the accreditation procedure to avoid that?
Proxy registrations is something I've talked about already. Many ICANN accredited registrars operate through a network of resellers. It allows them to multiply marketing efforts throughout the community and more globally. To what extent should resellers be held liable to the RAA? Are they beholden just to the registrar and then the registrar is responsible to ICANN, or should that sort of food chain be changed?
And then finally, the last two have to do with registrar data escrow, and how can we accelerate that program and complete it. And then finally, a clarification of ICANN's responsibilities to registrants, and how can we facilitate that.

So the next slide that I put up, if you can see it, is just sort of a bullet summary of the issues so everybody can kind of stare at them. But what I'd like you guys to take on, if you could, probably starting with the representatives of ALAC, so you, Vittorio, if you don't mind, comment -- you can comment on anything, of course. But comment on the situation specifically, but, more importantly, what ICANN and everyone else should be doing in general to move forward in a way that's very constructive and can help registrants in the shortest period of time.

>>VITTORIO BERTOLA: Thank you. And while I'm known to have an opinion on everything, so -- but I will try to be as brief as possible.

As you know, the at large is the constituency that advocates the interests of the final user of the DNS and of the individual registrant, and, specifically, of those who do not make money from their domains, so cannot even afford not just to participate, but to send someone here.

And this is why for us this is possibly the most important topic in these ICANN meetings.

And I'm very happy that we are here to discuss it. I'm very happy that Paul had this public stance and raised the attention on this issue. I am also somewhat happy with a lot of work and stuff put in in the last month to deal with the situation. So when staff finally started to deal with this, it was, I think, very effective.

I'm less happy with the fact that ICANN has not traditionally been very attentive to these issues. So in a certain sense, we had to go -- undergo a difficult situation to realize that this is really an important part.

And I'm still aware of the fact that a part of the ICANN community still does not realize that this is a fundamental part of the mission of ICANN. So, of course, there are people who maybe are afraid of the idea of ICANN becoming too much involved in relationships between customers and registrars or domain name sellers, even. But at the same time, ICANN is the only entity that has contracts with these registrars and registries. So it is the only entity in the world that can do something to ensure that there is at least a minimum level of service in this market for registrants.

And so I think that ICANN cannot discharge itself on this responsibility. Actually, registrants pay 25 cents or even more in certain TLDs, per every domain name registration. So registrants actually pay money to ICANN to do this. And I guess they might accept to pay travel to these nice five-star hotels around the world, but only if that has the purpose to guarantee some minimum level of purpose. So that's the best point that we have to fulfill if we want to continue this mission.

So to come to the specific points, I think that it doesn't need to be a very prescriptive solution to the problem. I think that it's possibly a mix of instruments that we have to deploy.

There is a basic level of things that have to be inserted, I think, in contracts. And, for example, the data escrow is one of them. It has to work. Because ICANN has to provide insurance to all the registrants, at least in gTLDs, that they can be proven to be the registrant's (inaudible) domain name. So in case everything fails, at least the fact that they are the registrant is known and certified by a third party.

And the -- well, I take the issue about proxy services, but the problem with proxy services is that they are a bad answer to a true problem. So you will solve that by giving the possibility to have a good answer to that problem. By revising, I think, the policies on WHOIS, there will be less need for proxy services, and so you will not have this kind of problem anymore.

Because registrants themselves will want to provide you correct data to certify that they are the owner of the domain name. The problem they have is with not publishing it to everyone, not giving you their correct information.

And the other thing, I think, that has to be in the contracts is the ability for registrants to transfer away their domain names in an effective and cheap and quick way. Because if you have that, then you can rely on the market to -- I mean, you can rely on the fact that registrants will move to better registrars if they start to have problems with one.

But if you do not have that guarantee, so if registrants are stuck with a registrar because it takes them one year to transfer or it takes them, I mean, ten times the registration fee, at that point, they will not be able to do it and so the market will not work. So that's one of the basic things that you have to ensure in the market.

And then I think that the rest of the things might be less binding. So there's a lot of education to do. And I think there's also a lot of work on agreeing on, for example, best practices.

So I think that registrars, registries, and registrants could agree on the best practices on their relationships. This is something that will not be binding to anyone but would at least provide guidance to all the parties in this market to understand the best way to do things.

And even -- I mean, there are certain things that, for example, what -- one typical problem that registrants have with resellers especially is that registrants buy a domain name, and then the reseller puts themselves as the registrant rather than the actual registrant.

And while ICANN will never be able to enter into this kind of a relationship between a reseller and a customer, I notice that as far as I know, there's no place where someone brought that this is bad. So at least having a best practice document that says that you shouldn't do this could at least help registrants to understand whether their reseller is behaving correctly or not. And maybe even if they went to a court or a consumer protection agency or whatever, it will help them to prove that they were right.

So -- And the final thing that ICANN should do is monitor these things somewhere directly. It should have ways to understand statistically if a specific registrar is causing problems, so perhaps even just through a complaint form which you don't enter into individual cases but just do statistical analysis. If all of a sudden, you start to receive 10,000 complaints in a week on a specific registrar, then maybe you understand that something is going wrong.

Thank you.

>>KURT PRITZ: Okay. Thank you, Vittorio.

I don't know, Patrick or Kelvin?

>>VINT CERF: I'm sorry. I wonder if I could intervene for just one moment.

Vittorio said something which I'd like to, well, dispute is too strong a word, but Vittorio's no stranger to that. You said ICANN was the only entity in the world who could do anything about this. And I wanted to suggest to you that there are some other entities with whom we might wish to cooperate who can assist in consumer problems, in consumer complaints. Within each national jurisdiction, there are often one or more entities that undertake to deal with consumer problems. I'm by no means suggesting that ICANN should simply say that it's their problem. But, rather, we should take advantage of the existence of these organizations to do that.

The second point I want to make is that your plea for fast transfer has another side to it.

I listened last night to Joichi Ito describe the mechanisms by which domain names could be hijacked. And a side effect of rapid transfer or ease of transfer or, let's say, false transfer enabled someone to hijack the domain name.

So before we call for mechanisms that make things happen very quickly, we should also think about how to make them happen safely.

Thank you.

>>KURT PRITZ: Thank you, Vint.

Patrick?

>>PATRICK VANDE WALLE: Thank you.

Well, Vittorio already said a lot of things I wanted to say, so....

But I would add to that that, indeed, your question was, what are the next steps, what can ICANN do, what can the ICANN community do to make things work better.

I think one of the things we could do is educate the user, educate the domain name registrant. Because you not only have 45,000 companies registering domain names; you also have a lot of individuals. And when they register a domain name, actually, they don't know anything about ICANN, about registries, and sometimes not even about registrars or resellers, because they're just buying the domain name from whichever Web hoster is selling them some Web space. For them, the first point of contact is usually the company who has sold them the domain name. And this may not be the registrar directly.

So often, if they lose a domain name somehow through what happened to RegisterFly, for example, they don't know where to go. And if they go to ICANN, then they get the ICANN home page, if they ever get to the ICANN home page, because they know that maybe ICANN might have an answer, they see, have a registrar problem? Find answers. That's good.

But maybe these people do not even know what a registrar is and what the registrar does and what the registry does.

So I think that even if, as it was stated during the -- earlier this morning, even if ICANN does not have customers, at least ICANN has some responsibility to educate those domain name registrants.

The ICANN Web site -- I know it's being worked on, and there have been already a lot of positive changes. Still, if you're not part of the ICANN community, you still have difficulty finding answers to simple questions, like where should I turn to if I have a problem with my domain name? It could be a technical problem. It could be a contractual problem. And maybe there should be a part of the ICANN Web site directed at dummies, ICANN for dummies, for example, with simple graphics, a sort of wizard, click here, and just as you would find on some company support Web sites like Microsoft or others. And that's one thing that I think we should do and that ICANN could quite easily do.

I do understand, indeed, that ICANN cannot be the complaints department for all the problems with domain names throughout the world, because most people would direct a complaint to ICANN, well, maybe they would do it for a ccTLD, in which case it's not ICANN's business. And things like that.

So -- but at least there should be somewhere a place where, okay, you have a problem with a ccTLD. Here's a contact address. Here's where you can complain.

And Vint was mentioning that for consumer protection, ICANN could work with some national bodies who handle these sort of complaints now. See, the main problem I see is that most of these bodies work on a strictly national basis. So if I'm in Europe, if my registrar is in the U.S., how can I -- where do I go to have my case settled? And that's a big issue, because mostly my local consumer protection union will say, "Well, you know, there's not much we can do. You just maybe should go somewhere in the U.S. and complain to someone over there, and maybe they might be able to help, but we can't."

So this is another issue.

And we were -- Vittorio was also mentioning a set of best practices. And I think such things have already been done in the ICANN community, particularly by ccTLDs. And we might get a lot of inspiration from the work they have done and see if it can be implemented and replicated within ICANN. For example, I've seen a draft of a code of conduct for registrars being published by ARID (saying name). And I think there are some very good ideas in such a document and that maybe this should -- this could give a base for discussion within the ICANN community.

So that's about most of what I can say.

So I'll give the floor to Kelvin Brown.

>>KURT PRITZ: Excuse me for just a second. We are pulling up another comment.

>>PAUL TWOMEY: I just want to point out on the ICANN Web site at the moment where, if you're having trouble with a registrar, we do actually point some complaints to an organization called the International Consumer Protection and Enforcement Network, ICPEN.org, which is a group of about 30 consumer protection agencies around the world. That's one of the things we want to work further on. I wanted to address that particular point on your question of where do you go if it's across the border.

>>KURT PRITZ: Kelvin?

>>KELVIN BROWN: One of the luxuries of going third is that my list gets shorter.

There is one lesson that maybe we should take from this, and that is, in a competitive market, failure does tend to occur the more competitive the market gets.

So maybe we need to take some positives out of this. Unfortunately, this particular case was slightly more messy than failures can be. But we just want to point out that there are positives from this failure that you want to take out.

To reiterate what the previous two speakers have said, the clearer that you can make it for the registrants out there, the better. And there are possibilities.

We would imagine that the registrar agreements could be adjusted with that in mind, bearing in mind that that process is complex.

And we also are interested in the code of conduct stuff that has been done. The other speakers have allowed me to be brief. Thank you.

>>KURT PRITZ: Okay. So just to reiterate, our last three speakers of representatives of the at large community. Chris Disspain represents the ccTLDs and is chair of the ccNSO.

>>CHRIS DISSPAIN: Thank you, Kurt. I thought what might be useful is if I looked at some of the issues on the summary and actually talked about what we do in Australia in our ccTLDs that handle some of those issues, because, effectively, we have exactly the same issues with our registrars as you have with yours.

So in no particular order, first of all, our process involves, obviously, signing a registrar agreement. And I think it's critical for ICANN that their registrar agreement is beefed up to be at a level that enables you to basically control where you need to control.

As a simple example among which I would suspect would help new this case, we do not allow the sale or change of ownership of a registrar without our consent. Because we have accredited an organization with people in it. And if they simply sell it to someone else, then we have effectively lost control.

So our rules, our agreements, say you're very welcome to sell, and if you -- but you need to get our consent.

Now, in the event that you sell to another registrar, then that is effectively a formality, and we will simply approve. In the event that you sell to an organization that is not currently a registrar, we will make that -- we will make you reaccredit. So will you have to go through the process of accreditation to take ownership.

We have a policy test and a technical test. And we do have specific people in organizations that are designated -- in registrars that are designated as being the technical person. And a change in those people can mean that the registrar sends the new people to do it, to do a technical test.

I acknowledge and accept that we're dealing with a smaller number of registrars than you are. But, nonetheless, the principles, I think, still apply.

In respect to resellers, we have a large amount of resellers. We mandate that registrars in their agreement with resellers put certain clauses, and those clauses effectively make the reseller do things to make our life easier. One of those clauses is that a reseller must comply with the code of practice. We have a code of practice. It is the registrars' code of practice. We simply facilitated its existence. And resellers are obliged to comply with that as a term of their contract, their resale contract with their registrar.

The issue of proxy -- sorry, the issue of resellers using their own names as the registrant in the database, that has occurred in Australia. We audit the database, and we require the registrar to correct where a reseller has put bulk names in with their information. Obviously, the registrar themselves may have to force the reseller. But as far as we're concerned, it's the registrar's responsibility to control their resellers. And we have clauses in the contract that make them do that.

A couple of final points on transfer policy.

Generally, our transfer policy works on the principle that the losing registrar cannot, generally speaking, prevent a transfer. There are circumstances in which they can. There is a wait, there is a period of time in which they have the opportunity to tell us there's a problem. But, fundamentally, they can't prevent the transfer.

And registrars are required to provide the password to -- or the auth info, whatever it's called, to the registrant within a fixed period of time, even by a manual process, if necessary. Sometimes the e-mail -- the authoritative e-mail address in the databases doesn't work or isn't working, hasn't worked in some time, in which case there's a manual process for the provision of the password to the registrant.

Just finally, on Vint's point and the point that Patrick's picked up about, using other consumer organizations to pursue difficulties, I can tell you that the case in Australia is, we have something called the ACCC, the Australian Consumer and Competition Commission. And each state also has its own consumer trading division. They will very happily pursue problems with Australian registrars, but their immediate response to any question to do with a dot com name or dot net name, for that matter, unless it happens to be with an Australian registrar, is that there is absolutely nothing that they can do. And, in fact, they don't know where they can send you to.

>>KURT PRITZ: Yes, Vint.

>>VINT CERF: Just to respond, I didn't speak very carefully. What I was intending to suggest is that the consumer protection agent that would be relevant to the registrar is the one that one would look for help from. Not from the consumer protection agency from the registrant obviously has these limitations that have been mentioned by two people.

The real issue is whether we can get the consumer protection agencies to be aware of and work with each other so as to effect a linkage between the registrant's problem in country X and the registrar's misbehavior in country Y. I don't suggest ICANN has no role to play at all. In fact, Paul has already suggested one mechanism through which this could happen. I'm just trying to find ways finding mobile enforcement possibilities in addition to things that ICANN might do on its own.

>>CHRIS DISSPAIN: I agree with you, Vint. As Patrick has said, the vast majority of registrants are, in fact, people who just have a domain name. And it's not something that -- it hasn't cost them a lot of money. It can cause them a huge amount of frustration, but the thought of them having to try and contact a consumer commission in the U.S. from, say, Australia to try to lodge a complaint about a registrar who has done something with their domain name, it's really quite hard for that to occur.

I don't know what the solution is, but I just know that it's pretty tough.

>>VINT CERF: Well, keep in mind that we don't have -- ICANN doesn't have operations in 240 countries in the world either.

So if you say it's ICANN's job, we still have that potential difficulty that you just mentioned.

>>CHRIS DISSPAIN: I wasn't actually saying that, but yeah, I agree.

>>KURT PRITZ: Thank you. From the registrar constituency, we have Jon Nevett and Tim Ruiz.

>>JON NEVETT: Thanks, Kurt.

I would like to read a resolution that was approved by about 90% of -- of registrars who represent about 90% of active domain names under management.

Whereas registrars only succeed if they provide valuable services to their customers. WHEREAS, registrants must be protected against the potential bad acts of disreputable registries and registrars. Whereas within the scope of ICANN's mission and mandate it is incumbent on it to protect registrants against the potential bad acts of disreputable gTLS registries and registrars. Whereas ICANN staff has recently formulated a new compliance program for gTLD registries and registrars. Whereas ICANN staff has recently announced its success in furthering a data escrow program and requirement for gTLD registries.

Whereas ICANN staff has not yet scheduled or specified a schedule of terms or format of a data escrow requirement for gTLD registrars.

WHEREAS, many registrars currently secure registrant and domain name data through various backup methods, but that this practice is by no means uniform or compulsory across all accredited registrars.

WHEREAS, the various backup methods used by registrars may not be sufficient in all cases to assist ICANN staff in recovering such data in the event of a registrar business failure.

And WHEREAS, recent events have highlighted the need for a registrar data escrow program, and enhanced compliance efforts with regard to requirements in the registrar accreditation agreement.

Be it resolved that the undersigned registrars call for ICANN staff to work with the ICANN registrar constituency to finalize the terms of a gTLD registrar data escrow program, and be it further resolved that the undersigned registrars call for ICANN staff to work with the ICANN registrar constituency to improve the effectiveness of the ICANN compliance program for gTLD registrars.

And again, it's signed by the vast majority of registrars, gTLD registrars in the community.

And I'm -- Having been the chair of the registrar constituency for almost a year now and working for network solutions for a little over two years, I have come to realize that the registrar community at times could be quite paranoid. And sometimes it's warranted, if you are looking up at this dais, the two registrars up here and many of the other registrar leaders still have not received our luggage

[ Laughter ]

>>VINT CERF: This was deliberate, you understand.

>>JON NEVETT: I note that I was on the same plane with Vint, and he is wearing his suit, so....

[ Laughter ]

>>VINT CERF: No, I am wearing your suit

[ Laughter ]

[ Applause ]

>>JON NEVETT: I don't think you could fit in my suit.

[ Laughter ]

>>JON NEVETT: But I'm very heartened that the registrar community got together on this and quickly responded and agreed to sign on to this resolution, and to make sure that ICANN has the tools it needs to protect registrants in the case of registrar failure.

We have been calling for additional compliance for many years now.

Those registrars, the reputable registrars that actually comply with the rules and our requirements, we believe it's the right thing to do, first of all.

Second of all, we're at a competitive disadvantage to those who do not comply. And so we have been calling for additional compliance efforts, and we are again heartened by the fact that Stacy is up here on the dais and the new -- the new compliance efforts that are being underwent by ICANN.

So we're looking forward to working with ICANN on these efforts.

As for next steps, tomorrow, during our registrar constituency meeting, we will be meeting with the ICANN staff and the ICANN board to discuss these issues, and to go through these -- through this list and figure out which ones work quickly and get the low-hanging fruit ones as fast as possible, the ones that don't require a change to the RAA, which many of them don't, and again to work quickly with you on which ones will work and to give you the tools that you need to make sure that something like this doesn't happen again.

>>TIM RUIZ: Tim Ruiz with the Go Daddy group.

I just want to echo probably a lot of what John had just said, and we certainly -- the Go Daddy group of registrars certainly has signed onto the resolution that Jon just read.

As far as the issue summary is concerned, most of those issues listed there I think are valid to consider, and we'll certainly participate in any activities doing that.

The two, I think, though that we feel have the most immediate need is to complete the escrow requirements for registrars. That's been something we have been kicking around now for a few years and we still haven't quite gotten to that, defining the schedules, the terms, and the format in which that escrow should take place.

And while -- as the resolution said, while registrars do back up their data, we feel that the escrow is definitely needed for situations where there's a failure or potential failure. And compliance, we have called for a long time for better compliance, for better tools and mechanisms for ICANN to be able to force compliance of their agreement. And even in the RegisterFly case we think there would have been more opportunity earlier on if they had those tools and could have used them.

So escrow and compliance are the two things we are looking for, primarily, immediately. And I'm a 42 short.

[ Laughter ]

>>KURT PRITZ: Steve Crocker is the chair of the SSAC.

>>STEPHEN CROCKER: You know, I think we want fair and uniform treatment, and I can report that I, too, was without clothes for a day coming through Milan.

Let me try it raise the temperature here a little bit.

There has been a lot of discussion about modifying or making better use of the mechanisms that we have available.

Let me take some words from Vittorio. What is it we're trying to accomplish? What is it we want here?

And let me try to be a bit more specific about this.

We can play with the mechanisms, but we have not yet articulated exactly what it is we're trying to accomplish.

How much protection do we want for registrants? How much latitude do we want for registrars? How much latitude do we want for resellers and for registries, and so forth.

So, for example, do we have any idea of what kinds of errors or failures or abuses actually take place? Have we measured them? Is the experience in the gTLD space comparable to, say, the experience in Australia, to pick up from Chris's comments, for example. Or is there a pretty big difference? I have no idea.

The fact that we have no idea, I think that very few people have any insight into how the market is actually behaving, suggests that we are actually inhibiting both the discussion and the development of our value system and the adjustment in the markets because we're not sharing that information.

Now, I know that there's been a propensity to try to keep abuses, complaints, and so forth dealt with on a quiet basis out of deference, out of trying not to make a lot of issues out of things. And out of, frankly, trying to protect the community and to probably, some extent, ICANN.

But I think sunshine is probably more helpful here than not.

So my first and strongest feeling about this is, before we start fiddling with the mechanisms, before we start putting energy into all this, or maybe in parallel, we ought to back up to first principles and say, what is this market that we have constructed? How is it behaving in and what do we want out of it?

This is a 100 percent artificially constructed market. This market is built out of absolutely nothing except symbols that we have created, that we promulgate. And all of the mechanisms -- I mean, there is no physical -- we're not stuck with the physics of farming or the physics of melting steel or any of the natural processes that have shaped markets in the past.

There's very, very little sort of real-world stuff here. This is 100 percent an invention by us, by many of us in this room and practiced by us. And it's within our power to adjust those mechanisms.

So we've created the registrar mechanism, we have created the reseller mechanism, we have created the accreditation mechanism. And they serve us probably reasonably well, but they also don't serve us as well as necessary.

I'm not suggesting we want to throw all this out, but I am suggesting that we don't have to accept that they exist, and, therefore, we have to live only within that framework.

Now, we all understand that you can't have a contract and then ignore it and trample over it and we have to be controlled by laws and there are other things. But there is a level at which one can ask, is all of this working right? And if it's not, then we can begin to seek paths for fixing that. Some of it may take a little while with policy development processes and so forth. But I think the very first thing to ask is what would be a satisfactory balance point in the market? There will be bad actors. There will be bad actors among the registrants, among the registries, among the registrars. One could run numbers and predict with some accuracy what these behaviors are going to be.

This is a standard in all sorts of markets. And law enforcement and insurance companies and others that have to deal with large-scale human behavior and the excesses of it deal with all of that very professionally.

We have not yet reached that point in the development of this market. We're at a kind of early stage. I tend to think of it as still kind of a wild west orientation, as opposed to smoothly running.

The commodity that we're dealing with is a very peculiar commodity in that it is a very low price and has very little intrinsic value at the outset, and then enormous value as people -- as a registrant makes use of it.

If I lose my domain name and I'm running a business based upon that domain name, I'm out of business.

This is not a small matter. It is far worse than, say, if the electricity is cut off, or even if my telephone is cut off. I can replace those far easier than I can replace my domain name.

So the underlying value, or the sort of quietly -- the accreted value in a way of a domain name that's been in use is potentially enormous, and the harm that comes to the registrant is possibly catastrophic.

We have to fashion the mechanisms for protection, I would say, to match what the risks are. A contractual process that's dragged out for months in courts or an uncertain dispute resolution process, or a consumer complaints process is probably okay for certain aspects -- for example, the bill is too high, but I paid it and now I want to get a refund and we're going to haggle about that. That may be an okay process, but if the domain name is turned off and I'm out of business, I've got a problem right now, and having no way of dealing with that on an urgent basis doesn't do me any good.

That's my speech on that.

And then to return to my earlier point, we don't have any numbers on how bad that is.

I think we need some numbers.

Then we can go to all of these ideas, which are all very reasonable ideas, and ask whether or not we've got the parts lined up. In the committee that I chair, the Security and Stability Advisory Committee, we have done a couple of reports on domain name hijacking and on the consequences of releasing your name and having unintended consequences come after that.

The issues that we're seeing in RegisterFly and related situations are all a part of that general story of whether or not the interaction of these parts, particularly the failure modes of what happens when a losing registrar does or doesn't behave properly, when a gaining registrar does or doesn't behave properly, whether a registrant is actually a bad actor, all of those things have to be explored in a great deal more depth and comprehension than we have done to date.

And then, as I say, once you've got a look at the whole thing as a system and not just, well, we'll fiddle with this clause in this contract or we'll have a meeting of some people and we'll have a best practices, so forth, those are all implementation mechanisms, and, to a certain extent, details within the larger framework.

That's my speech.

>>KURT PRITZ: Thank you, Steve.

[ Applause ]

>>KURT PRITZ: Yes, Vint.

>>VINT CERF: You were looking for a number. 42.

>>STEPHEN CROCKER: I think that's a little short.

>>KURT PRITZ: Stacy Burnette is ICANN's manager of compliance.

>>STACY BURNETTE: In reviewing the issues summary, there appear to be a number of suggestions and ideas that might be beneficial in terms of reforming the RAA, especially the additional compliance enforcement tools, that would assist ICANN in enforcing the terms of the agreement.

But until those suggestions or ideas actually morph into terms in a new agreement, it's ICANN's intention to enforce the current agreements that we have. And we are doing that.

And just to give you an example, three weeks ago, all of the registrars that are represented in this room, and all 880 registrars received a transmittal from me saying that you have to update your primary contact information because we are commencing our 2007 registrar audits.

And just to give you an idea, we published our audit schedule, and we currently have an audit underway concerning Web site compliance. And while there are 880 registrars currently, we have completed checking the Web sites of 520 registrars, and we found that, while some of the larger registrars appear to be compliant with the Web site requirements, we have other registrars that aren't in compliance. And we found 40 cases of registrars that didn't have a working Web site at all.

We found another 35 cases -- I'm sorry, another 27 cases where their WHOIS service wasn't working on a particular Web site.

And so we are going to question those registrars who don't appear to be in compliance and ask that you respond back to us as to whether we just can't find the information, whether there was some technical problem. But we are enforcing the current contracts. And we intend to go forward with our registrar/registry schedule that's been published with the new compliance program, which you can find at icann.org/compliance.

And we look forward to reforms that might come later, but until that point we are going forward with what we have in the current contracts.

>>KURT PRITZ: Thank you. Did you have anything to add, Paul?

>>PAUL TWOMEY: Thanks, Kurt.

I think I've got a couple of observations, following on from Steve's intervention, and then also I want to make some comments prior to that.

First of all, I'd like to particularly put on record my recognition and thanks both to Jon and Tim individually, but also to the registrar constituency for the resolution that you read to the record. And the, I think, positive, cooperative approach that you have taken. I appreciate that very much.

And I appreciate very much, as you point out, that some of the issues that were placed in my communication are not all in the registry accreditation agreement. They are actually in the broader environment.

They also include issues that relate to ICANN's own actions and things that we need to discuss there.

I think one of the things we should clearly be talking about is, we've mentioned before, but we should put more pressure on the agenda to talk to the Governmental Advisory Committee to deal with the communications with consumer protection agencies.

I note even in Chris's example that we have had different answers from Graham Samuel than you have, just in conversation.

So I think what we need to do is put that more formally back on the GAC agenda as one of their items. Perhaps not at this meeting, but as an item to be followed up on for cooperation on that sort of cross-border consumer protection agency.

One thing that is clear to me in management terms is we need to continue to augment in ICANN the separation of the compliance function from other functions and support registrars and registries. I think that just ends up with an ensured focus and continued focus. I'm not saying there hasn't been a focus. I'm just saying it's one step we will be continuing to do is have a very clear compliance function.

And that compliance function is separate from the legal function, it's separate to the registry/registrar liaison functions. Just so that there's clarity, not so inside ICANN, but clarity in interaction with the registrant or the registry, so they understand which part of ICANN and which hat am I dealing with at the moment in this questioning.

I think to come to some of the questions that Steve raises, I certainly think that sort of analysis is required, but I think we can make a couple of statements already in pretty general terms about the markets.

First of all, this market is not a commodity market. And as a consequence, it's quite hard to do an apples and apples comparison with all suppliers. Because even though they are registrars for our purposes, many of them are actually businesses that do other things as well.

And that's been part of the consequence of the competition.

I think partly to answer the question that Steve also asks, we should not forget that we have made at least one fundamental philosophical decision early on in the creation of ICANN, which is that we will utilize market mechanisms for delivery of benefits to consumers.

That's not to say that all Steve's questions are invalid. I'm not saying that. But I am saying the first principle -- there is an existing principle which is that we have used market conditions, we have used separation of registry and registrar, we have competition at the registrar level, and that is a first step in provision of service to the consumer.

It does strike me one problem we have the information flow to the consumer about particular benefits of the registrars is not transparent. In that sense we don't have transparency in the market to the consumer. I'm not saying, per se, that's an ICANN role, but that's nevertheless, I think in this instance I think Steve is correct, it is an immature market in that there have not been the intermediaries that have developed in the marketplace to provide information across the information flows of the market.

I would make the comparison that in pension funds, morning star plays a major role in rating funds managers. We don't have morning stars inside the registrar environment.

The second observation I would make, even if the market is not a commodity market, there probably are families of services. And in the families of services -- in other words, you could break the 850 down to maybe three or four types of markets. In each of those markets, there will be cost curve for the provision of services, and you can guarantee in any marketplace, it's the people who are at the marginal cost provider who are going to face difficulties.

Difficulties driven either by changing in the pricing or any other circumstance.

But if you are running on particularly low margins, then you are more likely to be in trouble than if you are sitting on very good margins, depending on where you sit in the cost curve of the industry.

I make that point because I want to make this point. I'm not trying to run counter to the points that Steve has made, but I am concerned about this.

I don't think RegisterFly is a unique instance. Indeed, I think RegisterFly, in some respects -- in some respects it was unique more in terms of what happened internally in the management. There was a particular phenomenon in the management of this company that resulted in where we are now.

But there is undoubtedly tens of registrars who are marginal players because of where they sit on the cost curve, and it is undoubtedly one of the things that I worry a little bit about is any company that's sitting on that edge will have all sorts of financial arrangements in place for how to survive day to day. And that's fine. That's a market, that's what capitalism is.

The issue that I worry about is not -- it part of our previous analysis. Our previous analysis in this place has tended to be an on/off function. A registrar is fine or a registrar has failed.

A registry is fine or a registry has failed.

But we've got really a third function. It's the venture capitalist nightmare. We've got the zombie problem, the walking dead. Because the business risks and the business problems that we faced in ICANN interacting is not when the company fails. It's actually when the company is into trouble but not yet failed.

And that's a very interesting set of issues, which Steve, may I propose that we should do the sort of questions you ask, but we can parallel process other questions relating for what would be -- There are going to be business -- When the company is in problems, what do you do in the business circumstances there, which has certainly been brought to light by the RegisterFly circumstance.

That's part of the analysis we need to do in engagement with the registrars.

And I know that's part, also, of the concerns of the paranoia of the registrars, to take Jon's words, I would be in the same problem. I would be sitting there saying I'm a good registrar and I don't want ICANN to be sort of playing around inside my business, thank you very much, too much.

And that's a fine position to be in. But we have to have quite a dialogue about what do we do in the circumstances where the business is not fully functional and it's not fully dead. It's in between the two. And our concern is the registrant, while the concern of the registrar is the shareholder.

That's a dialogue that I think we could fully have anyway, even despite -- even parallel processing the sort of analysis that Steve has indicated.

Steve Crocker.

>>VINT CERF: It occurs to me that that analysis, which suggests this range of registrars and range of condition of registrars from healthy to walking dead to gone, but not forgotten, there's another range having to do with the registrants themselves.

There are some registrants who are like the domainers in constant touch, even automatically with software, with one or more registrars and constantly interacting and have a very refined understanding of how the system works.

The other end of the spectrum is someone who registered one or two domain names may or may not have actually put up a Web site. And by the way, has an interaction once a year at most, perhaps even once every two or three years if they registered for multiple years. And they forget who they registered with. And then they get notifications from other registrars that they didn't register with who know that when their registration is going to expire and they are told, "Don't forget to reregister." Of course, it's an implicit transfer.

There are a whole lot of thing on that end of the spectrum which you could raise as potential consumer hazards.

So in the course of trying to analyze the space of things that we're trying to protect consumers from, we need to distinguish among the various range of consumers as well as the range of registrars that would fit into this framework.

>>KURT PRITZ: So before taking comments, there's a brief slide here about next steps.

I think it's already changed based on a lot of the comments we've received up here and that potentially again from what we are going to see right now.

But certainly, we've described a consensus based discussion that's going to happen next to address these issues raised.

There are certain very specific issues to be accelerated. One we knew in advance of this presentation was the release of the data escrow plan, and also the active prosecution of compliance issues the way the registrar accreditation agreement is written now. And I seem to use the word prosecution a lot but in this case it's about perseverance until completion.

I think some other important issues were raised here. One is about the difficulty in using consumer protection agencies in a -- with a global community of customers when they have limited jurisdiction.

Another is a discussion of controls on resellers and change of registrar ownership. There are actually several. And, finally, having to do with Steve's more comprehensive study.

So there's a couple more things we want to say up here, but if anybody has any questions, I welcome anybody to the podium.

Amadeu, can Steve Crocker say something first?

QUESTIONS FROM THE FLOOR

Okay, go ahead, Amadeu.

>>AMADEU ABRIL i ABRIL: Okay.

Amadeu Abril i Abril, domain name owner, registrant, sorry.

I have lots of comments about everything you said here, all of you, but I will just try to do some concrete proposals here.

As many of you know, I've been on the side of those advocating for ICANN enforcing compliance for a long time. And not only that. It's a question of we all agree, I think, that ICANN is not in the business of adjudicating consumer disputes. Individual problems and individual consumers and individual registrars. It's not the business of ICANN. ICANN is responsible for the landscape, for the design of the system.

And, therefore, it's responsible for addressing, when we see that there are repeated problems in some areas or repeated problems with some registrars, then there is the failure where ICANN should act. Sorry. Not just to eradicate malignity in the world, that would be very nice, but probably is beyond the scope and the possibilities. So some concrete issues that can be done here.

We know we need things. The first thing was the transfers. And we have something that's better than what we had at the very beginning. But still there are lots of complaints among registrants about the difficulty of getting their name transferred. And probably -- I am completely sure I know that -- most of these complaints go to a very small subset of registrars.

And then we have other type of behaviors that we shouldn't discuss here probably. We need still a better transfer mechanism.

Second, escrow. As Paul pointed out, RegisterFly is an accident, but probably not the only accident we will have here. So some solution for the registrar escrow system that has never been implemented, especially under dot com and dot net, with the thin registry model where all of the data is in the registrar's hands is really overdue.

But third and more important, we need credible compliance mechanism.

Now what we have, we have death penalty. We can terminate accreditations. This is overkill for most of the situations. And this is not a credible threat for the behavior of some marginal registrars.

So we need other things.

The stick and the carrot, we need labels for all the registrars of which ICANN has never received a complaint, which are lots of them. But we also probably need some partial punishment. For instance, if you do a termination of the accreditation, you're also punishing the registrants that suddenly have to transfer that, even if they don't have a concrete problem with the registrar.

I have always been advocating for a solution, for instance, ICANN suspending the ability for a registrar to register new names for one to four months, but, you know, being able to service all those registrations that have already paid for. In case of repeated problems with transfers, repeated problems with not allowing, you know, changes of the registrant data, and problems with trying to induce registrants, misleading them into, you know -- pretending that they are the registrant of record for some registrants when they are not, we know that the list of these three problems occur very often. We should have some partial solution preventing these registrars from doing new business for one to three months, but not still killing them, because this is overkill. It is not credible.

>>STEVE METALITZ: Thank you, Steve Metalitz, on behalf of the intellectual property constituency. Just briefly, I want to say, we're very supportive of this initiative, as was laid out in the president's statement and as we've been discussing here. We think it's long overdue.

We -- I just would like to encourage ICANN to make sure, first, the efforts, all the things that have been talked about here, are fully resourced and are given a high priority. You have heard from us at this microphone ad nauseam about the importance of making contract compliance a top priority for ICANN. And I'm hopeful that this initiative will start to translate that into reality.

I hope that the initiative will involve not only the participation of the registrars, which, of course, is extremely important, but also of representatives of registrants, including the members of my constituency, the intellectual property constituency.

And I think it's also very important that while we look at the larger issues that Steve Crocker has raised and the need for changing the registrar accreditation agreement, it is also important to be actively enforcing the agreement that now exists. And I just want to thank Stacy Burnette for her responsiveness to the concerns of our constituency. And we look forward to working with her and with the rest of the staff on all of these issues. Thank you.

>>SUSAN CRAWFORD: Susan Crawford, ICANN board.

Two points looking back and one looking forward. The first point looking back is that I share Steve Crocker's concern that ICANN's worries about its own liability and concerns about making information public may have led us down a path where inadequate compliance was actually taking place. And resource constraints have something to do with that as well. I'm hopeful that we can drive forward now. Certainly this crisis is making us focus in a way we hadn't before.

But there will need to be some accountability for the lapses over the last five years or so.

Second point looking back is that this document, the registrar accreditation agreement, is not divine. It was created by people trying to bring this artificial marketplace into being in order to create some competition to the then-Network Solutions monopoly.

It's clear from this discussion that the sanctions-related clauses in that contract are not supported by consensus. They're simply not. There's uproar in all areas of the community about the weakness of this binary regime. So the forward-looking point here is that I think it would make a lot of sense to sunset the sanctions clauses in these contracts, just those specific clauses, and have a quick consensus development process following the PDP guidelines, actually meeting those dates. And what I mean by sunset is that if parties don't come to a consensus by a date certain, those clauses just disappear.

Now, that can't happen. So something will come into place in its place. And the parties will be forced into a room together, have to come to agreement. And that's the way this should work. Thanks very much.

>> RUI BEBIANO: Hi, my name is Rui Bebiano, from Portugal. First thing, I think that although there is a problem of compliance, I think that the best way to solve this problem will be to let the market solve the problem and also the bad registrars. So if it was really, like Vittorio said, not quick, but an easy way for a registrant to transfer their domain out of a bard registrar, this should never have been an issue altogether. Because the problem here with RegisterFly is that people just can't get their domains out of there.

And I would suggest that since we have an outcode, the outcode should be with the registrant. Some of you might argue that that would create a security problem. But, anyway, the security problem already is. If someone wants to hijack a domain, that shouldn't be stopped by the fact that the domain is with the registrar.

So if there was a mechanism that would provide the registrant with their own outcode that they can use in a situation like this, and he wouldn't have the need to -- for the registrar to be in the process of letting him transfer out of them.

Anyway, I think that this is not the only problem here.

I was here yesterday, and I saw something absolutely astonishing, someone saying that when the domain expires, the registrant changes. And there are some registrars that do that, they just take over the domain and they don't give -- they don't care about the (inaudible) process. And that's another problem that should be addressed when thinking about the new registrant agreements.

One other thing that can -- it's somewhat lateral to this, is that the UDRP is a very expensive process. If someone took my name in the process of the domain being evicted, it shouldn't be economically feasible for me to go to a UDRP. It should be cheaper to buy the domain for some cybersquatter than to pay the UDRP fees.

So that should be taken into consideration, too. Okay, thanks.

>>KIEREN McCARTHY: Sorry. Could I just jump in here? It's unrelated. I'm not sure there's going to be a moment with the way this discussion is going to put this information out there and I want to do it now.

With regard to -- I'm the general manager of public participation. I want to say what happened with regard to the participation from the public, if that's okay.

Okay. Well, -- okay. Thank you.

The RegisterFly situation provoked a very wide response from the public. We made the first announcement on the 2nd of May where RegisterFly refused to allow two staff members into the offices to inspect and secure the data.

But it became very clear soon after that that there was a lot of individuals who were being affected. So we took an active decision a few days later to elicit comments from the public. And we did this by posting a series of blog posts in which the responses were open. Anyone was able to comment. Anyone was able to say what they wanted.

We received in the first week 500 comments from -- just under 500 comments from around 200 different people. And the ICANN ombudsman received about another 195 responses as well.

When the troubles with RegisterFly went into a third week, we took the decision to take several staff off their normal duties and dedicate them to helping the registrar team deal with the flood of e-mails that they were getting from angry customers.

We've had several more official announcements since then, several more blog posts since then. We haven't had time to do a proper analysis. I've got a very small analysis of the 500 initial responses. Of them, 494, of them, 13% concerned ICANN's authority, and including accredit (inaudible) of ICANN's failure to stop this happening in the first place, 6% covered RegisterFly's proxy registration service, which somewhat ironically was supposed to protect registrants but actually made it impossible for ICANN to get at the data.

31% were about transferring the domains, getting hold of the authorization codes to transfer domains. But remarkable 34% were about registrants sharing information with one another on the blog.

So ICANN was a meeting spot rather than an active participant. And we were delighted that this enabled a lot of people to get their domains back. We were very pleased that the blog served that function.

And, yes, if that was a thread to draw through these many thousands of comments, it's very difficult to summarize, but the thread is that most of them were frustrated by the lack of information about what was going on and what could be done. And that was -- that's the thread through it.

Now, we tried, sincerely, to fill this void as frequently and sensitively and effectively as we could. And the response was not always greeted warmly, but we think we helped reduced some of the stress on individuals. And we will be reviewing what our response was and what we can learn from it.

And we have also prepared a fact sheet which you in the room should have. And I've done -- just put up a blog post with it downloaded from a PDF, which hopefully will give the wider public a better understanding of what the system is, why we can't -- why ICANN can't just stop this from happening and what the history behind registrants and registrars are.

>>VINT CERF: I'm sorry, Bruce, may I interrupt.

Some people have meetings that are scheduled at 1:30.

So Board Governance Committee members, if you need to go, you should feel free to do that now.

We'll continue the questions. We need to make this room available no later than 2:00. We're going to shoot for 1:45. I have one other intervention before we finish, after we get through the questions, one other intervention before we close this session. So, Bruce, you're on. Thanks.

>>BRUCE TONKIN: Thank you, Vint. Bruce Tonkin from Melbourne I.T.

Firstly, Melbourne I.T. applauds the approach that ICANN is taking to this and supports the issue and further work on that issue.

One of the things I hear, and I find interesting in the different language people use about domain names, and I think -- and I was interested from the point of view of the public participation point of view as perhaps getting better authoritative information.

But I think most people in this room don't even know what the role of a registrar is. And I think I could easily explain it by saying we provide a records management service. We don't actually sell domain names, because there's no such thing as owning a domain name. What we're providing people is a license to use a domain name for a prescribed period of time. So when someone says the name is expired and how come I can't get it back, it's my name, it's not, actually. You licensed the name for a period of time. That license expired. You didn't renew it. The name is being provided to another party.

So records management service, if you understand that, what you're paying for is the quality of that records management.

And in actual fact, just to pick up another point Vittorio mentioned about registrants paying and some of them pay or it's perceived that they pay 25 cents.

In fact, you can actually get domain names for free. There are commercial entities in the market that provide a free service. Now, of course, you get nothing for free truly. So, basically, they -- by going to their Web site and getting their free service, they're hoping you will go back to their Web site more regularly. And they get money from advertising on that Web site.

They don't actually charge the registrant anything, though, in that particular business model.

So, then, that registrant has a problem and says, oh, hey, I didn't get very good service. Well, they paid for zero service. Well, they paid zero, and therefore they effectively are getting zero service.

So you need to understand that the registrar, what you're paying for is records management service. And that varies in quality.

But a lot of the issues I think come around the RegisterFly thing come down to -- one is that people didn't have the ability to renew their license. And I think that's an issue that's very different from, you know, the license expired because they chose not to renew it. And certainly I think a lot of the approaches here that when there is a business failure or there is a failure of a registrar to allow you to transfer out, that, you know, there's obviously a time limit where the registrar should resolve that. But I do think we need to come back to the transfers policy, because that has been under review for a while. And I don't think we've really given that due diligence. And I agree with Vint, we can't just suddenly say, we can't worry about any authentication. You just simply stick your hand up and say it's mine, I'll transfer it to you. Because that highlights a lot of problems with records management, because a lot of those registrars and registrants don't manage records very well. In fact, they don't even record correctly who the license holder is. And that causes no end of problems when there are disputes, because quite often it's an employee of a company who's been listed as the license holder, and that employee leaves that company. It's not the company that is the license holder; that's that person. They've left. You've lost the name. Well, you've lost control of it, at least.

So, you know, people need to understand that it is the record, it's just like a title to a house or anything else for land or something. You want to know who's on that title.

You know, when you go and get a solicitor to do work for you to register your house, make sure it's your name on it, not the solicitor's name, when you've just paid $100,000 for your house. So, you know, a lot of it comes down to records management, plus providing an ability when there is -- when you're having an issue with your records management provider and you do wish to renew your name, that you can transfer it across.

And I think ICANN needs to provide perhaps some back-stop procedures there for when a registrar fails in that area to allow transfer. And I think the discussions I was having with some other registrars yesterday around escrow, that, really, what you're doing with escrow is providing the ability to do a transfer. Because there's a competitive market. There's a lot of records management providers out there. But if you can't actually get the credentials to manage that name, you can't avail yourself of that market.

So it comes down to understanding what the roles of the players are, know what a registrar actually does, know what you're paying for and what you're not getting with that payment. And ICANN needs to provide at least the support as a backstop to allow transfer to another records management provider that can provide the service you're seeking. And an escrow, I think, is going to be an important part of ICANN's ability to be able to provide that back stop role.

>>VINT CERF: I want to know where you can buy a $100,000 house. Sorry, it's all right. Go ahead.

>> JOHN BERRYHILL. Hi, I'm John Berryhill. And I was a representative of one of the domain registrants that was mentioned in one of the letters that ICANN posted. And while I can appreciate the understanding that ICANN is not a consumer protection agency and that there are relevant authorities for dealing with problems, actually, during the course of my dealings with RegisterFly, I was physically threatened by one of the -- one of the people associated with RegisterFly, and I understood that I turned that over to the New Jersey police.

And that there is not -- with 600, you know, registrar complaints coming in to ICANN every month, you can add an enormous amount of staff and not be an effective complaint desk for the Internet.

But I want to emphasize what Jon Nevett said, that many of the problems that people complain about are failures to comply with the existing provisions of the RAA, and that, you know, using a dramatic event as a justification to open a window for everyone's favorite policy agenda is probably not effectively serving registrants.

And in the absence of the type of analysis that Mr. Crocker suggested, I am skeptical of, you know, the notion that, well, we -- there are auditable things in the registrar accreditation agreement and if we audit things, this is a proxy for providing registrant protection. I'm sure that every fire extinguisher on the Titanic was in perfect working order and that all of the milk was fresh aboard the Hindenburg. But, you know, these are things --

[ Laughter ]

>> John Berryhill: These are things that can be measured, audited, and complied with, but they have no relation to the actual value that registrants place in the domain names or their ability to deal with them.

In Joichi's case, where his name was hijacked, you know, we talk about in terms of the transfer policy, is it too quick or too slow, ultimately, the person that cares -- ICANN's getting 25 cents, the registrar is getting a couple of dollars -- the person who cares, it can be of great financial, emotional value or whatever, is the registrant.

At the end of the transfer policy, there is a dispute policy provided for that. But the registrant doesn't have a hook into that. That is to be initiated by registrars. And, quite frankly, you know, what registrar is going to care? This is why the transfer policy never gets invoked. What registrar is going to care? It's a $2 or $3 contract from their end.

So if there were a way to define provisions of the registrar accreditation agreement that we want to give registrants a hook into without making them third-party beneficiaries as against ICANN, it would make sense to provide some sort of RAA dispute policy that if the registrant cares, that's where the value is, to define a policy to address items like title of the domain name or registrant identity, renewal problems, transfer problems, access and control problems.

And this could just have a very narrowly defined set of outcomes, transfer the registrant within the registrar to the prevailing party, transfer it out to another registrar, and would have the effect of making, you know, ICANN just the manager of getting the dispute proceedings into a dispute resolution provider without having to be, you know, Lord Solomon over every problem that should come up. Thank you.

>>ELLIOT NOSS: Elliot Noss from Tucows.

I think John's provided me a bit of a launching point in a couple of ways.

First, I think if a registrant has a registrar who doesn't care if their domain name is hijacked, they have the wrong registrar. I think Joichi's case is a great example. And it was not because it was him. We deal with this situation very quietly all the time. We look at it, whether it's a $2 contract, a 50-cent contract, or a $10 contract, that it's our job to care about that. And I think that it is not -- you know, to use that Titanic example, I don't think a regulation that would have required that the captain not drive into an iceberg would have helped the Titanic not go down.

So I don't know that you can legislate or regulate against bad behavior.

Steve Crocker's comments provided a great frame for what we're talking about. And there's a couple that I'd like to pull out in particular.

First, Steve said something that I don't remember in all of my years of ICANN participation hearing. I know it's something that I've been saying since the beginning. Which is that the concept of registrar is an artificial construct at a business level.

The reason that Tucows commenced a wholesale registration business is because we said a simple thing: Registrars don't sell domain names. Web hosting companies and ISPs sell domain names. That this was a concept of regulatory arbitrage, in essence. I think that's a very important placeholder to hold in mind.

Steve made another point that I think is very important, which is around data. So I'd like to share some data. Because, again, you can't regulate against bad behavior.

We have and have had over the years in the order of tens of thousands of hosting companies and ISPs as customers. The incidence of business failure is less than 1%. Didn't know I would be here presenting that data, and would be happy to go offline with Steve and let's figure out how many tenths of 1% that actually is.

And there's another piece of data that's extremely important, which is that since the very beginning of domain registration, when there was still a monopoly, what Web hosting companies and ISPs who had to sell and administer domain names, and, in fact, at the beginning they rarely sold them, they just went through the Byzantine provisions that were required to acquire them, they would insert their contact information.

They didn't do that as incidents of bad behavior or as any means of exerting leverage. That he did that because they were protecting the registrants and doing what was their job, which is to help make Internet services easier for the people, the 95-plus percent of the people who don't understand this stuff.

You know, I found -- Vittorio made two points that, for me, were in direct conflict, direct conflict with each other.

First, registrants really don't understand, you know, what they're doing with registrars and Internet services. Completely agree.

Second, that resellers, or registrars, who insert their own contact information are doing something wrong. They're doing that precisely because registrants don't understand.

One of my great frustrations with this whole process, with people coming from all over the world, filling up a room, three times a year, is that we have one of the worst say-do ratios of anything I've ever experienced.

So let me call out a couple things specifically.

You know, Vittorio, Patrick, I know you guys are really well intended around this. Please, take it upon yourselves, there could not be a more constructive step for the ALAC to take than to try and educate registrants around what they should know, what they should be aware of. In that vacuum, we have an industry that buys on price and lives on service. There is a difference between what people sell and what customers are buying.

And that is something that you guys could do tomorrow. In frustration, in frustration around that not existing, in frustration around this whole RegisterFly discussion, we published on the Tucows blog today -- blog.tucows.com or Tucows.blog.com -- a set of what we think all registrants should know. We don't do that because we think we're the final word. We do that because there is a vacuum of information and so much misinformation in the way this is discussed.

Lastly, there was a challenge to ALAC. I want to call out, Stacy, you and I haven't met, I apologize in advance for meeting like this, but, you know, I think it's important -- it would be important for me, Paul, Kurt, a challenge, you guys, to say not just here's what we have started to do, but to say, you know what? We haven't enforced compliance as well as we should. Or let me be clearer. We haven't enforced compliance, and we need to start now.

You know, Stacy, you called out a couple examples. That's great. I feel that those came directly from me yelling at Kurt about them a couple of weeks ago on the phone.

So now that's not something that, you know, we should be applauding you guys for. I am thrilled to be listened to.

The existing RAA has so much that can and should need be complied with, that can be done now. It's not complicated. It doesn't take task forces. It doesn't take working groups. It doesn't take consulting. It just takes do. That's all.

When we talk about frustrations with transfers, they are almost without exception because of noncompliance with the RAA.

Let's see where we can get to enforcing the rules that we have in place today before we spend a lot of time and effort figuring out how to change the RAA, how to change transfer policy, how to change the world as we know it.

Thank you.

[ Applause ]

>> PHILIP CORWIN: Good afternoon. Philip Corwin here for the Internet Commerce Association. I just arrived this morning, and Air Portugal promises that my luggage will arrive tomorrow.

>> Don't believe them. Won't happen.

>> PHILIP CORWIN: Let's see. Quickly, we want to commend ICANN for holding this public forum and for its public commitment to learning from the RegisterFly situation and assuring that there is not a repetition.

Certainly, to my mind, personally, one of the most disturbing aspects that registrants who opted for privacy protection turned out to be the least protected individuals of all. I think the questions that have been posed by president Twomey and -- are good ones. They're complex questions. The answers are interrelated. And while it's important to act expeditiously, it's also important to act right.

I know that often in doing -- in my day job with the U.S. Congress, when there's a problem, there's often a rush to enact new rules when a large part of the problem stems from the fact that there was not adequate oversight or enforcement of the old rules. So I think we all in the community have a better understanding of where there was inadequate information, where there was a lack of adequate enforcement tools, and then proceed from there to add what's necessary to move forward in the future. So we look forward to working with the staff and the community on this, and hopefully to, if possible, to getting some -- what needs to be done by the next meeting in San Juan. Thank you.

[ Applause ]

>>BERTRAND DE LA CHAPELLE: Hi, my name is Bertrand De La Chapelle. I'm the GAC -- the French GAC representative.

A few comments, picking up on previous remarks.

First of all, it is obvious that that kind of cases is bringing into the sunlight issues that is of the highest importance that previously had not been addressed. And it's, in a certain way, positive that this comes to the forefront of our concern.

And it's a good opportunity to congratulate the ICANN for holding this session and also Kieren, I don't know if he is still there, for having inaugurated his job with such a crisis that allows rapid response.

A few points.

I want to say how much I support Steve Crocker's comments, and especially the notion that in as much or to the extent that the DNS and the domain name system is a market, it is a very special type of market. It is a full man-made market.

As a matter of fact, it is not so much a market as the management of a man-made public resource that, according to the words of Paul Twomey, we have decided to manage, at least in part, through market mechanisms that we designed.

It's very important to understand the level of -- of control that we have on the market mechanisms we're putting in place.

And it is very important to use market mechanisms. And this is for many reasons why this system has expanded the way it has and globally has achieved a large number of positive goals.

But it is very important that in all of our discussions we keep in mind how man-made the resource and the mechanisms are.

In that direction, I would also support or underscore Susan's comment on -- Susan Crawford's comments on the distinction to make between what Steve Crocker is proposing in terms of really deep thinking about the system, and the fast track need to have a sort of deadline-bounded consensus development on a few rapid elements.

I think in many cases, from what I understand now, in the processes of policy development, the question of the schedule and the bound trees and the constraint to get to consensus is something that we are really struggling with, and it's a good case and point because here there's an urgency.

Another point regarding what Bruce has mentioned, I won't elaborate on that, but it is very interesting that he stressed the analogy with land records management.

If there is one thing that shows how much this is partly a market, but also partly public service function, is the comparison with land records management.

You can find many ways to manage land records. In some countries, it can be managed by a completely public agency. In another, it's a completely commercial agency that has a delegation for a public service.

But it remains, at the core, some sort of a public service that can be run by market function or by the public sector.

The diversity of tools is the important thing, but the function is the same.

I think it's very true that in that case, the comparison with record management is the real function of registrars.

And finally, Amadeu advocated sort of two-pronged approach, like the carrot and the stick. And it is true that the rating -- I suppose ICANN, in a general manner, has a lot of information about the level of complaints regarding a given -- a given registrar. I could imagine that something like a meter or a rating system, like the eBay rating of sorts is able to indirectly label the registrars that are generating the most complaints. I don't know how that can be done, but this kind of positive labeling is an interesting thing.

And on the other hand, Amadeu was absolutely right in saying that if the only tool that the ICANN structure and the ICANN board has regarding a registrar is the nuclear option of just terminating the contract, we don't have the graded set of tools that allow for, for instance, suspension of registration during a period, moving the control of their management database or their record database to somebody else in a given period of time.

And a final conclusion, this discussion is a perfect example of the delicate challenge that ICANN has between the day-to-day management and the creation of a system.

In that case, the real benefit and the value added of ICANN and ICANN processes is to help set the system and the structure. It of course has to deal in that case in day-to-day or concrete cases. But the real value add of the whole consultation process is to allow everybody to discuss the mechanisms we want to put in place to prevent the kind of situation, rather than putting in place the mechanisms that solve the difficulties afterwards.

Thank you.

>>KURT PRITZ: Steve Crocker had a comment.

>>STEPHEN CROCKER: Yeah. Thank you.

I wanted to get back to the comment that Paul Twomey made about one of the fundamental assumptions is that we're going to have -- that we decided to have a market driven economy, if you will, or a market driven process here.

I agree with that, but I want to say rather strongly that I think the phrase "market driven" -- I forget what the rest of that is, is fundamentally pretty thin. It's only skin deep. It is a slogan. It is -- And along with that slogan comes a bunch of assumptions and some hopes and some wishes and some prayers.

It is not a fully formed, coherent idea that has the solution to all aspects.

We have all kinds of markets in this world, and the -- it is the secondary aspects of those markets, what are the limits and what are the assumptions built into the markets, what are the various mechanisms.

And depending upon what it is -- so, frequent, in banking, we have lots and lots of constraints on how banks and financial institutions behave because there have been excesses.

We have a market driven system of banks where they compete with each other, but it's the unspoken part of that that is where all the action is.

So I think it's fine to say we have a market driven. I'm not suggesting that we throw that out.

But that doesn't take us very far. Not only does it not take us far enough, but I don't think it even takes us very far.

>>KURT PRITZ: Vittorio.

>>VITTORIO BERTOLA: I just wanted to say a couple of things very quickly, to reply to some of the registrars.

Well, first of all, market differentiation is good. So I'm really happy. You can have domains for free and maybe not so good service or pay them a lot of money and have great service.

However, there must be a minimal service to ensure that the market remains a market.

And one of the basis of a free market is that you can choose at any time and move from the bad people to the good people. So that's the minimal level you need, actually, for this to be a market and that's a minimal level ICANN has to ensure.

I don't think regulation can prevent a company to go bust or the Titanic to go into the iceberg, but at least it can prevent the captain from keeping you on board if you want to leave.

And about contact information, yes, I am totally fine if registrars want to add contact information for technical issues, but the registrant -- or the certified owner of the name must be the registrant and not the company that registers the domain name.

>>KURT PRITZ: I would like to thank all the panelists. Thank you very much for time. And thank you everybody for staying through this extended session.

By kieren.mccarthy at 2007-04-04 21:46 | Domains | registerfly | login or register to post comments

Public participation site

Navigation

Search

User login

Recent blog posts

Active forum topics

Public forum discussion over RegisterFly

Recent comments

ICANN news

Net coverage