ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>VINT CERF: Good morning, ladies and gentlemen. Welcome back to the first of the public forums that will be held during the course of the week.

First let me say that board members are free to either sit up here on the dais or to sit in the audience during the first portion of this public forum.

There are three topics that we'll cover between now and 1:30. One of them is the president's report, which will be offered by the CEO and president, Paul Twomey.

The second one is a consultation report on the operating plan.

The third one is a discussion about the lessons that we are learning -- I will say we haven't learned them all yet -- with regard to the RegisterFly situation. That's a more active discussion, and so as we move into that RegisterFly discussion, I'll ask the board members to join me on the dais and ask the members, participants, to be prepared to share their views and experience with registrant risks associated with registrar failures.

So let me ask Paul Twomey to begin this morning with his president's report. And we'll go on from there.

Paul.

>>PAUL TWOMEY: Thank you, Vint. Just while I'm getting the machine connected, can I say welcome again to everybody. And it's marvelous to see so many people here, nearly 900 people registered.

That's better -- there we go. Even the technology works.

>>VINT CERF: It's not up on the screen yet, Paul.

>>PAUL TWOMEY: No.

>>VINT CERF: My first thought is that the projector may not be tuned to the correct inputs.

>>PAUL TWOMEY: While we're getting that sorted, why don't I at least tell you what I'm going to talk about.

First of all, we've reorganized, after community feedback, the structure of the meetings, including reorganized when the public sessions take place and what the input is. So we have a public session at the beginning of the meeting. We have another one again on Thursday. So this is going to focus basically on three topics. One is the president's report, which I'd agree is going to be the stuff that's happening during the week.

The second one is going to be a much more consultation process around the operating plan.

And the third one is the beginning of a consultation process around the registrar accreditation agreement issues and the RegisterFly issue.

Good. Thank you word to our sponsors.

So if I may just move on, chairman, there's probably a number of things that I would like to talk to this morning and report to you and the community.

One is on the strategic plan and the operating plan. Secondly, on policy development activities that are taking place this week. I want to talk a little bit about ongoing improvements in the IANA function to report to the community.

Report continuous work on ccTLD framework, accountability frameworks. Give a small introduction to the registrar accreditation policy and process review.

Give you some more indications of what's happening with IDNs.

Also some reporting on accountability/transparency initiatives. Progress in the RALOs.

Point you to the work of the President's Strategy Committee and finish by reminding those of you who have not seen it yet that we are going to be for the first time hosting a visit by the new secretary-general of the International Telecommunications Union on Friday, Hamadoun Toure, which I think is a very significant event both in the history of ICANN but also in the history of the Internet governance discussions of the last five or six years.

The strategic plan was approved by the board in Sao Paulo in December 2006, following our six-month consultation cycle. Its objectives were organizational excellence in operations, organizational excellence in policy development, increased international participation in ICANN and the use of the Internet system of unique identifiers, increased participation in and efficiency of the ICANN multistakeholder environment, and work towards a post-MOU ICANN.

So they are the main headings that the community pointed out were the things they wanted in the strategic plan. It's some change from the previous year but not surprisingly some commonalities.

The operating plan, as you will recall, is then to follow that on in the next six-month cycle. It is to be updated and revised based on that community feedback during and after this Lisbon meeting. The first sort of presentation format will be straight after my report here.

The budget is to be approved at the Puerto Rico meeting in June. So the operating plan will be discussed. There will come a time when that is finalized, the budget is then formalized around that and goes to the Puerto Rico meeting.

So we have a planning cycle, which is strategic planning for the first six months, operating planning, then, for the next three, four months, and then budgeting behind that. That's how the 12-month process works.

I move to -- that's an important part and we definitely want community participation and feedback and reaction to that. And exhort you to look at that and make certain that your part of ICANN is doing what you want it to do.

In policy development activities, there's been more work on CC accountabilities. I'll come to that shortly.

Many of you know, so I'm just going to point to that there's more work on WHOIS, on the generic top-level domain discussions, and the triple X decision is due to be made by the board this week.

What I would particularly like to draw your attention to, though, is a new feature that we introduced in Sao Paulo in the Web site, certainly in the case at this time, and I -- will be in the case for all future meetings, is that in the agenda, in the schedule and agenda for a meeting, we are putting in for each of the sessions a where it's there, why it's important and who should participate. So I would strongly recommend if are you sitting there with your laptops open that you go and look at the schedule and the agenda for this week. And each of those will have a little blue underlined agenda section. Click on that and have a look at who's going to be there, why it's important to be there at that particular meeting, and who should attend. Because that'll give you good guidance for the week as to which meetings you think you should go to, which meetings you don't need to go to, if you like.

So, again, it's in the bottom there. If you just simply go to the ICANN Web site and click on the Lisboa logo, and that Lisboa logo will have this thing which is called schedule and agenda. If you click on schedule and agenda and look at every agenda item, you will see on the right-hand side a link -- I'm getting lots of nods, people saying it's there. Good -- which says, here's how you find what's on at each session. So rather than my going through the details of each of these groups that you're all involved in, I'd exhort you to look at that space.

Just moving to IANA. There is continuing improvement in IANA's functions. There was quite a meeting at the IETF meeting in Prague on parameters that ICANN -- the IANA supports for the IETF community. I won't talk to that data here. Rather, I'll talk particularly to root management. And I thank David Conrad and Barbara Roseman and their team for putting these materials for me together.

This is some indication of the number of tickets for root management requests since March 2005 through to February 2007. So it's a two-year period. And as you can see, the trend line is basically satisfying. It's improved, so that we now have a situation where most tickets are done within -- I think it's within seven days.

So you can see the basic trend there. This data will be available for people to look at more clearly. Red in this chart means more than 30 days. Green in this chart is 0 to 7 days. And yellow is between 8 and 30. So you can see the gradual change in the ticket numbers.

In terms of the number of requests, the key number is to look at the red line. That's the queue, the outstanding queue. And you can see, again, the outstanding queue is now coming down to match the actual request coming in. So that's, again, a much improved convergence over the two-year period.

And in terms of maximum times for processing, the blue line being the maximum time for processing, for anything that's in the queue, you can see the maximums are now coming down to quite close to the means.

So, basically, that's a reporting on the work going on in root management. There are others -- other activities, of course, for the IANA. But as I said, there was quite a report to the IETF community last week, so I'll leave that part on the record.

It is 12 months since ICANN posted accountability framework template documents. Since then, we have done 19 agreements, eight exchange of letters, and 11 accountability frameworks, the most recent -- and that's actually since Sao Paulo. We've done 19 since Sao Paulo. So that's an accelerating process in the CC community. We signed dot LY yesterday with Libya. And those of you who have followed these issues, it's particularly gratifying to have the dot LY accountability framework signed, if you know the full history of the dot LY TLD for the last four or five, six, seven years.

We anticipate to sign three more during this meeting. Discussions are ongoing with other ccTLDs. I think parties are pleased with progress to date. So we have an accelerating program of, you know, we would have at least, I think, 60% of registrants worldwide covered by an accountability framework with their ccTLD.

The registrar accreditation policy and process clearly needs to be reviewed. I won't talk to that much now because we have a session coming up this morning talking about that.

I would just make the following observation: I'm particularly thankful for those CEOs and others of the registrar -- various registrars and registrar community, who have, both through staff and to me directly, shared their ideas, their concerns, their potential proposals for improvement in trying to ensure that we have a well-operating environment that looks -- that not only rewards and recognizes high quality and integrity from registrars, but also, very importantly, from the ICANN perspective, looks after the interests of registrants.

This public forum meeting will not be the end of the consultation. It's obviously the beginning of a consultation process. And there was a notice from -- in my name earlier this week that -- or late last week that actually also outlined a set of questions on the Web site that we'll be talking to.

The IDN program is -- continues underway. We, in December 2006, completed a series of laboratory testing. And the results of that laboratory testing are available on the Web site. The IETF has also reviewed the protocols that enable additional Unicode characters to be available in IDNs.

There is a very large degree of dependency on the ICANN process on IDNs and the work undertaken by the IETF. And we would like to put on record our thanks to those people who have been heavily involved in that work in the IETF, Patrik Faltstrom, John Klensin, Cary Karp, and others who have really been putting an enormous amount of effort into that work.

There is also input at this meeting both from the GNSO and the ccNSO on policy requests related to IDNs, and they will obviously continue. They've raised issues, and those issues need to be further addressed, I think.

I am still hopeful, I'm hoping that we as a community can keep trying to aim to some sort of deployment or some sort of deployment stage either the end of this year or early next year. I think we do have a tension about, you know, people who have been waiting for this work to be completed, people in parts of the world for whom this is very important. And so I hope we can still keep the various strands together, notwithstanding the dependencies, that we can try to have some sort of movement on introducing these to the root, if not at the end of this year, early next year.

Accountability and transparency initiatives have been a big part of the focus of the board and staff, particularly since Sao Paulo. We have moved to changing the board minutes reporting goals. They are expanded and more detailed reporting. And we have set a target of 72 hours for their being reported to the Web site. I think that's been well received by -- there's lots of nods in the room, so that's good.

We are expecting this week, I think on Wednesday, to release a report by the OneWorldTrust, which we indicated in Sao Paulo was an organization for -- to -- who undertake reviews of transparency for international companies, not-for-profits, and intergovernmental organizations. And that report will come with some recommendations for further improvement. And be made public this week. I can share with you one of its lead statements is that ICANN is in many ways a very transparent organization. It discloses a large quantity of information, probably more than any other global organization.

So we'll see that report this week.

It certainly, I think, comes back saying there's a lot of transparency in ICANN, but it also calls for some further things to be worked on.

The management operating principles, which are an important part, I think, of that transparency and accountability agenda, the community made it clear this process should not be rushed.

We have been waiting for the report from One World Trust to incorporate them into -- their proposals into these initiatives.

The draft principles are in development, we expect to have consultation in place prior to and in preparation for Puerto Rico. So this is parallel rather than serial processing as we wait for the One World Trust to come in.

One of the big efforts we have been spending a lot of staff time on, at least, has been to improve the Web site. And indeed, this morning is the first time the new Web site has become available.

Marc Salvatierra is in the room, I hope. Marc alone is worth all the money people pay to ICANN, and has done an amazing job in the last four or five months. I want to make that public. He has stayed up 16 hours a day, seven days a week for months on end, redoing the work here.

Now, in some respects, it's just a better planned Web site. So I don't want to get carried away with it. But on the other hand, he has also done a great job both in organizational -- informational structure and ensuring links aren't broken and all sorts of things.

Marc is going to briefly take you through the structure of the new Web site after my presentation. But I'm going to particularly ask you to look at a page which is called processes, because that page is actually -- it's still work in progress, we still have some stuff to put in it but that link which is processes is page to which all of ICANN's work is visible.

So you can go there on that web processes and you can see all of ICANN's work, all the work being undertaken in ICANN falling off the one page. So hopefully that will improve thing.

The regional at-large organizations, as you will recall, we had the Latin America-Caribbean RALO launched in Sao Paulo.

The public comment has been open in March for two additional RALOs, the Africa one and the Asia Australia Pacific RALO. We expecting to sign these MOUs this week. So that, again, is further great progress, I think.

There was the formation in Vancouver of a President's Strategy Committee dedicated to giving further input and ideas to the ICANN strategic planning processes and the board and the community.

This committee in its first combination has delivered a draft report after public consultation and an international town hall last week, last year. It had further consultation and another international town hall type meeting in the last several weeks. And it's final recommendations are now presently drafted and are now posted. And there will be a session about those recommendations for discussion, again later this week.

So to finish up, as I pointed out before, the secretary-general of the International Telecommunications Union, Hamadoun Toure from Mali is going to attend our meeting on Friday. We are lucky to have a public session with him prior to the ICANN board meeting.

Because of the interesting, exciting nature of the agenda for this meeting on Friday, I would hope members of the community would actually stay longer than they often do for the board meetings on fries, and particularly if members of the community were able to come like we did this morning to a 9:00 type session with the secretary-general, I think that would be very important and very well received.

It is the first time an ITU secretary-general has attended an ICANN meeting, or shown any interest in doing so.

And I have to say that Hamadoun has been in both public and private conversation very engaging and has made it quite clear in public statements, and I have a link there to a Reuters article which actually reports him saying some of this, he has made it quite clear that his focus is on development and on security and that he does not see much benefit in continuing the Internet governance discussions or heat or whatever the word you want to use that we have seen in previous years. And we're looking forward to talking to him, we're looking forward to hearing his objectives, and we certainly think, I think, that the ITU and ICANN are organizations, along with other organizations, that have a role in Internet governance, and should have much better working relationships and be able to cooperate much more than we have been able to do in the past.

So I think this is a very important initiative, and I hope you are able to support it, certainly by attending on Friday morning.

Chairman, that's the end of my report. And perhaps if there are any questions, we could take those while Marc is just quickly putting his Web site or looking after the Web site.

>>VINT CERF: Very good. Thank you so much, Paul. If there are questions about the president's report, we could take them from the floor now. And we'll have Marc get set up to give you a brief tour of the new Web site.

While Marc is getting himself connected up, let me just observe that those of you who built Web sites will know that there are many different ways to do so. Some of them are less flexible than others. And the previous implementation of the ICANN Web site was relatively inflexible and difficult to update.

My understanding is that Mark's reimplementation of it changes that pretty dramatically.

I hope the consequence of that will be an ease with which new information can be posted in a timely way.

So I gather that there aren't any questions yet for Paul, so we'll just proceed now that we've got the Web site up on the display.

So Marc, please go ahead.

>>MARC SALVATIERRA: Thank you very much, Vint. I can tell you it's been a great pleasure to work with the ICANN Web site. We undertook an effort to clean up, reform, evolve the ICANN Web site as part of the more broad effort to make ICANN more transparent.

If you will remember from the old Web site, a lot of users had complained that they found information simply hard to find. They found the interface unnavigable.

We knew we wanted to be transparent. We knew we needed to think about the way we presented information to users.

There's a fancy term for that which is information architecture. You can call it what you want, but we knew we needed to make it more accessible.

So you'll see now up at the top the results of that thinking.

We've created what are termed silos. You can see now we've got a home page, about ICANN, news, topics, meetings, structure, processes, which Paul referred to earlier, resources, documents, which are highly sought after because ICANN does generate a lot of documentation, and also importantly, a contact link because you can't be transparent unless people can contact you.

So I'll just go in and briefly show you some of the features that you may have found lacking on the previous site.

When you navigate through this new top navigation, you'll find that it stays with you throughout your entire journey through the site. It's what we call persistent.

If you were looking for information about registries, you would go into resources, you arrive at a landing page. There you will find the various resources we offer presently for various groups, mainly registrants, some for registries, ccTLD managers.

That's not to say that we can't quickly develop other content for other user bases. These are the ones that were on the existing site so we carried them over.

As a quick aside, one point I want to make is we haven't broken a single link in reforming the site for you. Every page we had before, we keep in place so if you have it book marked, don't worry, it will stay there.

If for some reason you are having a difficulty, you can let us know, you can e-mail webmaster@icann.org.

To take you through the site, as you navigate through you will notice on the left-hand side you get additional navigation options. That's something that was sort of haphazard on the former site.

You will see what are called bread crumbs on the upper left, comes from the Hansel and Gretel fairy tale to allow you to find your way back home.

That's what they are called.

If you were to go down three or four levels into deep into the site, the bread crumbs start to add up. So right now we are at the registry services evaluation process landing page.

On the left you see all the options that are immediately available to you for that particular area.

So this did require a lot of thought and kind of coordination to go through what was pretty much just a pile of 12,000 pages or so sitting around, and then to get them all typed together like this.

You'll also notice up at the top, the very top, a few iterations of the site back, there was a feature known as the quick links. And once upon a time they were taken away, and the complaints came in for a long time. And so I decided, well, it would be nice to have these back.

So you'll see them in the middle, and basically by pulling down, you can go to any of almost every conceivable subject area you would want to find on the site.

I won't babble on for too long but to tie this all together, the idea here was to give you the sort of conventions you would find on any other conventional Web site out on the Internet.

A top NAV, a left NAV, a site map, which is a new feature that was not on the old site.

Here, if -- We were concerned that by taking a lot of material off the home page, people would say, hey, I used to come and find a particular link through the home page all the time.

So the site map really addresses that because you do get a quick overview of anything you would want to find on the site.

Similarly, the site index gives you an alphabetical rundown of pretty much any item you would want to find. And there are cross links in case there are differences of agreement over what something is actually called.

And then failing all that, we've obviously retained site search.

So you have a number of different ways to find whatever you might be looking for on the site.

In terms of the roll-out of this, look for it soon. Within the next 24 hours, ideally this afternoon.

But I just wanted to give you that quick overview of what we have been doing.

We did consult with the community as much as possible. We gave it a lot of thought internally, and we hope you will be pleased with the result and find it useful.

>>VINT CERF: Marc, could you show them the processes page?

>>MARC SALVATIERRA: Oh, yes.

>>VINT CERF: I know Paul was particularly enthusiastic about that, so others might appreciate that.

>>MARC SALVATIERRA: Right, the processes page is what almost set the top NAV over the edge but we managed to squeeze it in.

When you go to the processes page what you will find is a quick overview of the major work that ICANN has going on at any one moment.

And all the major units of ICANN activity are covered here, board, GAC, ccNSO.

Clicking into, for example, the GNSO, you can get an overview of what their current policy issues are. And you can goes see whatever the current status is of, say, a PDP on WHOIS services. You can see here the arrow indicates, well, that particular sequence is at the status of the final report. Down at the bottom, the contractual conditions is in the process of report posting.

So that's to provide you a quick way to get a fast update on the status of a particular process.

Also, if I can get back up here, at the bottom of the processes page, you can see that ICANN has quite a lot of work going on.

What we've done is add a time line that you can manipulate with your cursor. Basically, each blue line you have here is an ongoing process or some sort of process underway, a project, an item of work. And there's quite a few of them.

The idea of the time line is to be able to show you this is what's going on, these are the milestones, this is when they commenced, this is when you can expect them to finish. And along the way, you will find other incidental items such as the co-op agreement expiration, other items like that.

But the idea is if you have any interest in seeing a current snapshot of processes, you will want to go to this page.

>>VINT CERF: I'd actually like to invite questions, if there are any. I have one. Having -- This is a phenomenal piece of work, Marc.

>>MARC SALVATIERRA: Thanks.

>>VINT CERF: My first reaction is maintaining it and keeping it up-to-date, especially with some timeliness to keep track of the state of various projects, it sounds like it's quite a big task.

Is this requiring to you personally do every update? Or is there some mechanism by which someone responsible for a given process is able to update the current state?

>>MARC SALVATIERRA: The linkages and communications all remain human.

In other words, it's up to us in ICANN to communicate with each other and with the public to know what's going on, to reflect that on the Web site.

And mechanically, also, the Web site is maintained in the collection of thousands of static files. So you are talking about human knowledge tying this all together. And there are miscommunications along the way. But as we go forward, it will be easier to tie this in technologically to a way to keep it maintained more efficiently.

>>VINT CERF: All right. I would think that in order to have accurate information you will want easy mechanisms for keeping track of what's actually going on.

There is a huge amount of material that you have compiled but if it's not kept up-to-date, it will become stale and something I know you do not want to have happen.

Are there any questions for Marc at this point? If not -- yes, I see applause over here, and I agree.

[ Applause ]

>>VINT CERF: Susan, we will get you a great big cue card that says "applause," so if you can help us do that at the right time, we would appreciate it.

Well, the next topic of conversation has to do with the consultations on the operating plan.

I'm sorry, there was a question from Alejandro.

>>ALEJANDRO PISANTY: Paul, can you provide a bit more detail or ask for appropriate staff to provide a very quick briefing on the work on IDNs that is pending before the 2007-2008 deadline you mentioned for bringing in TLDs into the root?

This would be for the benefit of the general community which is reviewing at this meeting for this purpose.

>>PAUL TWOMEY: Can I suggest that I take that on notice and I give you an answer after the consultation on the operating plan? So I just want to consult with a few staff members to get the right answer for you.

>>VINT CERF: Okay.

How do we want to do with the operating plan? Is Kurt going to be making a presentation?

So now we have to figure out how to connect the dongle up to the cable.

>>KURT PRITZ: Mr. Chairman, is it okay if I present from down here?

>>VINT CERF: Absolutely. If anybody makes a wireless projection unit, we should consider investing in one.

>>KURT PRITZ: Thank you.

For those of you looking at your computer, and if you haven't had an opportunity to read the operating plan, you can do so while I give my talk. So the link is easily available from the ICANN front page, a couple stories down, or that's the link there, you can bring it up.

So this is a familiar graph for us.

I remember the particular pain we went through giving birth to the first strategic plan, and there were several iterations of it through several ICANN meetings, and now it seems that we have developed this six-month strategic plan, six-month operating plan cycle, that it's strategic plan/operating plan, strategic plan/operating plan.

So we have developed some success in conducting community consultations and providing plans and iterating them and taking into account public comment.

I want to go into briefly what the go-forward plan is for taking this draft operating plan and finalizing it.

So this plan that's been published about a week ago is here for public comment.

As you know, the operating plan is the one-year action plan for accomplishing the objectives set out in the three-year strategic plan.

We plan to do community consultation here. Patrick Sharry is conducting consultations in several different languages, so that's exciting for us.

When we think the consultation process is done, we will finalize the operating plan. At that point, we will cost it out and that will essentially become the ICANN expense budget for the year. That expense budget will then be presented to the community for some iteration and then to the board for approval at the Lisbon meeting.

So that's as we've done it in the past. This presentation is sort of bifurcated so the first part will be to describe changes to our operating planning cycle and methodology that we have undertaken to improve the planning this time around. So I would like to go through that and then invite comments on that part of it.

And then sort of a brief discussion on the content of the plan and some of the work ICANN has undertaken in fiscal year 2007-2008.

And then if there are any comments on that, we'll take that, too.

This is our planning calendar for the year. So you see we're right about toward the end of March at the Lisbon consultations. The operating plan is developed through input we have received from the community and the strategic planning process and other operating planning processes, and the staff managers consult with their staff to develop work for the year. And I'm going to go into more detail there, how that's done, in a minute. And that's the remainder of the calendar. And the one constant on that calendar is always May 17th which is the bylaw requirement for posting the proposed budget.

So to give you some background, remember last year's operating plan. Not so long ago, we advertised that with -- or gave birth to it with great fanfare as a significant improvement over the way things had been done in the past.

Again, we're taking advantage of experience and pause for reflection to build in additional improvements.

So, for example, last year's operating plan was described in a series of projects that ICANN was undertaking, and each project could be individually budgeted and managed to a set of outcomes that was also published as part of the plan. It was independent of the day-to-day work.

Each project for the first time was linked affirmatively to the strategic plan, and as I said, we defined budgets and outcomes for each project.

So upon reflection, we've refined that process somewhat. So instead of organizing the strategic plan this year -- I'm sorry, the operating plan this year by strategic initiative, we're really organizing it by function or customer.

I think it's more understandable to organize the work that way, especially when various constituencies or community stakeholders are interested in certain aspect of ICANN activity, services or performance.

And one sort of shortcoming with the plan last year is we really focused on our projects. We didn't describe the day-to-day work that ICANN does. So that improving ICANN performance was a significant undertake on our project but the day-to-day effort to process root zone management requests and other work was sort of ignored in the plan.

So there wasn't a one-to-one link between everything ICANN was doing, its work, and the plan, and therefore the budget.

So we wanted to try to capture that this year.

And then that series of projects we described, as it turned out there were over 50 of them, each of which we used -- we've developed project management techniques for monitoring and controlling projects.

We decided there really wasn't -- there really wasn't staff bandwidth to do that.

We also decided that formalized project management techniques were applicable to bigger chunks of work.

So that's where efficiencies were realized.

So we skinnied down the number of projects this year, and what a project definition is.

So in order to create this year's operating plan, we went about it this way.

First, we asked our management staff to work with their people and compile the list of stuff ICANN does.

So ICANN performs a number of activities across the organization.

I've mentioned IANA activities, registry and registrar liaison have a set of customers, contractual compliances is another function, regional outreach has a set of stakeholders where they address their needs.

So to start the plan, we listed essentially what we do every day. And then we want to measure ourselves, so next to every activity, we try to describe a metric by which we would measure ourselves.

So to harp on the same example, root zone management change requests, that's a pretty easy one because it's days to process. Regional liaison outreach activity is a little harder to quantify success, but we thought it was important to have a metric for each activity.

That we described.

And so when we were finished with that exercise, we had a list of things that ICANN does in service to the constituency and the Internet community.

We then looked at that list, and looked at community feedback from past iterations of the strategic plan and operating plan and looked for areas of improvement.

So then our new work for the year, our different work for the year, is either to improve an existing activity or to create a new activity. And that sort of definition is sort of where the projects were in the operating plan this year.

This year we defined it as new work, or if it rose to a certain level of complexity or cost or interfunctional dependency, then we defined a project for it. So then we have sort of divided up our new work for the year in the form of continual improvement activities. So for example, if we want to improve turnaround time 10%, that's sort of a continual improvement, but if we need to make a capital expenditure or have a complex project, then we defined a project.

It's a little bit repetitive, but I'm trying to be clear and I will have examples later.

So conceptually, the operating plan looks like this. For each function we have listed activities and you can see some of the examples there. And each activity, then, not included in this pictorial, but then we had a metric for each activity. And I have sort of already described that.

So you see the operating plan is really in the form of sort of a matrix, and in fact, right now it's published essentially in Microsoft excel, and converted into a document.

And then looking at those activities, we define new works or projects or areas that we wanted to improve. As it says there, add efficiency or responsiveness to our base business.

And then a set of outcomes associated with each one.

So the budget, then, will be defined by maintaining that ongoing business, the activities, and then executing new work or projects that will either improve services or just scale up services to address real needs.

So that's essentially how we went about the planning this year.

I think it's pretty straightforward, but I wanted to pause because it's -- I'll be up here for another 20 minutes or so and I wanted to know if anybody had any comments about the planning process itself rather than the work itself.

So let me describe a little bit more what the planning template looks like.

And if I provide some more detail, maybe you will have a question or maybe you won't.

So this is what the operating plan essentially likes.

In the far left column there is the ICANN function.

So you see IANA is first, and then the IDN program is second.

And so we have listed activities there. So it's kind of hard to see so I'm going to blow it up for you in a second.

And then standards and metrics after that, how we measure ourselves. Existing work might be projects that are ongoing this year that it's carrying over into neck year, so it has to be accounted for.

Then new work next year or a project, and then an estimated cost, and then finally a link to the strategic plan.

So just to flesh that out a little bit.

The first step, as I mentioned, is identifying activities and standards and metrics.

So I have already given you this example of root zone management. That's how we penciled in the first function.

Then we identified existing work. So in the case of root zone management, a carryover project from last year is implementing the root zone management tool, the automated interface, for customers to request IANA services. So that work is ongoing.

We have some new work that's a 10 or 15% improvement in our turnaround time. Talking too much about IANA maybe, but associated with this is the book of IANA, which is, you know, 38-page document about how IANA's going to work to improve its performance this year.

And then in addition to the new work, there is a separable project that completes the implementation of the automated root zone management tool. So that work and goals and outcomes that we're trying to accomplish is listed under those columns there.

And then, finally, for projects, we wanted to estimate a cost early on. And that gives you some sense of sanity of what our projects are. So a project might sound like a really good idea and ICANN should do that and there's community support for it. But if it costs $2 million, then maybe at this stage of the game we want to reconsider that.

So we wanted to take an early look at project cost. And as you read the plan, they are very general. So if additional staff is required, we put incremental staff required. We didn't identify how much then, because at this early stage, the lowest coin of the realm seemed to be about 3rd/10ths or half of an FTE. And that's sort of large. And there's a human tendency to do that. And you add up the projects and get that you need 50 new people.

So, instead, we just identified the need for some incremental staff. But then if there were some outside services such as hardware or consulting services, we tried to quantify that.

And then the strategic plan reference is included after that.

So that's really the conclusion of how we're changing the planning portion, unless somebody has a comment, I'm going to go on and describe some of the work we're going to do in the strategic plan this year.

>> BILL MANNING: I do have a comment, and I can't get to the microphone.

>>KURT PRITZ: You don't need it, Bill.

>>BILL MANNING: Thank you very much, I was thinking about the folks who are remote. So if you could repeat my comments in the mike. I am blind. Can you use something other than a (inaudible) point slide on your fonts?

Anybody (inaudible) the slides? It's just me. The rest of us can't see them.

>>KURT PRITZ: So those -- you know, actually, we came in this morning and tried those screens back there. But are those screens back there not useful, way in the back?

>>BILL MANNING: It's really tiny, tiny-point font.

>>KURT PRITZ: Okay. So I'm not going to do anything. So Bill's comment was that the font in the presentation was too small. So I'm going to take that and not do anything about this presentation, but I'm going to take it back after this workshop and work with the presenters to make sure that the presentations are changed when they can be.

So this slide that some of you can't see demonstrates how ICANN organized the work by customer this year. So I'll -- I don't want to read it, but I'll give you some indication of what it was. What it is.

If you go down -- did you want to say something?

>>BERTRAND DE LA CHAPELLE: Is this working? Yeah.

My name is Bertrand de la Chapelle. I'm the French representative in the GAC. I just have one question.

You made four categories. There was the IANA outreach, international outreach, policy development, and relationships with registrar and registrants.

My question is, who are the customers of the policy development process? And should the word "customer" apply to policy development?

>>KURT PRITZ: Well, I'm not the best expert to answer this question, but I'll take a shot. And then if another ICANN staff wants to -- you want to do it?

Okay. So it's really policy development support. So the first level of customer is really the policy development groups, because we want to support their work. So we think the -- well, it's my slide. But it purports to say that the customer are the volunteers that work to develop policy, and facilitating their work by providing facilities, providing guidance, tools, collaboration tools, travel support. So our immediate customer, we think, is helping those volunteers that work so hard do their job.

The second tier to that question really is something that Bill will never see which is written at the bottom of that slide and says that "Users and registrants are the ultimate customers of," really, "all these functions."

So all that policy development work that the support staff is facilitating and those other groups that you see in ICANN, it's all meant to point at the end goal. You know, the end goal is the accomplishment of ICANN's mission: Security and stability, providing a fora for -- providing fora for multistakeholder participation, providing competition and choice for users.

So sort of a two-tier answer.

I almost got it right.

[ Laughter ]

>>PAUL TWOMEY: You got it completely right. But I just wanted to expand, because I could see where this question is going.

I think.

I've got a board member with a big sign which says, "Please speak slowly."

I shall do so, in English.

In previous experience of my own in government, where we've had -- we've all -- I've been involved several times in processes of reform for government services, where you've talked about -- we've had to go and talk about concepts like "customer" to get a business mentality in the delivery of the service. That's the same sort of approach here. So very -- and at one legal level, very importantly, ICANN doesn't have customers. That's -- In terms of our sort of antitrust structures, we're completely open to everybody to participate. So in that sense, we don't have customers. That's an important point to make so I keep my general counsel happy.

And I think the other aspect of it, to come to the thrust of your question, is that it is absolutely sort of a public good or public benefit being delivered for the broad users, the registrants, at least, if not all the users of the Internet.

But we are, just like governments do, trying to use businesslike language to try to ensure good delivery of service.

>>KURT PRITZ: Okay. Yes.

>> JUDE AUGUSTA: Hi, my name is Jude Augusta. I'm with the Internet Commerce Association. I had a question for ICANN in general, Mr. Twomey, sir.

We're wondering what enforcement procedures there were.

This gentleman from France had a question that I failed to articulate in previous sessions. But while ICANN may not have direct customers, similar to governments, there is accountability.

In government, what we do is, we vote or have a military coup, depending on the country. With ICANN, there are constituents, but we don't have those fiats. I notice in the mission statement -- I don't have it handy -- but some of the top suggestions were open and transparent governance and we're looking for broad participation.

Our argues, the Internet Commerce Association, represents the customers, domain owners, domain buyers, people that the decisions and ideas pontificated by ICANN and participants do radically affect on the level of a significant portion of domain -- of Internet traffic.

We have continuously tried to be part of this process, and we have a lobbyist coming who will be here very shortly. However, aside from spending thousands of dollars to go from the United States to Lisbon, Brazil, et cetera, -- not that those are the worst places to go. I enjoy it quite thoroughly, actually -- we have very limited participation, and we have yet to have a response from ICANN.

The domain owners can't get here. So what I'm wondering is, dovetailing on this gentleman from France's question, how are they included in policy-making if we're not included and we represent them in the significant interest that they control of Internet traffic?

>>VINT CERF: So before you respond to that -- this is Vint Cerf -- I'd like to make at least one observation.

First of all, there is the generic name supporting organization, which has some structure. And it seems to me that you could fit easily into that structure. That's point number one.

Point number two -- at least some of your constituents could.

Point number two is that for the general public, that's what the civil society activity and the RALOs are all about. That's another place where some of the participants in your organization could also have some influence.

I would assume that you would not claim that every user of the Internet is somehow a part of your organization or that every registrant or every domainer, domain holder is a member of your organization. You are one of many possible organizations in which those participants might appear.

But did I misunderstand you to say that you represent all of them?

>> JUDE AUGUSTA: Respectfully, we do --

>> Mike.

>>VINT CERF: Use the microphone so that we can get the transcript, please.

>> JUDE AUGUSTA: To the best of our ability, we do represent the interest of domain owners' rights and interests. Whether or not they know we exist is another story.

We have sponsors from around the world, and we are a relatively new organization. We were announced I believe last November. I have been with this organization only a few short months now.

We have not had exposure to everybody. However, what we want is the intentions of domain owners represented and reflected in the decisions of ICANN and the relative bodies that you spoke of.

Some people, for example, want domains to be considered property rights. Some people want them to be a renewable contract right.

We don't have an opinion on what they are, for example. We just want those intentions to be reflected in policy-making, without a specific agenda.

We have people on our own board that have opposing opinions, companies that are direct competitors on our board, for the gratuity and benevolence of domain owners, whether or not they are aware of our participation in helping them.

>>VINT CERF: So before we go too much deeper along this line, I'm only going to ask whether this is going to be fruitful for the discussion about the operating plan or whether the topic might be better covered in a different part of our public forum sessions.

I'm not suggesting that the points you're making are not relevant at all. In fact, I think we should pursue them. I just don't know whether it gets to the operating plan which is being presented right now.

>> JUDE AUGUSTA: I wondered the same thing, sir. And I think my operation question was, is there an enforcement body to make sure that we are talking about reality and not rhetoric? And that's what we were looking for.

>>VINT CERF: In fact, that's the next topic of discussion. Because what we've encountered, as I'm sure you're well aware, is that there are not fully satisfactory elements in our ability to, let's say, discipline abusive behavior in the registrar or registry community. And it's not going to be easy to find mechanisms to do that, because the parties who will be affected have to agree somehow to that kind of oversight.

So, in fact, the next discussion after the operating plan touches on some of what you wanted to get at.

>> JUDE AUGUSTA: I agree it's definitely a challenge for ICANN, being a body that is in an international environment, without international enforcement direct capability. We're happy to assist ICANN and participate with those efforts.

>>VINT CERF: How many divisions do you have?

>> JUDE AUGUSTA: Right now we are primarily in a United States-based organization.

>>VINT CERF: I'm sorry. That was a very bad historical reference. And it was a military question, how many divisions do you have?

[ Laughter ]

>>VINT CERF: If we're looking for international enforcement, it takes firepower.

Alex.

>>ALEJANDRO PISANTY: I'm -- to complete your reference, since it has been largely lost, the question is a paraphrase of a question asked, if I may remember well, by Napoleon, asking how many divisions does the Pope have. Being questioned by the Vatican in some of his imperial attacks.

Mr. Law -- I'm sorry. I'm changing your family name -- Augusta, I have been very much engaged since several years ago in the noncommercial construct, the noncommercial users' constituency, and more recently in the GNSO review. And I would feel very confident to assure you that business constituency would surely be the most prepared place within the ICANN structure to make an organization like yours and the members you have described heard. That's the place where commercial interests and domain names are best expressed.

The review that has been undertaken and is underway for the GNSO in general would consider particularly important if you had any evidence of artificial barriers to entry into that community. If there were both commercial and noncommercial domain name owners in your association, which it would seem it's mostly inclined to commercial ones, but if there were noncommercial ones, then you will probably be in the position of applying to membership for both of them. Noncommercial constituency is extremely open in its membership. So I am sure that that will be the maybe slow way, maybe not spectacular way, but a very assured way, very effective way to influence the whole policy. And the enforcement question you have is one that domain name users are more and more inclined to ask, especially after what will be described in the next session.

>> JUDE AUGUSTA: Thank you, sir. We are working with the GNSO as well. Thank you.

>>VINT CERF: Back to Kurt.

>>KURT PRITZ: Kurt continues.

So we have listed our functions here. And ICANN staff, as you can imagine, works together or across continents every day, but function by function, we are focused, essentially, on our own set of customers, and then sort of reconnoiter at the end of the day. So in this slide, we've organized the strategic plan by function, which is essentially the operating plan, rather, by strategic initiative.

So I'm briefly going to describe some of the work each one of these functions is going to do. So this is a little dry.

Either if you've read the operating plan and if you have comments about work that is being undertaken or not undertaken or should be -- or should be highlighted, I would ask you to either bring your memory of that reading here or look at this and perhaps at the end make some comments about the work you think is important, whether it's -- or whether it's here and shouldn't be here.

So certainly in IANA work, many people here are familiar with the sorts of work that are done here. But continuing the tradition that David, Barbara, Kim, and the rest of the staff have brought, there's a continuous improvement sort of initiative for address request processing, root management requests and the associated requests, protocol parameter requests, all managed by days to complete, you see. Better implementation of process maps and procedures. So for getting the right -- the right people in the company that has a global focus to focus on issues appropriately as ICANN scales its activities up, implementing appropriate escalation procedures, continue to improve the statistical reporting. You've seen some of that reporting in Paul's address earlier.

And then, finally, just gaining efficiencies through improving its own administration.

In policy development support work, many of you are familiar with the reviews that are being undertaken for the GNSO, which a report is done, and improvements are being suggested. And then there's upcoming reviews of ALAC, the Nominating Committee, and the board.

Policy development is also undertaking to better inform the policy development process and aid those volunteers by providing the right expertise to educate them on very specific and complex subject matters.

We also want to facilitate volunteer participation by selectively supporting their travel expenses.

And then there's major policy development tasks being undertaken. Now, IDN, not a policy development formally yet, but there's a lot of policy development work being undertaken there.

And then also WHOIS and new gTLDs, this afternoon is the GNSO public forum. So a lot of that policy development work will be described, and the breadth and the depth of it are clearly requiring significant ICANN staff support.

And then, finally, the formation of RALOs, which is a significant success that -- series of successes that are being announced at this meeting.

Global partnerships and the regional liaisons is also an area where ICANN's made dramatic changes over the past year. And so there's -- as with so many of these organizations, if you read the detail of the plan, there's communication out to the communities, and stakeholders, and then receiving information in and synthesizing in a way that's helpful to ICANN and then helpful to the community.

Global partnerships is where in the organization we're also facilitating the President's Strategy Committee work. And that is to determine the form of ICANN as it becomes an independent organization and facilitate the work that needs to be done in order to achieve that independence.

There's significant work described in the plan to facilitate the GAC work, increase participation there and improve effectiveness. And Paul's talk earlier today also describes the success we've had in entering partnerships with ccTLDs in the form of frameworks of accountability.

And then also, we're -- we have engaged in many fora, as you know, and many in this room have participated in those fora on their own and also facilitated ICANN and its work there. And that includes the Internet Governance Forum, the OECD, and ITU work.

In the gTLD environment, we -- the service is working to approve accreditation functions, a topic that we're going to talk about next is the accreditation process and the rules surrounding accreditation. Also it's a service we provide to the outside. So accreditation agreements are applied for and granted or not. Renewals have to be made. And we've -- ICANN's developing online tools to facilitate that process, make it more efficient and cost-effective for ICANN, and more quicker for our customers.

There's also customer service improvement initiatives. ICANN recently implemented the new registry services process, among other processes. So we want to improve the timeliness and turnaround time for that.

We've had significant success conducting regional workshops for registries and registrars in Asia, Europe, and Africa, and so that work will continue.

And there's significant staff support in guiding the policy development process, and also work in data escrow and registry failover. That's another important topic that we'll be talking about next. So those are the sorts of work that are being undertaken by those functions.

We're getting through this.

You can probably appreciate the depth of work being undertaken by the staff in creating an operating plan that's -- you know, as you can see online -- many, many pages long. It's the synthesis of a lot of activities, a lot of metrics, developing new work and projects for the year, and then combining all that and synthesizing it into one coherent document.

So the extensiveness of these slides sort of indicates the order of magnitude, and get to the plan itself.

So for contractual compliance, which is different from registry and registrar liaison, ICANN, as you might imagine, receives complaints from many quarters, and almost every member of the ICANN staff receives complaints. And so there are several reasons for centralizing that function. One is to take advantage of the information to compile statistics to understand the true environment of any serious developing problems or areas we can address in the community. And the other is to provide an effective mechanism for replying to complaints or sending them to the right place if ICANN is not the right place.

Then ICANN recently posted a couple documents regarding the compliance process, the contractual compliance process and how it is becoming proactive. I'd invite you to read that. That lays out a road map for this function.

Part of that is to conduct registry and registrar audits. So we've recently posted an audit schedule for that to determine if ICANN parties are in compliance with agreements.

And then consistently applying standards for that, and for escalating complaints.

Finally, managing communications, both those coming in and those going out.

IDN work was described already earlier today. Once again, there's -- a very important part of the IDN process is managing information in and information out. There's -- all the regions in the world are very active in this area, and coordinating the work that's being done across the globe is a significant effort that needs to be undertaken. In addition to this, there are several projects associated with the IDN program. One is updating technical documents to reflect the way in which IDNs are going to be implemented.

Recently, the project published the results of IDN tests, IDN lab tests that simulated the insertion of IDNs in the root zone. It was successful. That testing is not done, because the next step is to take it out of the lab and determine to what extent IDNs should be inserted into the root before final deployment.

There's significant policy development work that needs to be supported. And then there's -- there's an IDN repository where -- that ICANN manages where different organizations can put -- insert language tables in. So there's an IDN language table repository.

And then, finally, all that work needs to be synthesized, so there's finally a deployment of IDNs in the root zone.

Communications and meetings work. You saw a large part of that already today with the improvement in the ICANN Web site.

But this is all about ICANN transparency and openness, and developing mechanisms that tend to include members of the community, increase participation. And that includes developing online tools, improving the Web site, improving participation at ICANN meetings, the ICANN meetings committee has undertaken a serious initiative to improve the effectiveness of ICANN meetings.

The production of information that can be dispersed to the community. And then, importantly, as ICANN becomes -- the staff is truly global now, with the retention of regional liaisons and the opening of offices in a couple different locations, is managing internal communications so we can provide 24-hour support and have an integrated approach to issues.

Recently, ICANN implemented project management, formalized project management techniques. As an organization grows, it needs more formal mechanisms for managing projects. So we've established an effective but very small project office that manages the ICANN project portfolio. So this will manage the sum of, say, 20 projects that ICANN is managing throughout the year. It's also implemented a formal management and project governance process so that project managers who lack resources have a place to come to get resources, conflicts are resolved, projects are officially approved according to a process. So that project governance is something ICANN implemented, essentially, this year, but is fully staffing next year. And when I say "staffing," again it's a small function.

And this will enable us to provide reporting to the community as to our effectiveness in project management and finishing the projects.

Technical operations is essentially an inward-facing function. But it provides, just like anybody's company here, provides the right amount of technical support for ICANN staff so they can accomplish this job. So it's providing the right tools to people, but doing it in a cost-effective manner, with appropriate, consistent standards across the company, and providing the right amount of backup so that systems are resilient and also have significant uptime.

This also includes root function work, including the deployment of Anycast locations, and making the L-root -- continue to improve L-root resiliency.

Another inward-facing function, really important to me, maybe not as important to you, are HR, security, and finance work. But it's also the stuff that makes ICANN more effective. So it's about managing performance, enabling performance, and measuring ourselves inwardly and providing infrastructure so people can do their jobs in an effective way.

So that was sort of long, but I wanted to give you a sense for the amount of work we're undertaking.

We think this amended process and this amount of work has benefits this year.

The plan, to reiterate, it encompasses all of ICANN work. So it's all the business-as-usual stuff, and then it's the project work, too, and the new work.

So we think the operating plan, as we posted it, fully informs the community better as to what we're trying to undertake this year.

We think we've managed -- we are managing better how we define projects and how we manage them, especially in a way that's scalable to staff so that we can effectively manage them.

But we've maintained the linkage to the strategic plan. And in fact, if you go to the Web site there are two versions of the operating plan. There's one organized by customer, as I said, and there is another kind of turned on its ear that is organized by strategic plan objective. So if you are passionate about that, it's there for you.

This is the very start of the consultations. There's an online comment form associated with the operating plan, so I urge you to put comments in there.

As I said, there will be multi-lingual consultations here. There are constituency meetings where feedback on the plan is welcome.

And then over the next month, we'll finalize the plan and then cost that out, and provide an early version of the budget for community review.

So that's essentially the plan going forward.

And the end of this presentation, so if anybody has any comments about the work we are undertaking, that will be great. Or if not, that will be fine, too.

>>VINT CERF: I think you managed to --

>>KURT PRITZ: Put everybody to sleep.

>>VINT CERF: No, you didn't manage to put everybody to sleep but I think you have convinced everyone that you have a big work plan to proceed with.

So thank you, Kurt, for taking the time to walk us through this process.

I am going to alter the schedule just slightly by putting in two specific items before we get to the RegisterFly discussion.

If Markus Kummer and Demi Getschko happen to be in the room, can I see with a -- there they are.

I would like to invite the two of them to take the microphone and alert you once again to the Internet governance forum meetings which are scheduled to come in October in Rio de Janeiro this year, as a reminder that some of you, perhaps many of you, might wish to participate.

Demi, please, and Markus.

>>DEMI GETSCHKO: Thank you, Vint.

I will take the opportunity to remind you that we will have an important event in November this year and make you aware to reserve your space in your agenda.

It will be -- take place in Brazil in the city of Rio. Brazil will be the host country of this event.

And as a personal testimony, I was in the Athens meeting. It was a very important, very constructive and interesting meeting. A lot of issues that are somewhat complementary to our discussion here will be taking place in the IGF forum.

And then I will stress the invitation to all of you to pay attention to the second version of IGF, and I will let Mr. Markus Kummer, the chair of the event, to make....

>>MARKUS KUMMER: Thank you, Demi. Not the chair, just the secretary.

I am very much looking forward to the meeting in Rio. We already had a planning mission there, and the facilities, I can already say, will be excellent, thanks to our Brazilian host.

You may be interested, maybe, in the planning of the substantive part of the meeting.

We will be -- presumably follow very much the Athens model based on the four broad themes of access, openness, security, and diversity.

There will be room for workshops and other meetings.

We are discussing the possibility of offering a platform to relevant Internet-related organizations, such as ICANN, also the ITU, ISOC, and others, to present their activities so that people who don't have the opportunity to attend all the meetings will have the opportunity to look in and be informed about the activities of various organizations at the IGF meeting. As regards the planning, we are now waiting for a decision by the secretary-general for the preparatory mechanism, and hopefully this decision will be taken soon.

We are envisioning another round of consultations in May, on May 23rd in Geneva, and again, we will be inviting for written contributions and comments for preparing the Rio meeting.

Hopefully, the secretary-general will extend the invitations to the meeting in the coming months, so that people can start their official planning. But together with the Brazilian host, we'll make more details available on our respective Web sites, on the host country Web site and on our own IGF Web site.

And I look forward to seeing many of you in Rio in November.

Thank you.

>>VINT CERF: Thank you very much, Markus.

The next intervention is to introduce you or to remind you about the public participation Web site, which Kieren McCarthy, who is now standing at the lectern, was instrumental in creating and continues to evolve.

So we thought it would be very useful for you to see what that looks like.

And once again, for those of you who are asking how on earth to participate, this is yet another avenue in which to become involved in policy development.

So Kieren, please offer your brief intervention now, thank you.

>>KIEREN McCARTHY: Hello.

Hello, yes, I'm ICANN's new general manager of public participation.

Very, very quickly, I see the job as getting more input, better input, and then making that input count. And a big part of that, or a part of that, is this public participation Web site.

The idea is it will provide up-to-date information on what's going on in the ICANN meetings.

It's mostly for people who physically can't be here. I.E., anywhere on the Internet.

The site will remain there now. There was a test site in Sao Paulo. It will remain now at public.icann.org. So from now on, that's where all the information you require for meetings will be.

It should be fairly self-explanatory. As you see on the right, this is what's going on at the moment, public forum. This is where I am. This is the GNSO public forum going on later. You click on any of them. There is a Web page per meeting, it provides you with what is exactly is going on. Why you should attend, why it's important. Some links to presentations, when we have them. As you can see here, you simply click through to the Webcast, to the audio cast, there's also a chat room. I don't know who is in the chat room at the moment. Oh, I am not logged in.

I'll get to the registering aspect.

The idea is this allows feedback, effectively.

You go, you see the page. People can add comments to the bottom of the page. You can go into the chat room and add comments. And because they are there, the meeting moderators or people within the ICANN staff or people within the room will see what's going on, will hopefully feed that input back into the meeting. This is the idea.

To fully interact with the site, you need to register. It's very simple. On the left-hand side, you may already have an account if you have registered with the meeting. You may need to request a if you password. It should be fairly simple. You just type in your e-mail address. You will get sent an e-mail. You will use that, log into the site, and then you have access to -- you have your own personal blog, you can post comments, interact in the chat room, effectively whatever you need to do.

So I think my time is up. I had five minutes.

So we're looking to improve this as well. This really is just sort of version 1.1. So we really do want feedback. Whatever people think about it, what they think is good, what they think is bad, anything. Please send me an e-mail, Kieren.McCarthy@icann.org. Or put a comment on this site and I will read it and I will improve it for Puerto Rico.

>>VINT CERF: Thank you very much, Kieren. I hope many of these initiatives will meet with the approval of not only those in the room but those who are participating remotely. And it's additional evidence that ICANN, staff especially, are doing what they can to create new opportunities for participation in this process.

So now we move to --

[ Applause ]

>>VINT CERF: Yes, indeed. Applause.

We need to get another sign for Susan.

Thank you.

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.

Vittorio Bertola, Patrick Vande Walle, Kelvin Brown, Jon Nevett, Tim Ruiz, Steve Crocker, Chris Disspain, and Stacy Burnette. So I will introduce you again, but if you could work your way up, that would be great.

>>VINT CERF: Would you like to have them here on the dais?

>>KURT PRITZ: Yes, Mr. Chair.

>>VINT CERF: Let me invite all those names to join us here.

As a reminder, this discussion is intended to go until 1:30, and I don't intend to make any formal breaks. So if you need to leave the room, you should choose to do so on your own.

>>KURT PRITZ: Okay, so we have Vittorio Bertola who is the at-large liaison to the ICANN board. Patrick Vande Walle, who is instrumental in helping form the European RALO. Kelvin Brown, equally instrumental in forming the African RALO. Jon Nevett is the chair of the gTLD registrar constituency. Tim Ruiz is the co chair.

Steve?

>>STEPHEN CROCKER: Hi.

>>KURT PRITZ: Hey, Steve. Steve Crocker, the chair of the SSAC, Chris Disspain, the chair of the ccNSO, and Stacy Burnette, who is ICANN's manager of contractual compliance.

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.

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 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.

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.

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?

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.

>>PAUL TWOMEY: Before everybody goes, one final intervention finishing this morning's business which was a request for an update on IDN process by Alejandro. And Tina Dam is here. So we'll just take two minutes for Tina to give that update and then we will be closing this session.

>>TINA DAM: Thank you, Paul. I will try to be brief. As most of you know it's really difficult for me to talk about IDNs in only two minutes, but we will give it a try.

There's a status report on this topic as well on Thursday. So this will just be sort of a brief overview of what will be more detailed on Thursday.

If you take a look at three core elements for getting us Internationalized Domain Names in the root, there's lots more than three but let's just take a look at the three main ones from my perspective, anyway. There's the technical testing, there's the protocol revision and the IDN policy. And I'm going to speak briefly of each one of them and then we will talk a little bit about time lines.

So the technical testing is to determine whether it's technically safe to insert Internationalized Domain Names top level labels into the root.

The plan for that consists of several layers. One was the laboratory test that was testing the root server and resolver software. And that has been completed. And the result was successful, which also, at least large parts of the technical community expected it to be.

So that means that the software that was used in the laboratory test is capable of handling NS records of Punycode strings that corresponds to internationalized labels.

Then there is different opinions about what should be in the sec phase, across the community, not just the technical community.

Some want full application testing, which can be difficult because you need to determine which applications that would be.

Some wanted the testing to go all the way out to the user interface, and allow testing with registrants and registries and registrars.

Some of this is going further out than ICANN's mandate. For example, there's been suggestions about inserting test labels in the root to figure out what the community that those labels are directed to, which one of them they would like the best.

Some people believe that's domain tasting in the root, and we can't do that.

But in any event, there's lots of different opinions, and I've asked the technical liaisons to the ICANN board for some assistance in sorting out how far do we go in these testing mechanisms.

So that includes Suzanne Woolf who is the board liaison from the RSSAC, the Root Server Advisory Committee, and they met in Prague last week and decided it was okay for ICANN to insert test or production internationalized top-level strings as long as its NS record is in the root. So they are saying, for example, no DNAMES.

On that topic, we are waiting a little bit for the policy development bodies to figure out if they would like to have an aliasing mechanism, and if it is that functionality that they would like to have, then we will go back to the technical community and they are prepared to have some more conversations and analysis around what is the safest method for providing that functionality. DNAME could be one of those.

It also includes Steve Crocker as the chair of the SSAC. And the SSAC has decided to initiate an IDN analysis, if you like, for security and stability issues. Of course, if there's issues that come out of that study that requires some further testing or review or modifications for how IDNs are deployed, that could be something that we need it take up in the technical test projects.

Department of Commerce obviously also have a role in this in terms of I wanted to make sure there's emergency procedures available if something goes wrong as we go towards deployment. And they may have some additional requirements for testing.

So all of that is being worked on.

Second area was the IDN protocol revision, and as I think most of you know, that takes place within the IETF. And not within ICANN.

It's a revision of the protocol that was deployed as a standard in 2003. And we're looking at making some revisions to that.

I'm saying "we" because I'm part of that team, not specifically because I'm ICANN staff but because of the topic.

Then there's IDN policy developments or policy issues that might need to be figured out.

And we have a really large group of IDN policy issues working groups. That's a little bit of a challenge because you need a lot of staff and resources to make sure that these policy groups don't go off in different directions which would leave ICANN with something that could be difficult to implement and work with in terms of processes for deployment.

And this week, we have the IDN workshop on Wednesday, and that is focused on policy only. The intent is to figure out what is the overlapping issues between the policy working groups and to see where they need to work together on solutions as opposed to going in opposite directions.

So that's really brief on a lot of activities that are going on with IDNs.

And Paul, I know Alex, Alejandro asked for how we're going in terms of time line for the year, calendar year of 2007.

I have to be honest that with the dependencies that are in place right now externally, with the different studies and the different works that's going on, it's just not possible for me to give you that time line.

I know that's not a very good answer. It is the truth, however. And when working hard on getting time lines from the different groups that are working so that we can merge all of those into an updated project plan that then will give a deadline for when we will be ready with this deployment efforts.

>>VINT CERF: Thank you very much, Tina. Just to reinforce an observation on the technical side, the IETF is very, very active in trying to recharacterize which of the many, many thousands of characters that are part of the Unicode should be part of the IDN symbol space.

And that's moving ahead, but it's a really, really hard technical challenge to get through all of it at scale and still come back with something that's implementable.

So again, it's very hard to estimate when that will be done. But if it isn't done properly, then the whole thing won't work very well.

So that's just the way it is.

So we're concluding this meeting. My understanding is that the next one is the GNSO, -- sorry.

Yeah, the GNSO public forum for new gTLDs is meeting here at 2:00. And someone must be leading and it isn't me.

[2:07]