President's Report and Discussion of Public Forum
 ICANN Meeting - CAIRO
 Monday, 3 November 2008
 
 >>PAUL TWOMEY:  So can we shift now to the next stage of our agenda, which is the President's Report.
 And we're now ready here.
 So let me proceed.
 The purpose of this report is, to remind everybody, is to set some key agenda, key issues that will be discussed this week, key messages that we deliver once at the beginning of the meeting so they don't get repeated, necessarily, throughout the meeting.
 There are a number of key agenda items this week.  The strategic plan.  The new generic top-level domain program status.  The fast-track process status for IDN ccTLDs.
 I want to talk a little bit in detail about reporting and accountability for ICANN.  DNSsec.  Looking at the improving institutional confidence initiative, some policy development  activities, compliance activities, strategic partnerships, IANA, IPv6 implementation issues, our translation program, and the Business Access Agenda.  And I should do this all reasonably quickly because we are supposed to finish all this within 25 minutes.
 The strategic plan is out in front of you for discussion.  The draft strategic plan for 2008 to 2011.  And there are some key objectives identified by the community to focus on and business issues and reporting.
 Some of them are up there.  I am not going to go through this because this is all available on the Web site and will be posted. But my main message to everybody is please participate in the sessions, please give us your online feedback.
 This is a process we run bottom-up in setting the strategic plan for ICANN over a three-year period.  We want your participation.  There are sessions this week on that.  Please note when they are and please participate, both as organizations but also as individuals.
 As many here know, the new generic top-level domain program status has now moved to the stage where we have the draft documentation in place, what we are calling the Applicant Guidebook, together with the draft RFP, the draft contract, and a series -- I think it's six or eight, explanatory memorandums on key points there.
 I recognize that there's a lot of material produced.  I recognize for some people, they will feel annoyed that it was produced -- released so close to the meeting.  I can only report to you that staff and outside consultants and others have been working 26 hours a day intensely, for months, to try to meet these guidelines and get material presented.
 Let me be clear how we see this material.  We think it is a well thought through, thorough, integrated body of work.
 We do not think it is the end statement.
 So we are here to say here is a well thought through body of work.  We would like to hear your feedback.  We want to get responses, we want to get critiques, we want to get issues brought out, we want issues that still need to be discussed, discussed.
 Not here defending this document as being written in stone.
 But we are keen starting at this meeting and moving forward for at least another 45 days to that sort of engagement, critique, discussion around that as presentation.
 There will be two 45-day public comment periods.  The first one will start on the 24th October.
 I want to go to some key sort of controversial issues here, and just address them quite clearly.
 Let's just talk about the cost, and particularly the evaluation fee.
 Key principle is that there should be no cross-subsidize sayings by existing registrants to the new process.
 The evaluation fee is set to be cost neutral, not to maximize revenue.  And there is a detailed explanatory memorandum on the fee process which outlines three subsets of what makes up the fee.  I ask you to look at that and read it carefully.
 If there are any cost overruns -- in other words, if we find the costs of this round actually are greater than the fee brings in, they will be allocated to future rounds.  We will have to recoup that in future rounds.
 If we have underestimated the costs and we find ourselves with excess fees, this whole fee area will be separately accounted for, separately reported, and you will have full transparency into what fee has been received, the expenditure of those fees.  If there is any cost overruns, we will consult -- cost underruns -- in other words, excess money -- we will come back and consult the community about how that should be spent.
 None of this money is going to my salary or any of the executives salary.  We are not buying a Learjet with any of this money.  I am being extreme but I have actually heard these sorts of rumors.  This is an exercise of increasing the pay of everybody and all this sort of stuff.
 It will be very transparently reported.  It has nothing to do with that.  It has to do with making sure there is no cross-subsidize sayings process by the existing registrants to the new process.  And you will get further reporting on that.
 Protection of rights.  We are very aware of the concerns of rights holders, particularly talking, if I can, from the ICANN staff perspective, in terms of implementation and thinking through the implementation processes.
 We have put forward some proposals in consultation with the intellectual property constituency and others in the documentation.
 We want to hear more practical feedback.
 For instance, we are requiring in the draft that new gTLDs will be required to describe proposed rights protection mechanisms as part of the application process.
 And we particularly refer them to the piece of work done by the intellectual property constituency called "the perfect sunrise" which lays out a series of potential mechanisms which can be used.  So we are requiring people to describe that and we would like to thank the work of the IPC in producing this work.
 One feedback idea I have heard already, which I have put down here, is it might be possible to have a common registry for all rights holders who wish to provide information for sunrise mechanisms.
 So if we have 100 gTLDs who want to use a sunrise mechanism, a rights holder could record their information in one place once and not have to go through the administrative cost of doing it 100 times.
 We want to hear other sorts of ideas like this in this consultation process.
 Resolution of string contention remains something which is not yet finalized and remains up for discussion.
 We think it will be resolved by comparative evaluation process or by negotiation between the contending parties.  And we are specifically proposing a long period for that sort of negotiation.
 Last-resort contention resolution mechanisms have been proposed.  We want to hear your feedback.
 One of them put forward is around auctions, but there are other options.  And we are waiting for feedback on this.  This is not yet a finalized position.  That's a key part for the feedback we want to receive.
 An important piece of work has been done over some time is by CRA International, formally the Charles River Associates, a noted economist group, specifically looking on the relationship between registries and registrars and the structural separation of those two.
 Their report has come in.  It is their report.  It is not an ICANN report.  It is their report.  And it is indicating some special circumstances in which the present registry/registrar separation could be eased.
 The first one is that a registrar could own a registry and operate a registry providing it did not sell that registry string.
 And there's a series of analysis in there in terms of benefits and otherwise for consumers.
 And another one is where there's a single organizational TLD where essentially the customer is the same as the registry.
 An internal company TLD, where their analysis says there may not be benefits to the user, and, indeed, there may be negative benefits to the consumer, internal consumer, of having structural separation.
 We are very keen to get your feedback on CRAI's thinking, see what the responses are to that.  If it is responded well to, generally, then there will be consultations between ICANN staff and constituencies to develop a draft model of how that could be implemented.
 But we are keen to get feedback on this piece of analysis and thinking about some easing on the registry/registrar separation.
 Moving to the IDN ccTLD fast-track process.
 The draft implementation plan was posted on 24th October, and there is public comment period now open.
 The IDNA protocol for internationalized labels is being revised.  And new requirements may be specified.
 There's plenty of workshops this week to talk through this issue.  I would particularly like to thank the work of Janis Karklins and Chris Disspain in particular, but many others, in convening and managing the IDNC working group.
 I would like to thank particularly the work Chris has been doing also in helping to think through some of the business issues and discussions with the leaders of the IDN ccTLD community, what are some of the issues that will be involved in actually ensuring we have an implementation of the fast track.
 Again, there are sessions, there are Web site connections here.  We very much want people's involvement.
 I want to talk quite specifically, as CEO and president about an issue I also get asked about, which is what do you spend the money on.  And it's a great question.  So I want to just remind people and then show some additional things just to give some indication of our commitment to reporting and transparency on this.
 We have a detailed budget process and disclosure process, and there's a link there to that.
 Many members of the community are not aware how detailed that is.  And I would recommend that you go and have a look at how detailed the budget process is.
 About a year ago, we also started implementing a dashboard, which is an online mechanism for looking at some of the mechanical operational aspects of ICANN and its community.
 That dashboard has been substantially expanded just in the last week or so, or it's been further released.  And I am actually going to ask to tab across so you can see this.
 That's probably a little busy, but there are -- off the front page of the ICANN Web site, there's a link and it says "Dashboards."  And the dashboard then gives you information about corporate affairs activities, lots of details about the finance, lots of details concerning global partnerships work, the IANA work, work with registrars, work with registries.
 This particular page in front of you, for instance, is monthly reporting on how many people are subscribing to newsletters and other sort of communications mechanisms we have.  And it's quite fascinating how much after the Paris meeting we had thousands and thousands of people subscribing to newsletters and monthly reports and things.
 We might move to just clicking on the data escrow status.
 And, Minister, you referred to cybersecurity being an important part of all of our agendas.  One of the things that is very high on our resiliency agenda is ensuring that the data held by registrars is held in escrow in case of business failure.  And this is actually reporting now of the total number of registrars, how many now have data escrow with the ICANN process and how many don't.
 And on the right, I think it indicates something like neither 95% of all registrants in the gTLD space are now -- we know are in data escrow.  And there's obviously more work to be done there, and you can see we can track that.
 We also, if I can just take to you the IETF queues, this again is live reporting of all the work that is done for the different queues for the Internet engineering task force management within the IANA functions.
 I am just showing those as sort of examples because I want to exhort people who ask this question, what do these people do and what do they spend the money on, this is one of the ways in which you can actively look at the activity going on.
 If we can toggle back now.
 Further than that is that we actually have developed an operational scorecard which is a summary of ICANN's operating plan with discrete, clearly identifiable deliverables.  It provides an insight into the organizational goals and the progress made on the plan as tied to the ICANN budget.
 It includes several hundred projects and initiatives under it at any time.
 We are going to post this in the dashboard view in the next few weeks, and this will be something updated every three months or so which is actually a summary of all the work done by the ICANN staff and with the community according to the operational plan and what is the status of each of those projects, whether they are on track, whether they have been completed, whether they are on time.
 So that is another form of how people will be able to see how is activity being completed.
 We have also been working, and I want to thank the leadership of the Board Finance Committee, on reviewing our financial reporting approaches, particularly to move much more to functional reporting approach.
 To again, get a better analysis, understanding of where ICANN's money is spent.
 It's going to be previewed here in this meeting, and we expect it to be up as a regular part of our reporting on the dashboard by the end of this calendar year.
 But to give you some indication what it might look like, we might be able to give sample reports, for instance, of -- here we have IANA, security work, compliance work, work being done on meetings, work being done for community support, ombudsman cost, work being done for board support, NomCom support, Lroot, new gTLD project, Internationalized Domain Names, et cetera.
 And we will be able to report both what is the baseline expenditure and what we call initiatives, projects.  And they vary over time.  This would be the budgeting, so we would be able to report both on a monthly basis and also fiscal year-to-date data.
 Many people in the community have been wanting to see this sort of information over time, and the Board Finance Committee has taken leadership and we're going to recast our accounts, and this will be out by the end of the year.
 There are many other transparency and accountability measures being taken.  And I have just got a short list there of what they are.  And again, wasn't to remind people, there are lots of opportunities here for people to actually be able to find information about what's going on in ICANN.  The monthly newsletters, the compliance update.  These are things you can sign up for and receive the information.
 I want to reinforce that we have an annual report process coming out this year and an annual independent financial auditing.
 Let me make one further point about the annual report.  There has been some discussion recently from data which, frankly, was completely inappropriate to analyze about the pay for executives and staff and how does ICANN look at the issues of remunerating executives and staff.  This annual report, we will put out very detailed information on the full process used by the ICANN board for setting the compensation methodology that's used inside ICANN and the whole process that's followed.
 So again, in the annual report that will be out by December, there will be very detailed information on the compensation program and the mechanisms and the facts and the data of that compensation for ICANN staff fully reported by December.
 Moving on from reporting and accountability, one of the key potential technologies to help us address issues like the Kaminsky vulnerability is DNS security protocol.  And on 9 October ICANN released a proposal to sign a root zone file with DNSsec.  The proposal was reviewed by global DNSsec experts and it's been backed by our year-long -- year-plus experience of actually having a signed root zone and widely testing the DNS software vendors and DNSsec community.
 It provides a chain of trust with the DNS.  Very importantly many now know, but DNSsec is not a way of encrypting the DNS.  This is not any sort of encryption for the DNS.  And it is merely about ensuring that people have confidence that the record that was put in the DNS record is actually the record that was put in by that person at that time.
 The Department of Commerce has issued a Notice of Inquiry.  ICANN has put forward a proposal.  Our friends from VeriSign have put forward a proposal.  The Department of Commerce is looking at a Notice of Inquiry process looking for feedback on that.  There will be a workshop on this during the week, and we would exhort people to participate both in the workshop and also to give feedback to the Notice of Inquiry process.
 And again, if I can just -- as the Minister well understands, we need to understand the different cultures here.
 If people have got views, the key thing the inquiry is going to require is that you say them in writing.
 So attending a meeting and saying, "I think this," or think that, is one thing.  You have actually have to write it and send did in so it can be part of the Notice of Inquiry process.
 It calls for ICANN to be operationally ready.  That is our aim.  Our aim is to be operationally ready and work closely with our partners in the Department of Commerce.
 We have been doing a lot of work as you know in improving institutional confidence.  Since February of 2008, we have two rounds of public consultations and we have had seven dedicated meetings worldwide looking at this process.
 Some of the things we have learned through our work here at the President's Strategy Committee is we need to simplify the consultation process and documents.  We need to improve business participation, emphasize the importance of competition, detail issues of accountability and additional legal presence, and clarify improvements in ICANN's operations.
 There will be further discussion about this this week, I think it's either Wednesday or Thursday, and we would ask people to be very much involved in that and help us with it.
 There are a series of policy development process activities being undertaken this week, being discussed, particularly in the GNSO, but elsewhere.
 The GNSO restructuring.  The inter-registry transfer PDP has started.
 A Fast Flux hosing PDP process has started.  WHOIS study recommendations are being reviewed by constituencies.  But as the ICANN blog has recently pointed out, ICANN staff are continuing with studies and analysis and enforcement on WHOIS at the moment.
 And our monthly policy updates are available by subscription, and you can go to the Web site and subscribe to them in Arabic, Chinese, English, French, Russian and Spanish.
 And there is more activity here on compliance activities.
 Let me just point out some few facts for you.
 We received 5,808 complaints in 2007.
 Until August this year we have received 7 aye,479 complaints.  We have 940 registrars under contract.  We have so far this year de-accredited 13 registrars.  And we continue to investigate registrars and we are post that process.  You can continue to see the record of compliance through public postings and particularly through the semi-annual compliance report, and also the compliance newsletter.
 On the partnership program, we have 80 candidates for the fellowship program for this meeting.  28 are attending.  So 28 attending.
 We had 19 presentations and trainings around the world since the last meeting.
 And we now have 44 ccTLD accountability frameworks in place.  Since our last meeting we have signed agreements with Thailand, Costa Rica, Poland, and Cocos and Keeling Islands.
 IANA performance, I think, again, is fully transparent, and people can check it through the link.  What is coming clear is we are getting an increasing number of requests that involve multiple TLDs, particularly where we have hosting requests or change of host requests where there are multiple ccTLDs using those hosts.
 This requires that we have increasing communication burden.
 We require full approval and support from everybody involved before we make a change.  As a consequence, we are increasingly large queue of outstanding requests and requests are taking longer to complete.  But I want to emphasize it's because of the complexity of requests and the number of people whose permissions we have to make certain we achieve before the implementation can take place.
 v6 implementation is a very important issue, and we are moving to provide IPv6 accessible web mail and name servers.  IPv6 address of course has been added to the root servers.
 We are working closely with the NRO and want to do more discussions with the NRO and RIRs on IPv6 deployment, and we are consistently reporting that.  One of the things I have been suggesting to governments, worldwide have asked me on this issue, is that one simple thing would just be to keep a national checklist of the top 3- or 400 Web sites that people visit and the top several hundred ISPs people use in their countries and keep a checklist saying which ones are v6 compliant and which ones are not.
 I think a little bit of sunshine on that process will give us sort of one very cheap thing, one mechanism, at least, to put some window on that process.
 The translation program is now in place.  We've got 650,000 documents translated in -- from 2008 to 2009.
 My final point to remind people is in the business access agenda.  We have a parallel series of events in this meeting, essentially as we did in Paris, focusing on explaining to business leaders the key issues in ICANN's work and giving them access to key discussions.  And there's meetings on Monday, Tuesday, and those are available off the site.  So thank you for that.  I really would emphasize the need for everybody to participate in sessions this week.  Please go to the -- to the agenda.  Please find where those meetings are that are around some of these issues that are important to you.  Please participate strongly.  Thank you very much.
 [ Applause ]
 >>KIEREN McCARTHY:   Hello.  So for those who don't know me, my name is Kieren McCarthy.  I'm the general manager of public participation.  And I want to outline briefly how to participate at this meeting.
 First of all, get up and speak.  Nearly all of the sessions have open Q&A, nearly all the sessions have microphones.  That's mainly how we get your feedback at meetings, to pick up a microphone and say, "This is what we think."
 Someone else may pick up the microphone.  That's the nature of the beast.  If you want to get involved, that's the way to do that.
 Secondly, share your notes.  ICANNWiki has set up a URL.  ICANNWiki.org, slash, type, underscore share, underscore vote.  If you type notes of any meetings that you're in, you can upload it there for that session very simply, very easily.  And in that way, the sessions that you're not in, you'll be able to see the notes of the people that were in it.  The idea is that we share the information, we share the notes that we all take sitting there typing all the time, we share them so other people can see what's happening across the meeting.
 Ask others.  We are a community.  It's a big community.  It's sometimes a community that shares quite a lot of disparate views.  But if you have a question about something, chances are someone in the room will already know the answer or be able to point you in the right direction.  So if you want to participate, just ask other people.  People tend to be very helpful if you just ask.
 And visit the Web site.  Hopefully, people have gotten used to the concept of us having a different meeting Web site each time.  This time, it's at CAI, for Cairo, obviously, dot icann.org.  Anything you want to know about the meeting.  The schedule is there, if you click on the schedule, everything that's happening about that meeting is on the Web site.  So you have the links to the audio feed.  You have links to the videos where we have them.  You have links to the presentations, links to the presenters, everything that you need to know about the meeting.  And there's a few information about Cairo and so on and so forth there.
 Go to CAI.icann.org.  There's also a link, too, on the front of the ICANN site.
 What's new and improved for Cairo.  Well, first of all, the scribe feed, the scribe transcripts.  For those of you who were in Paris, you will remember there at the end, we experimented.  It's taken years to get there.  We experimented with running the scribe feed in a window in an actual browser rather than just having to read the screen or read the transcript afterwards.  We have expanded that.  It worked well.  And now if you go to the Cairo site, you should be able to see a link at the top for when there is a scribe feed.  And it will simply bring it up in a simple window in your browser, and you will be able to view in realtime and on the Internet, hence, anywhere in the world, what appears on this screen on the left-hand side.
 Extra interaction.  Immediately after I get off stage, there's a meeting of the Security and Stability Advisory Committee.  And we're trying something out there where we're using Adobe's Connect software, where in one screen, you will be able to see video of what's going on, the presenters' slides, you'll have a chat room, you'll have audio feed.  Basically, we're trying out a vastly improved method of interacting during a meeting.  So you can log onto that wherever you are, if you go to the Cairo site, and you go to this SSAC meeting you'll see a simple link.  Click that link and that will bring it up.  It's an experiment.  We want you to try it out and tell us whether it worked, whether it was slow, whether it was terrific.  We need the feedback, because if it's good, we'll expand that out to other meetings.  The theory is, if you can't come to a meeting, then you should be able to, as far as possible, interact and participate in that meeting.  So this is the next stage.  We're trying that out.  So please do have a look at that.
 And I am trying a test as well with a chat room particularly for the improving institutional confidence on Thursday, which is a -- it's a different startup chat room, which means you can embed code into whatever site you like and it will all lead to the same chat room.  People have been saying to get into the chat room, I have to find various different links to get to that particular meeting's chat room.  With this one, you can embed your own code wherever you are.  Now, in future, what we'll do is set up the chat rooms and provide that code to whatever wants it.  So the idea will be, if you're particularly interested in say, new gTLDs at the the Mexico City meeting, someone can put that on your blog, "This is the chat room for this."  There will be multiple entry points for the same chat room, which should increase the value and size of participation during the meetings.
 You will see the fellows from domain dot info wandering around with the cameras.  They've -- I have been working quite hard with them.  We're going to have regular videos, hopefully daily videos, just a quick summary about what's happening in the meeting the day before.  And we're going to run them through this dot (inaudible) that enables us to -- (Cross talk on audio).
 >>KIEREN McCARTHY:   In multiple languages as fast as possible.  So that's something we're trying out.
 ICANNWiki does -- most of you, if you have been to ICANN meetings, the last four or five, remember, a daily newsletter, ICANNWiki has taken that newsletter on and they're adding useful stuff to it.  Some -- it's a trial, I think the first one, and you have not seen it, was out this morning.  And they've added stuff -- their own aspects of it, feedback from the community.  They have some polls up on the ICANNWiki site.  And that will be added in.  So the ICANNWiki has taken on the daily newsletter, which should be interesting.  And if you want to give them feedback, their booth is just in the corner out here in the corner just before you hit the stairs, or just after you hit the stairs.
 Go and talk to them there.
 What's quite a big change which should be very interesting this meeting is the joint supporting organization and advisory committee meetings.  There's two this afternoon, and there's a final one on Thursday.  And this is where the chairs, Chris Disspain, the ccNSO, Avri Doria, the GNSO, et cetera, Janis Karklins of the GAC, Cheryl Langdon-Orr of ALAC, will be running what they hope will be very participative meetings with the chairs there.  So it's a slightly different format.  We'll see if that works.  We hope it does.  It should be an opportunity for you to give feedback to the chairs and the chairs give feedback to the room.
 Wish tree, what's new and unusual.  We have a wish tree, which the staff have been mocking me greatly over.  But I know that you're all going to love it and embrace it.  It's on the other side of the stairs by the cyber café.  And the simple idea of the wish tree is that you write on it what is your general expectations of this meeting.  Scribble it on a tag and tie it onto the tree.  And I do a summary at the end of the conference of what people have basically said.  
 The idea is, we want to know, why do you come to these meetings?  What do you want out of this meeting?  Because it's very hard to gather that information in large rooms and on stage.
 So write it in your own time, write it on a tag.  Tie it on the tree.  And we'll review it.
 So do, please, try that out.  I know that Paul Levins is a particular fan of that.
 The public forums this meeting.  Today, this afternoon, there's two of these joint SOAC meetings.  There's a lot of interaction poured into those meetings.  That's effectively -- should be a very useful public forum.  And we have an interesting thing with white boards.  It should be interesting.  It should allow for greater participation.
 And, again, on Thursday in the morning at 8:30, they have another one-hour reporting back session, same sort of thing.
 And then the usual Thursday afternoon, 9:30 to 1:00, we've got the board reports, we have the SO and AC reports, the staff updates, and we'll have speeches, which I'll get to in a minute, followed by public forum, people getting up and asking questions with the board up on the stage.
 So there's two main schedules -- changes and announcements.  One, the joint SO and AC meeting this afternoon, just to make you aware, it was originally said that it would be domain name space, i.e., new gTLDs and IDNs, first of all, and improving institutional confidence afterwards.  That's been switched around, just so you know, the improving institutional confidence discussion will start at 2:00 and will continue for maybe an hour, and then it will switch into the new gTLDs and IDNs.
 So there will be a coffee break called when the room starts getting tired, I expect, by Patrick Sharry or Chris Disspain.  
 And on Thursday -- I'm not sure whether Paul announced this -- Dr. Hamadoun Toure, the secretary-general of the ITU, will be visiting and give a speech, as well as Meredith Atwell-Baker, who is the deputy assistant secretary at the NTIA.  She'll be visiting here on Thursday, just so you're aware of that, on Thursday, there will be speeches by both of them.  And tonight -- I don't know whether you're aware, there's a welcome reception tonight.  Dr. Kamel, who was -- who sat here earlier, has invited you all to Baron's Palace.  You can see it there.  Apparently, it's a very intriguing place.  You can see from the architecture, there's the -- according to legend, it was placed on a turnstile so you could turn it around so that the windows would always face the sun.  I'm not sure how true that is.  You can find out.  You can try and push it after you've had a few drinks, no doubt after a few coffees.  
 So there will be shuttle service from this hotel starting at 7:00 p.m.  And there will be buses back to all the official hotels in the evening, starting at 10:00 p.m.  That's just to tell you about tonight's reception.
 And then, of course, the gala, which I'm told is a very interesting spot, so you get to see all the pyramids.  And it should be stunning.  We have a live show, we have food.  I'm told it's going to be a terrific evening.  It is formal dress, I understand.  That means cocktail or formal dress, some smart clothing.  And again, it's the same system.  There will be a shuttle service from this hotel at 7:00 p.m., and then there will be return shuttles to each of the official hotels.
 So there you go.  That's my part.  I hope you all enjoy Cairo.  I hope you all participate.  I hope you all check out the Web site.  And I hope you all try these new systems.  And if they work or they don't work or you have new ideas, I'm here.  And if you see me running around, please just grab me and tell me what you think.
 So thank you very much.
 [ Applause ]
 >>KURT PRITZ:   Hi.  I'm Kurt Pritz.  And I'm going to give the next presentation.  It's about new gTLDs and the applicant guidebook that's recently been posted.
 So I wonder if everybody in the back can hear me okay.  I know there's a lot of conversations going on and the door is open.  So if you need to transact business, that's completely understandable.  You can do that outside.  And then we'll start the presentation here.
 So this is intended for those that might wish to apply for a new top-level domain, either in this upcoming round or in subsequent rounds, or those that are interested in the process and want to learn more about it.
 Paul Twomey just described in some detail the work that's been done on new gTLDs.
 This presentation, in particular, is going to talk about the applicant guidebook itself.  So how you can find things about the application process in that guidebook.  It's kind of to show you around, as Paul intimated.  There's a couple hundred pages' worth of material there, plus accompanying memos and supporting materials.
 So I wanted to take advantage of some of your time to provide some detail there.
 So what we're going to talk about today, then, is an overview of the guidebook and some of the supporting and explanatory materials that are in there.
 And then I'm going to go into the guidebook detail a little bit to show you where some things are so you can find them he'll and then some probably timelines for how this new gTLD process is going to roll out.
 So what was published, essentially, is the guidebook.  The guidebook we used to call the RFP or the request for proposals.  It's a request to those who wish to apply for a new top-level domain.  There's been many presentations given over the years, the last three or four years, about this process and the development of it.  There's currently 21 generic top-level domains in the root zone.  This process is intended to open that up and create opportunities for more top-level domains.
 The supporting memoranda are intended to annotate the guidebook.  So the guidebook is, essentially, a set of directions for applying for a new top-level domain.  The explanatory memoranda describe the thinking, the development that went into the processes and procedures that are there.
 There's also some other supporting information that I'll describe to you.
 As Paul discussed, and I'm going to say in the next slide, this guidebook is a draft version.  It's intended for public comment.  It's intended for amendment.  And we'll take a look at the comment forum there.
 And there's also some background material with some key messages in it.
 So what are the key messages?  And what are the key themes associated with this whole round of applying for new TLDs and opening up the domain space in this way, which will be quite a remarkable change to the domain name system?
 Well, first, new gTLDs, new top-level domains, are intended to enhance competition and choice for users of the Internet.  This was envisioned in ICANN's founding documents and has carried through with considerable effort, as I'll describe in a minute.
 There's -- it's being implemented, especially in this first round, with principles of conservatism in mind, both technical conservatism, in order to ensure the ongoing security and stability of the domain name system, and also we want to have a measured approach for how new TLDs are introduced, at least in this first round in the DNS.
 And certainly the ICANN community, the Internet community, and ICANN staff will learn quite a bit in this first round.  And we expect policies and procedures to become more liberal in the future.
 There's a strong, strong emphasis in this process on registrant protection.  Applicants that devote significant resources and efforts toward registrant protection will be rewarded in the application evaluation process.
 So this decision to launch new top-level domains has followed a detailed and lengthy process.
 As I just said, in the founding of ICANN ten years ago, in the hearings that took place when the papers were written, they focused on DNS stability and security, but also on promoting competition in the domain name system.  And the first steps in competition, as you know, were taking place in opening up the registrar system.  Where there once was one registrar, now there's over 900.
 But also discussed at the at the same time was consideration of top-level domains.  And considerable work has been done since the founding of ICANN with this mission in mind.  There were trial rounds of new top-level domains in 2000 and 2003, where 14 new top-level domains were introduced.  And then ICANN undertook an intensive policy development process, conducted by ICANN's supporting organizations and advisory committees, that took place over a period of about two years and so much of ICANN volunteers' time to provide 19 succinct yet detailed policy recommendations to guide how new top-level domains will be introduced.  
 So this effort isn't a new initiative, but, rather, it's the next step -- it's sort of a culmination, but, really, a next step in ongoing work that's been undertaken since ICANN's inception.
 Also, as I said a minute ago, it's fully intended for public comment and amendment.  We think the final draft, the final version of this guidebook will be considerably different than the one you see.
 Almost all the issues in the guidebook have been discussed in the Internet community on a single basis.  But this is the first opportunity we have to look at the Gestalt, the whole thing together as a package, where different aspects of the process and procedures can be contrasted and compared.  And so we think that's going to inspire a lot of discussion and take it out of the realm of a number of people working on it in ICANN in coordination with its policy-making bodies and really open up the discussion across the community.  And that will provide new viewpoints and insights that will allow us to continue to improve what the draft process is so far.
 So there's two -- as you look at a couple hundred pages of guidebook and associated memoranda and all that other stuff, your mind can boggle.  But at the heart of it, really, there's two aspects of it.  In most cases, for most applicants, it will be an uncomplicated process.  There's a six-step inquiry that we will review in a second where most of the applications can be processed and considered evaluated in a straightforward way in a reasonable period of time, using objective criteria.
 But besides being uncomplicated, the process also needs to be robust when it has to be.  So it's anticipated there might be applications or applicants that apply for strings that are controversial in some way or may infringe rights of others or may affect other very important interests.  And in those cases, the process needs to be robust to provide a path for considering what might be objections to top-level domain labels or top-level domain services that can be considered as part of the process, so we don't need to go outside the process in order to consider them.
 So straightforward in most cases, and uncomplicated, but robust.
 The guidebook itself is divided into modules.  There's actually six modules.  But the modules, essentially, following the evaluation path, the path that applicants will go through when their top-level domain application is evaluated.
 So Module 1 describes the process overall and then also the requirements for an application period.
 The second module is the initial evaluation.  That's that six-step process or evaluation process I just talked about.
 We think that most applications will go through that process and pass and then go to the transition to delegation and be delegated as a top-level domain.
 But the other modules address those areas where an application might require extended or more complex evaluation for a variety of reasons that we'll talk about in a second, or whether there are objections to the application for very limited -- on very limited grounds, or where there's string contention, where there's two identical applicants, not identical applicants, but the string they're applying for is identical.  And that contention between the two strings needs to be resolved before we can go on.
 So the other modules address those areas of complexity in the process.
 So, for those of you who want a slightly larger font to describe that, this is sort of a textual description of each one of those modules.
 There's a sixth module.  That's the terms and conditions that are agreed to by the applicant and ICANN as we embark on this process together.
 In addition to the --  In addition to the guidebook and the modules, which are the directions for how to apply for a new top-level domain, there's a set of explanatory memoranda that are intended to accompany the guidebook and explain, as I said before, the reasoning or the thought or the development process that occurred in order to arrive at this particular set of directions.  As you kind of imagine, there are a lot of decisions to be made in considering the policy recommendations of the GNSO and turning that into an implementation plan.  Those memoranda are intended to explain how those decisions were made and how the final product really maps into the GNSO recommendations.  And part of what we're going to talk about as we discuss the applicant guidebook and the details of it are how they map to the individual policy recommendations that are really driving this whole effort.
 So those explanatory memos are listed here. 
 Resolving string contention is about if you get two identical strings that are applied for, and how contention sets are identified and resolved.
 Cross considerations describe how the program is costed out, the development costs of the program, the operational costs of the program, the risks of the program and how they were costed out, and then how those costs are passed on to the applicant in the form of a processing fee and how they're mapped over there.
 There's a memo that describes how geographic place names will be considered as a subset to all the names.  There's an update to the DNS stability paper, so that a string in itself should not affect the functionality of the domain name system, the stability and security of the domain name system in every way.  That paper describes the clear criteria, we think, that the string must comply with in order to make sure that those bad effects don't happen.
 Paul Twomey talked at some length about protection of rights of others.  And there's a paper in there describing some of the background, how considerations for those rights, protections, are considered in the process, and how the evaluation process measures and rewards applicants who include rights protection mechanisms in their proposal and how rights protection mechanisms are in fact required in proposals for a new top-level domain.
 There's a separate paper on morality and public order objections to certain strings, the reasoning and work that went on in order to develop potential standards and standing requirements for making objections based on those grounds.  Those potential standards are given in that report and are intended for public discussion so we can arrive at a final set of standards.  So I think they're fairly well laid out in there.  And also included in this proposal is the base agreement that new top-level domain registries will be asked to sign.  And there's a memo in there that describes the changes, how the agreement has morphed into a more streamlined agreement in this case.
 So those are them.
 There's also some related resources.  There's a summary of the GNSO policy recommendations.  There's a mapping, a cross reference or mapping of the policy recommendations to what's in the guidebook to show how it all ties.  And I'm going to show you a part of that here.
 There's a version of a preproduction algorithm that will assign scores to TLD strings that are applied for so that that result can be used by those who would judge if strings are so similar that they would cause user confusion.  So an algorithm's been developed, a preproduction version of it is available in three scripts currently:  Cyrillic, Greek, and Latin.  There's an interactive process flow that we may touch upon later.  And then there's an anticipated timeline for continuing the process.
 So for those of you in the first row, this is intended -- some of these are intended just to pique your interest and look on the Web site.  But there's a map posted of the entire posting of the applicant guidebook and all of its associated documentation and how they link.  The guidebook's on the left and the memoranda and associated materials on the right.
 For those of you in the first ten or 15 rows, that blows it up a little bit.  And this slide describes the -- each of the modules.  So attached to Module 2, which is the evaluation procedure, there is the set of questions that each applicant will answer as part of the application.  And accompanying those questions are the evaluation criteria and the scoring for that.  So the applicant can self-score or anticipate how their application's going to be measured.
 Attached to Module 5 is the base agreement for new registries.  And all those little boxes under Module 5 are the different appendices with that agreement.
 Then the other part of the posting is the resources available, the explanatory memoranda I showed you that I described earlier on the left, and the other resources on the right.
 So that's the end of the tiny font portion of the presentation.
 So, I don't know, is this set up to work?  So can we switch over to this?
 So the top link there goes to the Web site.  This is the comment forum that's posted on the Web site.  And why I wanted to show you this isn't to get you to try to read this, too.  But if you scroll down through some text, then you get to down below, where the applicant guidebook is -- yeah, you can see this.  So each module of the guidebook is posted here.  And then associated with it are whatever the explanatory memoranda for this goes.
 So in Module 1, we describe the fees, the application fees, or, actually, the evaluation processing fees associated with applying for a new TLD.  So the cost considerations memo is posted with that.  And then, you know, I made this font a little bigger, so it spills off the end of the page.
 But over here, you would click on where you would send your comment.  And then over to the right of that is actually where you can view the comments.  So you can see in Module 2, in Module 2, there's the evaluation procedures.  So there's the DNS stability procedures.  
 If you're going to apply for a string, you want to make sure it meets the criteria that are described in that memo and in the Module 2.  And the geographical name process is there and so on through the different modules.  So it's meant to lay out so you can have your reference material alongside the rules that are in the applicant guidebook.
 The other site would be the gTLD program page.  So I encourage you to visit here.  There will be continual updates in the process page.  Updates are listed down here.  So the latest ones can be found.
 And then the additional resources I discussed here.  So the guidebook diagram, the cross reference with the GNSO policy recommendations, and so on.
 And one of those link to a sort of interactive model of the entire process.  So this is another version of that very brief 1 through 5 module process flow diagram I sent you.
 And as you flash over each of the steps in the evaluation process, there's a description.  And then you can go to different parts of the evaluation process and flash over each one, get a description.
 So this is the first part of the evaluation process, and then you can go to the second part of the evaluation process and look at, for example, the financial capability section, and the questions that are being asked of applicants.
 So I encourage you to root around in the Web site, around that.
 You can start right from the ICANN front page where the new gTLD program is prominently displayed, as prominently as can be.
 Jason, can we go back to the presentation?  That would be great.  Thanks.
 So there are links you can use or you can go to icann.org and get going yourself.
 You can go on to the next one.
 So I want to spend a little bit of time -- thank you -- before I take questions going through some aspects of the guidebook itself, module by module.
 So right from the get-go, what's important for applicants to know?  Well, any established organization, institution or corporation can apply, as long as they are in good standing.
 Individuals cannot apply.
 An applicant will be asked to make one of two designations.  One is whether they are an open or a community-based applicant.
 So an open applicant is generic application and the registry can be used for any reason that doesn't affect DNS stability and complies with all the other rules and consensus policy and the like.
 A community-based TLD is operated for the benefit of a defined community consisting of a restricted population.  And there's a set of rules, a set of criteria in the guidebook that define what a bona fide community member must be or the criteria to be met.  So I encourage you to look at those, and applicants will choose whether or not to be an open or community-based application.
 I'm sorry.
 The evaluation processing fee is set presently at $185,000.  That's for the evaluation of the application and covers all the efforts that will be furnished by ICANN through independent panels and outside consultants, except for certain cases where there's a complex evaluation or a controversial application.  In those cases, there will be additional scrutiny of the application.
 That scrutiny or adjudication would take place using outside panels.  And those fees would be paid directly to those panels or outside consultants and not to ICANN.
 IDNs will probably be available in this opening round.  So that's very good news.  It's one of the main reasons why new gTLDs are being introduced to allow participation in different scripts, in different languages.
 Some of the final technical work is being done through the IETF to establish appropriate protocols for use of IDNs, and as Paul described earlier, and as we're going to talk a lot about at this meeting, there is an IDN effort to provide IDNs to ccTLDs through sort of a fast-track process that's being implemented.
 And those two processes will -- the development of those two processes will come to a culmination at about the same time, so that IDN ccTLDs and new gTLDs will be implemented at the same time, or introduced, or made available.  And that will enable the introduction of IDNs in the generic space, too.  So that's good news.
 So just briefly to talk about Module 1.  It describes the whole application life cycle.
 There is a process flow in there of the whole life cycle.
 As I just said, there are two different types of applications.  A commune-based type represents a community, as I said.  The open type is everything else.
 The documents required from all applicants are listed in there.  So certificates of good standing or organization, certainly financial statements.  They are all listed in there.
 There are certain technical and other requirements specific to IDN applicants.  Those are provided in there.  And then the processing fee information.
 For your use later on, I have put two versions of each of the next couple -- well, the next couple slides in.  Those boxes refer to the GNSO policy recommendation.  So it's to provide a tool for those who are interested in mapping the work in each module and the implementation in each module to the policy recommendations that the staff are implementing.
 So we provided those little guides in there.
 So you will see those, and that's all there is to say about those.
 Applications are going to be initially assessed in rounds.  So the rounds will have an opening date and a closing date.  All the rounds will be kept -- all the applications will be kept in confidence during that application period, and then right after the close of the application period, they will be posted.
 This guidebook certainly applies to the initial round.
 A follow-up round is being announced as part of this initial round to provide an expectation for everybody who doesn't want to participate right away, when they will be able to participate next.  Because there will be an additional opportunity and set of opportunities after that.
 So for those who wish to learn by watching the first round, that's very important to know that there will be that chance.
 The fee was calculated on a cost recovery basis.  So as I said, there was a considerable amount of work done, tedious cost-accounting work, if you don't mind the redundancy, to first assess the development cost there, and which development costs might be fairly assessed to the applicants.
 And then the processing cost for each application, each type of evaluation, the cost of outside technical panels, the cost of procuring services in many different languages, in many different regions of the world, translation expense, legal expense, and, like I said, there are several different panels, independent panels, that will be hired in order to evaluate the applications, go into the processing cost.
 And finally there is this assessment-of-risk cost.  So risk costs are really a number of things that would cost a whole a lot of money, but there's a really, really small chance of them occurring.
 So if you multiply the probability times the cost and sum those, you get the expected value of what those risk costs are.
 So they are an estimation of what we think the real cost is going to be at the end of the day and not just an arbitrarily large number, but really the result of a detailed study that was done regarding risk in this program.
 And then as I said, outside additional fees, if they are required for complex applications, which we think will be a significant minority, will be paid directly to outside panels.
 So Module 2 is really where the applicant will learn how their application will be assessed.
 It will be assessed in two ways.  First, the string, the label itself, will be assessed, and then the applicant will be assessed.  So there are two types of assessments.  There are three tests associated with each one.
 First, we want to ensure that the string does not effect in a deleterious way DNS stability or security.
 That's pretty much done by assessing the string against the very objective criteria that are listed in that paper.
 But also, a technical panel will look at the string to see if there's any other way in which a string could affect DNS stability.
 A second way the string will be measured is that we wish to ensure that user confusion does not result when a new TLD is delegated.
 So if an applied-for top-level domain is either identical or very, very similar, so similar that user confusion would result, would be likely to result as a result of its delegation into the root zone, we wish to avoid that.  So there will be a panel of examiners that will examine the strings against existing top-level domains and other applicants to ensure that doesn't occur.
 And then there will be a process to ensure that a limited set of geographical place names, country and subregion names, have the requisite approval.
 So in cases of country names, the process calls for the relevant government to approve that application affirmatively, or at least write a letter of non-objection.
 So after the string is examined, we want to look at the applicant themselves.
 Does the applicant have the technical capability and the financial capability of operating a registry?
 So what does that mean?  Well, each of the questions there go to how that's evaluated, and I'm going to talk about that a little bit more in a second.
 And then also, we want to look at the registry services that are going to be offered.
 Registry services are examined just to ensure that they do not affect DNS stability and security in a negative way.  So that there will be a quick-look sort of examination of every registry service that's offered.  We ask the applicant to describe those.
 And in those few cases we suspect where there might be an issue with that, those issues would be referred to a standing technical panel that would review that information.
 So this is that mapping one.  So we can go on to the next one.
 So the applicant guidebook has spiffing criteria and procedures listed for each of those tests.
 So there's detailed criteria about technical instability.  Detailed criteria about the process and procedure for assessing confusingly similar names, and for those other, the technical and financial capabilities and registry services evaluation.  So I encourage you to go and read those.
 The two applicant inquiries that are very important are demonstration of technical and financial capability.  There's two sets of assessment.
 So regarding technical capability, there's a set of 20 questions.  Each question identifies an area of technical or operational competence required to run a gTLD registry.
 And each question is scored separately, and each question requires a minimum score in order to pass the evaluation.  And then a sum-total score is required.
 So the purpose for this is to have the app can't demonstrate access to the technical expertise to operate a registry.
 We understand at this stage of the game the application is really a set of promises or a set of demonstration of understanding.  We're not asking the applicant to actually go to the expense of implementing a registry before their application is presented.
 Then there's a set of 11 financial questions.  And they are evaluated on seven criteria.  And that criteria is also described in the application.
 So each one of these 20 plus 11 questions all goes to, you know, what are you going to do so -- what are you going to do technically to comply with the technical requirements and a brief description of how you are going to operate the registry.
 What are you going to do, how much is it going to cost, how are you going to pay for it, where does the funding come from, and how are you going to protect registrants?
 Those are the four inquiries we have.
 So the principles of all these questions in this section really focus upon these things.
 DNS security and stability at the top, because we want to ensure the ongoing DNS stability and security.
 Then second, registrant protection.  So as I said earlier, applications that actively serve to protect registrants and demonstrate steps right away to protect registrants will be rewarded.
 There is conservatism as I said before about technical aspects and fiscal aspects to make sure the process is self-funding and registrants won't be asked to pay for it in any way.
 It's intended to be flexible.  So the evaluation process is meant to accommodate different business models and different technical models.  So the requirements kind of scale with what you want to do.
 So if you want to do a lot, then, you know, how you are going to pay for it is more difficult.  But it's intended to accommodate different business models.
 And then there is a requirement for protection rights mechanisms.
 Module 3 is about dispute resolution procedures.  And Paul talked a little bit about this earlier, but there are four areas of interest to be protected, where there can be a formal objection to a top-level domain string.
 And entities, parties withstanding, that meet standing requirements, can object to top-level domain strings only on these four grounds.  So the module defines the grounds, and that includes the associated memoranda.  Remember that morality and public order memoranda I told you about.
 The standing requirements for these groups is defined.  There's fairly detailed procedures about how to file an objection and the steps thereafter for the adjudication proceedings.
 And then there's the standards themselves, the dispute resolution principles by which the disputes will be heard.
 That section also defines or describes the three entities with whom ICANN has agreements in principle to conduct these dispute resolution proceedings.  And there's more information there.
 So Module 4 talks about string contention.
 So string contention arises when you get identical applications for top-level domains or, as I said, you get applications that are so similar that user confusion is likely to result.
 So there is a methodology described for how to identify contention sets.
 It can get a little bit tricky.  If we talk about strings being similar to one other, you can picture string A and B being similar to one another, and B and C, but not A and C.
 So how that contention is resolved gets to be complex, and that's why there is considerable material devoted to it in the guidebook and also in an explanatory memoranda alongside it.
 And then the section goes on to explain how this contention can be resolved.  So in certain cases, there will be a comparative evaluation between strings in order to determine if there is one string that should be awarded the TLD.
 The GNSO in its policy recommendations determined that community-based top-level domains should be afforded a consideration in the case where there's contending strings.
 That string that clearly identifies, say, an indigenous people should be awarded to that in a contending environment.
 Because that is the string for that community.
 So comparative evaluation can apply in those cases.
 Where it doesn't apply, the parties are urged to settle the matter amongst themselves.  So the most economical way for two parties to settle a dispute like this where there's contention to is arrive at some economic agreement among themselves.
 And finally, there's got to be a last-resort contention mechanism, and that's described in an accompanying paper.
 There are certain options given there.  The pros and cons of each option are described in that paper.  So that makes for great reading.  So I would point you to that one, too if you have made it this far.
 So I will just skip that one.
 And finally, there is the applicants that most applicants we think will go through the initial evaluation process only, and then transition to delegation.
 So Module 5 has a registry agreement, the graft registry agreement, that successful applicants will be asked to enter into with ICANN and contains a base agreement and then seven associated specifications.  I think we used to call them appendices.
 And then there are certain pre-delegation requirements.  So all those promises that were made in the application stage, there will be an opportunity to test some of those to see that the applicant actually is complying with the technical requirements or actually has put into place some protection mechanisms for registrants in case of failure.
 And so just prior to delegation, it can be actually checked that those things are in place.  And so it is a worthwhile check, and the applicant will be asked to go to some investment and expense in order to get the final delegation, which is an IANA function process.  The IANA function of ICANN will work through its regular process to delegate the top-level domain.
 So those are the little mapping things.
 And this is included in the posted presentation also, just to demonstrate how each of the 19 policy recommendations -- there's no recommendation 11 so that's why there's 20 there -- the 19 policy recommendations map to each one of those modules, for your interest.
 So how are we going to go forward from here?
 There's a lot of work to be done.
 Publishing this was a significant step in the process, but it's a step in the process.
 And that would get to start a period of community discussions, questions, good advice.
 As a result of that, there will be another version of the guidebook published for public comment probably before the final version is posted.
 We think there is going to be significant enough amendment to this guidebook that the community should have another look at it before the final version is posted.
 After that iteration of public comment, the guidebook will be forwarded to the Board of Directors of ICANN for consideration for approval.  And then it will be posted as the evaluation process, the request for proposals for new top-level domain.
 When that's posted, there's intended to be a four-month communication period between the publication of that and the acceptance of applications.  And that's intended to ensure there can be adequate communication through all regions, to parties that aren't in the ICANN cognizetti here to become aware of this opportunity to learn about the process and prepare an application in time.
 So that time line looks kind of like this, that the policy was approved by the ICANN board just before the third quarter of 2008, and the draft RFP was just issued a week and a half ago.
 And then the final RFP will be issued probably sometime between the end of the -- along the end of the first quarter or in the second quarter of next year.  And then the application period will be launched four months after that.
 So applications will be accepted either, you know, as early as -- as early as the end of the second quarter next year, but more probably be sometime in the beginning of the third quarter.
 So that's the time line for that.  And that's sort of the end of a rapid run-through of a lot of information.  So I thank you all for your time.  And we have allotted some time for questions if anybody wants to have any questions answered to the best of my ability.
 [ Applause ]
 >>KURT PRITZ:   Hi, Amadeu.
 >>AMADEU ABRIL i ABRIL:   Is there a mic?
 >>KURT PRITZ:   Yeah.
 >>AMADEU ABRIL i ABRIL:   I'm sure you are surprised to see me here.
 My name is Amadeu.  I am a prospective applicant for a TLD that will be a huge success in the next months.  Thus, I want answers from Kurt.
 First thing, you probably heard that many times, the ICANN evaluation fee is too high, and more especially the minimum fee -- the annual fee for the registries at $75,000, it's way too high for not OECD-based registries, not-for-profits, and many community-based.
 Having said that, the question -- I am surprised, and it's not that I am begging you for more work, but I am surprised in the application -- the evaluations, there are not many questions, if any, regarding policies for the TLD, regarding the usual things that we were used to for sunrise, land rush, and regular registrations, and different types of registrations, if any, and things like that.
 There is something like a general question regarding what are you doing with your registration services.  Does everything fit in there, or is ICANN not willing to hear about the details of the registration policies, the compliance policies and all things like that.
 And the comment regarding contention, two specific suggestions to make, be it a success or a failure.
 In the comparative evaluation you need 12 or 11 points, so three, three, three, and two.
 There is one criteria saying if the string is the name of a relevant institution, in the community institution, you have three.  If not, you have two.
 That is, if you apply for a new TLD like dot cat, or let's say the German cultural and linguistic community, and you ask for dot Deutsch, D-E-U-T-S-C-H, which is the name of the language, you get two.  If you ask for dot DUVIN which is the name of the common review (inaudible), you have three points because (inaudible) not the community.
 How can you give more points for one of the relevant institutions or an acronym for that and not the community?  This makes people just build fake institutions for the sake of having that when the relevant thing the name should reflect the community, not line of institutions.  And we can give all sorts of examples here.
 The last question is regarding what you said about you encourage negotiations and settlement.  But you encourage difficult things.
 If there are many applicants for the same TLD, let's imagine what happens, for instance -- what would happen if dot cat did not exist, it applies now for the Catalan linguistic and cultural community for dot cat.  And then there is a dot cat for cats, the animals.  You know, that's an accident of life.
 It's the same TLD.  They cannot co-exist.  They have nothing to negotiate.  Because the only thing they could negotiate is, look, dot cat cannot change the name because anything else wouldn't mean anything to them. 
 But dot cat could be transformed into dot cats with an "S" at the end.  It still means everything for that, and nobody would confuse that with the language because with the ending "S" means nothing related to the language and culture.  But this is not allowed.  
 You cannot just simply say we have had an accident, so let's change one of the strings because that's possible.  
 I understand that the GNSO counsel advised not (inaudible) that.  But my interpretation is they were thinking about what was happening in 2000 with dot aero, dot web, dot info, dot I, dot III and other funny things for different reasons for things that should not happen again but here is different.  Here is the accident between legitimate TLDs for different things and the only thing you can do there is arm twisting, black mailing, or just the kind of things that you prefer to negotiate with everybody has to withdraw but one in terms of questions.
 But for community-based TLDs, public auctions or private auctions is not the solution, so please try to fix that.
 >>KURT PRITZ:   Thank you, Amadeu.
 I'll try to briefly address your questions but I am not going to do very well, and we will certainly talk after this to make sure I have captured all your thoughts.
 The $75,000 fee was set by using a comparison with existing registry agreements, how they -- how much they were paying now in actual fees and also in consideration of various business models where some top-level domains will be operated in a classical way with registrations and others will be operated more with few registrations.
 So it is intended as sort of a one size fits all fee structure that intends to address the very different business models.
 As the process graduates in future round and as ICANN budgets are envisioned in out years, it's certainly apparent that fees overall will go down.
 And also, it's apparent that in this round where there's enough complexity already, introducing additional complexity of grants for certain applications for the application fee or for reduced fees in a way that cannot be abused or gained adds another layer of complexity on top of something that's already difficult to do.
 So right now, we intended to avoid that level of complexity by having this one set of fees, but the thinking will continue to evolve as we get to May of next year, June of next year.
 And so there's certainly more time to think about that.  And I value your comment about certain community-based TLDs not being able to pay $75,000.
 I also heard your comment about land rush and opening period and a lack of question there.
 So I'll take that back.
 I also heard your comment about land rush and an opening period and a lack of question there.  So I'll take that back.  We do ask the applicant for what rights protection mechanisms will be in place during the opening of the -- you know, they're required during the opening of the TLD.  That's meant in partial response to your question.  But we'll go back and see if we need to ask for more information there or if it's reasonable to ask for more information there.
 Registry policies.  I'm not sure I -- I wrote those two words down, so I'm not sure I remember what -- but we ask for the registry services that are going to be offered.  And the application asks for a complete description of all registry services, mostly to ensure the stability and security requirements are met.
 So it's sort of a fast evaluation for that.  And I'll need to talk to you more about that to understand exactly what you meant.
 The community-based label and the scoring of 11 out of 12 is meant to capture that you're a community-based top-level domain and that's your -- you know, that's your string.  And it would not be -- so in the interest of your community, if you want that string that's so clearly yours you should get it, and the further apart, the less of nexus between the string and that organization, then the less -- then the less of a requirement it is that that organization get that string.  So that high level of scoring, you know, you can change scoring to make it much less than 11 out of 12.  You can make the scoring so it's, you know, 50 out of 60 or something like that.  And then they would be ten apart.
 But that scoring is meant to intend to reward community-based applications that are applying for strings that are clearly a representation of their community.
 And I also understood your comment about not being able to change a name where two bona fide applicants apply for a name and some accommodation could be made easily if one of the applicants was allowed to change the name as a way of resolving the contention, where one applicant wouldn't have to forfeit some of the application fee and lose out.
 There was a -- as you sit around and talk about various implementation models, there's very many ways where a system where you can change a name can be abused or gamed.  And I'm not going to bring any of them to mind right now.  But the requirement that you couldn't change -- couldn't change your name was made in anticipation of that, at least in the first round.
 But I want to talk to you some more about that to get your understanding of it.  So I appreciate the comment.
 >> All right.  We have a question with mike 2 in the back.  Raise your sign, please.  Is that question still there?
 >> Yes, my name is Ray King.  I'm with (saying name).  
 And my question is, if you have a situation where, let's say, you apply for a -- you do a community app; right?  And let's just say, for example, there are two other people that do open apps for the same TLD.  And let's say you get ten points out of 12, so you've missed the bar; right?  Now you're back in the same -- you're in the same pool with the other two open apps.
 Do the -- assuming you have put some community restrictions in your original app, do those still apply?  So if you're back in -- now you're working -- you're just equal with the other two people and contending.  Do you still have to uphold those same restrictions?
 >>KURT PRITZ:   Thanks, Ray.
 Yeah, the really short answer to that is, yes, if you make a community-based application and have some restrictions associated with that, those would be -- those would be made part of the agreement, and they would be enforced through a, you know, post delegation sort of procedure.
 >>RAYMOND KING:   Thank you.
 >>KURT PRITZ:   Sure, Ray.
 >> All right.  Do you want another question?  We have a question on mike --
 >>KURT PRITZ:   Yeah.
 >> -- 4.
 >> Hi, my name is (saying name).  I'm doing dot NYC and I'm advising some other people on names that they're doing.
 I'd like to first thank the ICANN staff for putting this together, Kurt and Karla and other people who have worked very hard on this.  And I think, for the most part, that it's been very successful.
 That said, I'd like to identify a few issues that relate to one another, which are risk, cost, and speed.
 I've heard a lot about risk, but it has mainly been identified for ICANN and not for the applicants.
 And the major risk I see for the applicants is the contract, first of all, where ICANN can change anything they'd like at any time.  And the only way that can be dealt with by the other party to the contract is by a supermajority of affected registries affirmatively going against the contract change.  That seems to me a very, very high bar.
 The second area of risk is the vagueness that is attached to the various financial requirements.  And this all comes down to a question of cost.  Because if I am, or as I suspect many people are, looking for investment in their TLDs, it's all very well to hear from you and from other people that really expect most of these to go through, and it shouldn't be an issue.  But if I'm an investor and I'm looking at my risk, that's going to be insufficient.  I'm going to want to know if I'm going to get my money back.  And the way I read it is that you have one bite at the apple.  It may be refused.  You may not know the grounds.  You may not know who refused it or why.
 We certainly know from various other panels to which people must submit, for instance, UDRPs, that there's a great deal of variation of the kinds of decisions that are made.  You can have very similar domain name cases decided differently by different panelists.  So there's not any transparency there, and it seems to me to be a huge risk and therefore makes it quite difficult to raise investment.
 And the third thing that goes with that is speed.  Now, we all have a bit of an issue here.  We'd like to see a more perfect application process.  But we're also quite worried that it may take forever.  I mean, God knows, it's been ten years since we started this.
 So, you know, businesses here have staff.  They have offices, et cetera, et cetera.  Today, we learned that there's going to be a second draft.  So how do we know there's not going to be a third draft?  How long do we have to carry these costs while we wait?
 So there's a definite tension there.  And I'm not suggesting that it's easily solvable.
 And, finally, I'd like to echo what Amadeu and others have said about the -- not necessarily the initial fee, which is high, but at least we know what it is, more or less, but the ongoing cost, which is deadly to small but deserving TLDs and really has not been justified at all in the way that the initial cost was very carefully justified.
 So I'd like you to speak to those issues.  Thank you.
 >>KURT PRITZ:   All right.  Thank you very much for that.
 You're right about the contract, that it's easier for ICANN to change.  So how do I want to put this?
 So as the -- as we've seen over the last ten years, the marketplace evolves very quickly.  And there's new business models, some of which are at the fringe of what's allowable under agreements, some of which aren't even in the contemplation of agreements we have now.
 And so there --  It is thought there there has to be a mechanism for amending the contract in a facile way.  Presently, we have 16 gTLD contracts that are each negotiated separately.  And those negotiations take a significant amount of time.  In the latest round, where seven new TLDs were introduced, each set of contract negotiations took considerable time in a way that just wouldn't scale up.
 And then the other reason that contract should be changed in a relatively easy way is to address stability and security issues that arise due to the changing marketplace.
 So with hundreds of TLDs rather than 16, there's no real way to scale that.
 So I understand your comments very well.  And you're not the first one that's made comments this week about that.
 So there --  You know -- and so there's got to be some discussion where that balancing can take place maybe.  I don't know if the amendments can just take place in limited areas or there's a different mechanism for approval of them that can be accomplished in a different way.  You know, we talk -- there's been considerable discussion among ICANN and outside counsel and others about ways of going about this.  Different models have evolved.
 What you're seeing and what you're reading is certainly one of them.
 There is a certain vagueness to the financial requirements.  That's also a balancing that took place.  Should the requirement be that you have $100,000 in the bank for a gTLD registry?  Well, that's enough for a certain-size registry, but maybe too much for a small one and not enough for a really large one.  So the financial requirements were written in a way that were intended to enable us a scaling or a flexibility.
 So if you want to propose a small business model, then your financial obligation is to demonstrate that you can fund somehow that small business model and still protect registrants.
 If you have more a grandiose plan, then you just want to demonstrate that financial competence that you can fund what you're intending.
 The financial criteria also put a high, high value on protection of registrants.
 So just prior to registration, the obligations call for getting some sort of -- implementing some sort of instrument so ongoing operations can be funded for a period of time in case the registry fails.
 If you obtain that instrument during the application phase, there's bonus points there that put you well on the way to passing.  So that's -- and that's a very objective measure.
 So a lot of thought went into the criteria.  But we understand they're not completely objective.  And if there's ideas -- I understand the criticism, and it's very constructive.  If there are thoughts about how to make them more objective and retain that flexibility, that would be great.  'Cause it's certainly been a struggle to get as close to totally objective as you can, and maintain the flexibility.
 As far as who reviews the applications, there will be a public tender in the near future for the provider of those panels.  So applicants will know who the -- who the panelists are, what company runs that operation.  So there will be a degree of transparency there.
 And I understand that this process has been going on since the start of ICANN.  So we've been talking about it a long time.  We think that publishing this guidebook is really breaking some sort of Gordian knot and making a substantial step forward so that we can forecast with some specificity what the future will bring.  This comment period, one other comment period, and then the end, we think.
 >> We have several questions out here, people lining up.
 I'd like to take the question from 3.
 I see all of your questions.  I do realize that.  But we'll do 3 first.
 >> Hi, Kurt.  Stuart Lawley here, ACM registry.
 A couple of questions on the two separate objection processes, one in the case of community-based objections.
 In the example, or, for example, if you had six applications for an open type string, identical, the same identical string, but you had one community-based objector who was not a bidder, does that objector have to file six separate filings and pay the filings fee against all six open bidders?  And sit and wait and hopefully win his objection and get his money back at some time in the future?  So that's question number one for community-based applicants.
 And the second question is to do with morality and public order-based objections.
 Reading the latest missive that came out on this, it strikes me that a lot of likely objections here may be from governments, NGOs, or nonprofit organizations.  I'm assuming -- or if I recall, the objection's going to be dealt with by the International Chamber of Commerce.  So I guess there's still a filing fee.
 It strikes me that a lot of the governments or NGOs and even nonprofits wouldn't like to pay filing fees.  So is this a big disincentive for them to actually jump through those hoops and object to a potentially objectionable string?
 And taking that one step further, I assume that once morality or public order objection has been put in against a string, it automatically counts against all applicants for that string?
 And would we there -- potentially therefore have the nightmare scenario that if there's a filing fee to pay and a would-be-objector on morality didn't have the money or wasn't prepared to fill in the forms and pay the fee, that a potentially very objectionable TLD could pass through unchallenged?
 >>KURT PRITZ:   Thanks, Stuart.  Those questions are sort of related, because there's an opportunity for certain objections to be consolidated, and you could probably think through cases where objections are more easily consolidated than not.
 So based -- in the case of a community-based objection, the objection is really about that applicant and whether he's a representative -- a bona fide representative of that community.
 So in that case, it seems like each objection would be very different, because it's more about the applicant than the string.  And so it seems more likely than not, but not certain, that there would be separate filing fees for those kinds of objections.
 If you're objecting about a string, which is most of what morality and public order objections are about, if you're objecting about a string, it seems that objections are more easily consolidated into one.  So there would be more likelihood that there would be lower fees associated with that, because it can be spread over the objections.
 So the answer to both of your questions really goes, I think, to whether they can be consolidated or not.
 There's been a lot of discussion about governments and whether or not they'll participate in the process and pay the fees.  That's part of the standing discussion that's going on right now, who should have standing to make a morality or public order objection.  Is it just governments?  Or governments and certain organizations?  Or can -- could it be the proxies of governments and therefore individuals could object to -- could object to strings?
 So that's -- you know, if you have a -- an opinion on that or thoughts how that can be rationally done, I would appreciate making a comment.
 So is that kind of clear?  Next?  Number 4.
 >> All right.  We'd like to take a question from 1, please.
 >> Microphone.
 >> Please don't turn the mike off.  We manage it from here.
 >> Yeah, it seemed to be on.  Hello.
 >> You're welcome.
 >> Emily Taylor from Nominet.
 First of all, can I say thank you for a very good, readable document, which is -- I think, will be -- as it's developed, will become a very important resource going forward.  And it's also good to see evidence of learning from previous experiences.  And you can see that as the process is mapped out.
 I have a question and a suggestion.  Really, as I was reading through it very quickly, what seems to be lacking is an overall vision of what the name space is going to be looking like after we get through to the end of this new gTLD process.
 There's no sense of what the shape will be or what really are the objectives here.
 So, you know, the detailed examination of each application will bring you a bunch of individual answers, but who is actually going to look at the entire shape of things?  And who is also going to safeguard the interests and perspectives of end users in this?
 I don't think that that is the same as asking applicants to submit evidence of community support.
 So my suggestion is that, you know, is there some sort of final review of the overall suite of new gTLDs that are going to be, you know -- that are going to be made?  You know, have we met the objectives?  Is there any evaluation of the extent to which proposals or the new name space will meet previously unmet needs?  Or is this just an exercise in creating new space, whatever the outcome?
 >>KURT PRITZ:   So I think -- thanks for that.  I think those are excellent points.
 There's a lot been written about how the process has been developed, the history of it, the -- ICANN's mission in promoting competition and choice for consumers, the community-based, bottom-up discussion that resulted in a set of policy recommendations to guide that.  But I don't think there has been, to the extent you describe, which I think is desirable, what the outcome is envisaged and how that would affect the participants in this process, but also end users.
 So I don't really have a better answer for you than that.
 There's certainly planned to be a review of this process after one round to determine if certain goals are met.  And I think that, you know, the high-level, overarching goal should be considered in that review, too.  So I think that was just a great comment.  Thank you.
 >> We have a question here on mike 4.
 >> Hello, Kurt.  Can everybody hear me?  Ray Fassett from Dot Jobs.
 Kurt, I'd also like to take the opportunity to compliment ICANN staff on some very robust documents.  I think it is a very positive step forward to have these documents now out there for discussion.
 My question specifically has to do with the community-based application.  Dot Jobs went through the sponsored round.  But if I was going to compare it to this round, we would be considered a community-based application.
 And specifically, I'm talking about the criteria that has to do with having registration policies that include name selection and then use requirements.
 Now, going through the round that we went through, you know, the idea was for the applicant to define a community, define eligibility requirements of who can register in the TLD, and then manage that in the allocation of domain names at the second level in operations.
 Now, this is a little different when we start talking about use requirements or the registry operator being able to effectively manage the use of the domain names once they've been allocated.
 So I'm wondering if staff has considered that.  This seems kind of new to me for -- and also considering the fact that this would go into the contract as well.  So there would be a contract requirement for the registry operator to be somehow managing or enforcing the use of the domain names.  And I'm wondering if you guys gave that considerable thought.
 >>KURT PRITZ:   So thanks, Ray.  And I'd like to compliment ICANN staff, too.
 You know, I certainly don't want to opine if Dot Jobs would meet the requirements of a community-based TLD today.  But I think you're referring to the comparative evaluation test that is described in the applicant guidebook.  Is that right?
 >>RAY FASSETT:   Yes.
 >>KURT PRITZ:   Yes.
 So that is -- this comes into play, the qualification as a community-based applicant comes into play only if there is contention between two strings, if two identical strings are applied for.
 So, typically, a community-based applicant will self-identify itself as a community-based applicant and how its registration and use policies are restricted in order to meet the needs of the community, and how it's going to meet the needs of that community.
 And then be asked to live up to those restrictions.  And that's really the end of the inquiry.  So in all those cases, there's not that inquiry.  The only time this comes into play is when there's contention between strings.
 And in those cases where there are two bona fide applicants for a top-level domain, one of which has identified itself as a community-based one, we think that community-based TLD -- this process things that community-based TLD and that applicant should be awarded a priority if, really, that is the string for that community, that this applicant and the community would be -- this would serve to the detriment of that community if someone else got that string, because nobody else -- there's no other string really available for that community.  So the contention resolution is meant to identify the community as a clear winner based on the nexus between that string and that community.
 And then to the extent to which there's registration end use policies invoked.  So you can get, you know, less than a 4 in the current plan, less than a 4 on one of those things and still pass.  So we think there's flexibility in not having strict use policies or not having the close nexus, but you at least have to have most of that stuff.  And like I said, it's only meant to award a priority in the case of string contention.  Otherwise, there's not that test for a community-based one.
 >> We have a question on 2.
 >> Hi.  Becky Burr, Wilmer Hale.
 I have one comment and two questions.  I want to echo Anthony's comment about the provisions of the contract that permit ICANN to change the contract provision, any provision, of the registry contract for any reason.
 There is a provision right now that has existed from the beginning of time that allows ICANN to enact changes in the contracts on an emergency basis or on a permanent basis for stability and security.  So I -- I note that you mention that as a need.  But I don't see that it's there.
 The other thing is, I think that given that this is a fundamental change in the basic bargain here, that contract that you -- that you would enter into contracts that a company would agree you could change in the course of the contract, and they live with the uncertainty, the business uncertainty, that that provides, I would certainly like to see some examples of where the technology has changed in the last ten years in a way that would have justified this kind of cram-down.  Because I'm not aware of any.
 And I just want to say, I found that a very disturbing issue in the midst of this enhancing institutional confidence.
 Along those same lines, I was really amazed by the fact that in order to apply for a gTLD in this round, you need to check your rights at the door and agree in advance that you will not challenge ICANN's determination.
 Now, on its face, you have to waive all of your rights.  That would include your reconsideration rights and IRP rights.  I think it's a terrible position to take under any circumstances.  But if you are really suggesting that somebody cannot file a reconsideration or an IRP position, that's just shocking.  I mean, I just don't even know what to say to it.
 The final thing is, the current sTLDs all have a provision in their contracts that said when we applied, we had to demonstrate differentiation in the domain space.
 As I understand it, the string contention issue is limited to visible -- you know, visual confusion, and I'm wondering if it was an oversight to address that aspect in the contracts or if, in fact, you intend to eliminate that provision of the contracts.
 >>KURT PRITZ:   So, Becky.  Hi.  So I'm going to accept your first three comments, and, you know, we have transcription, and take note of them.  So, you know, I understand them completely.
 Regarding string contention, there's two examinations to determine if strings are so similar that they collide.  The first one, as written in the process, is visual comparison that's conducted by a panel of examiners initially to determine if there's visual confusion.
 The second is the objection process for string confusion where there can be an objection that an applied-for string is so similar to an existing string or an applied-for string that user confusion would result.  That confusion could result from either the -- because they're visually similar or orally similar or have similar meaning.
 So that examination is more expansive.
 >>BECKY BURR:   I -- that's helpful.  But I don't think that that answers the question about the statement -- the right that you consider differentiation.  Because differentiation and confusion are not necessarily the same thing.
 >>KURT PRITZ:   Wait.  Don't go away.
 >>BECKY BURR:   Okay.
 >>KURT PRITZ:   Say that again.
 >>BECKY BURR:   sTLD contracts, there's a provision in appendix X, whatever it was, that said we had to demonstrate to you that we were bringing differentiation to the name space by provision this.
 In recognition of the fact that we had to do that, you're going to take that into consideration in approving new domain names going forward.  That's not a, "We'll never bring a string that competes with this into the space."  Everybody understands that.
 But I don't think that a provision that says you're going to consider the fact that we had to demonstrate that we were adding sort of a differentiation to the name space is answered by simply saying, "You can't confuse people."
 >>KURT PRITZ:   You can't what?
 >>BECKY BURR:   You can't confuse people.
 I mean, I just don't think it's the same thing.  And I'm sure we're going to have more time to talk about it.
 >>KURT PRITZ:   Yeah, we'll have more time.  I think the differentiation of the name space is about the community nature of the sTLD rather than a differentiation of what the string is.
 We'll talk later.  I'm sorry.
 Who's next?
 >> Question on 3, please.  A question on 3 that's been waiting a while.
 >> Hello, Kurt.  Hello, testing, testing.
 Not there yet.  One, two, three.  Let me know when it's on.  Is it on?
 Hello, test, test, test.  Hello, test, test.
 >> Please talk into the mike so we can see if it's on.
 >>ERIC BRUNNER-WILLIAMS:   Okay.  I'll just go ahead.
 >> Did somebody turn it off?
 >>ERIC BRUNNER-WILLIAMS:   No, it's not turned off.  But I'll talk lightly.
 >> Number 4 is on.
 >>KURT PRITZ:   Eric, you're the most technical person in the room.
 >> Somebody took the wrong microphone.  Are you talking on 4?
 >> No, 4.
 (Multiple people speaking simultaneously.)
 >> Turn 4 off.
 >>KURT PRITZ:   Hey, John.
 >>ERIC BRUNNER WILLIAMS:  Hello, Kurt?
 >> This one works.
 >>ERIC BRUNNER WILLIAMS:  It's finally on.  That's simpler.
 Hi, Kurt.  Eric Brunner Williams from CORE.
 There are three different objection -- I might not get the word, but there is a rights based, there is a morality based, and there is morality community based.
 Each one of these has a separate price point.  Could you please review the prices for each of these three forms of objection?  And then address the issue of why the corporate form or the corporate right that is intellectual property rights cost one-tenth or perhaps even one-100th as much as a community-based objection.
 My concern here is that we are designing a system that is bound to fail if it charges an order of magnitude more for community-based objections than for rights-based objections; that is, intellectual property rights-based objections.  And we should not be doing that.  We shouldn't be making it so that a dollar buys ten times more corporate rights than buys community rights.  Or even 100 times.
 Thank you.
 >>KURT PRITZ:   Certainly that's well put.  The goal was to make all the objection processes and adjudication processes as economical as possible.  So to take advantage of your question, if one was $1 and one was $10 it would be okay because they were both pretty low, even though one is ten times the other.
 I think what you are talking about is the infringement-of-rights objection will probably, based on the input we received from our potential provider, will probably be a flat fee, whereas community-based and morality and public order-based objections will be charged at an hourly rate.  And because the morality and public order objections are more complex in nature, that might be a three-person panel instead of a one-person panel.  And so be even more expensive.
 So in order to temper that, you know, we have tried to make the process as economical as possible.
 In the case of infringement of rights, that's an area where there is some well settled decisions in the domain name space and certainly outside it where the dispute resolution provider knows what they are getting into and what their task is, and kind of can picture a flat fee.
 For community-based objections, sort of new grounds.
 We think that can be handled by one person, a one-person panel, so we pushed the cost down as much as we could there.
 And -- but then it's an hourly rate, where, as we continue to refine our estimates, we're going to narrow those ranges to provide certainty for applicants.
 And then finally morality and public order, those are potentially the most complex of the bunch and potentially hearing cases involving governments.  Where discussions with those, with highly esteemed jurists and practitioners in the area of international law and international courts advise it would be better to have three-person panels.
 So that becomes more expensive.
 You know, we continue to push back on that.
 Another aspect of this process is it's essentially loser pays.
 So that if you are in the right -- you know, never say never, never say always -- but you will have some assurance you will prevail and in the end you won't have to be making that high level of investment.
 So it's certainly ICANN's desire and objective to push those costs as low as they can to provide an affordable process.
 But I understand what you are saying about some processes being more expensive than others.
 >> We have a question on 1.  Please make sure the mic has not been turned off accidentally.
 Mic 1.
 >>WERNER STAUB:  My name is Werner Staub from CORE.
 I would like to talk first about the objectives of this process here where we try to have certainty for all the parties involved.
 What we seem to be realizing more and more is that, indeed, time is money.  But money is not time.
 We cannot replace the time lost with whatever investments are going to be made thereafter.
 And in the process that we have now, we are trying to improve the criteria in whatever way we go forward by pushing the deadline further off.  And now we have gone into a further step of pushing things off, namely by saying there is going to be a pause after this coming round to think.  And there is an estimate that this may take a year and a half or so.  The (inaudible) is going to be as soon as we stop the process, it's going to take three or four years again.
 So you imagine, this is just like a city that is having many ideas of what it should be built like, but the city government has decided that construction permits are only awarded once every five or six years.
 Imagine what kind of buildings that city would have.
 So if you want to have a good TLD space, you have to give it a process that is conducive to good proposals.
 Good proposals need their time for development and they cannot be subject to the risk, the ICANN risk, so to speak, who doesn't even know when the process is going to begin, when it will close again, when is the time for re-opening and so on.  The community working on a given project would of course have to be sure that once they have done their job, they will be able to deliver their proposal to someone, there is somebody listening on the other side.
 Now, even losing that objective which was stated in 2003 in the form of ongoing process, not once every five years.
 The other thing is a brief reminder, we should be careful now about the foundations of the very documents that we are seeing now.  There are very good things in there but we have a couple of bugs that we are trying to chase down and some of the bugs are in the foundations.
 One of them I see is in language, the language bug.  You cannot have a language that says you are either a community-based TLD or an open TLD.  It's just like saying you are either American or Muslim.  They are not a contradiction.
 By putting this kind of language inside, we actually create distinctions that will cause damage to everyone further down.
 >>KURT PRITZ:   Thanks, Werner.
 So I understand clearly your comments.
 I think that what you see in all the pages that are posted are sort of a robust process.  And what's paramount in launching this thing right is how it's going to come out at the end.
 We had a really good comment earlier about what's your vision for the end game here.
 How do you expect the DNS to look after this round?
 How are you going to measure yourself against this process?
 Well, so of paramount concern is, you know, ongoing is stability and security, creating a robust process, understanding all the complexities associated with what I think are really well-founded and well-developed policy recommendations to protect certain interests and developing mechanisms for dealing with each contingency that can occur in a process with several hundred applicants.
 So that the sorts of time lines you are seeing are a result of trying to ensure that all those contingencies are addressed.  Stability and security is maintained, and the vision for what the DNS looks like at the end is obtained, and not -- even though there is strong demand and a strong desire on the part of ICANN to do things in a timely way, not do things before they are well considered.
 And as you know, the GNSO and staff worked for a long period of time on developing the policy.  And the staff is now working with the GNSO to get feedback on the policy, and also the board is playing a very important role in providing feedback to staff on portions of the procedure as they are developed.
 So I'm very sympathetic to what you had to say.  And ICANN will continue to expend effort and resources in every way that's reasonable in order to accelerate the process and bring it to an end.
 I heard the same comment yesterday that you made that I think is very good about the language, about open versus community-based TLDs, and so I think that should be considered in the next version to clean that up.
 >> We have one last question.  We will take it from 4.
 >> Good day.  It's Josh Row here, and I represent an end user.  Me.
 So I use domain names to find Web sites.  I use domain names in sending people e-mails.  And even when I go on search engines, I use domain names as way of working out the credibility of the site before I click on it.
 So I think at the moment, domain names are really important.
 Today, we have 270 top-level domain names and generic and country code.  Under country code domain name, there are over 1700 second-level domain names.
 So my question to ICANN is what benefit are any new names, at the top level, at the second level, wherever, for me, the end user?  Does it make my experience more usable in accessing e-mails, visiting Web sites, figuring out links to click on in search engine results.  How does it make the experience more usable?
 >>KURT PRITZ:   I think this -- You know, it's a very profound question; right?  And it's exactly the right question that was considered and discussed many times in the founding of ICANN and the creation of the mission statement to open up the domain name space and then revisit it again in the policy development discussions that occurred across the community where the fundamental first question to be answered in that policy development was whether there should be new TLDs introduced.
 And memorialized in those discussions by ICANN's policy-making volunteers is the pros and cons or the benefits and detriments of opening the domain space to additional TLDs.
 So I don't feel adequate to stand up here and highlight the results of those discussions.  But I would point in that direction.  And I would combine your comment with an earlier comment that we need to describe the vision for what the domain space is going to look like after we are done so we can measure ourselves against those goals and determine if the benefits were achieved or not.
 So Nancy, is there another meeting right now?  Or is there an opportunity to take more questions if people have them?
 >> Yes, there is.  I was trying to work with the sound man.
 We have a question here on mic 2, and this is the last one because everyone has scheduled appointments.
 >>KHALED FATTAL:  Thank you.
 Thank you very much.  And I apologize to my Arab brothers, but I will ask my question in English.
 Many of you know me as the chairman and CEO of MINC since 2002.
 Kurt, I would like to make short point and on other issues I will correspond with you at later date.
 Emily Taylor from Nominet -- and thank you, Emily, for making an excellent comment earlier on -- referred to the learning process and the ability to define what is our objective from all of this exercise.
 The reason why I make this comment is because in 2004 -- I don't think, Kurt, you were with ICANN at that time yet.
 >>KURT PRITZ:   Yes, I was.
 >>KHALED FATTAL:  Fantastic, so guess what?  You are accountable.
 >>KURT PRITZ:   But I wasn't responsible.  Yeah.
 [ Laughter ]
 >>KHALED FATTAL:  In 2004, at the Kuala Lumpur ICANN IDN workshop, which was the first IDN major workshop that had been done by ICANN, many people participated, and I actually made a presentation, which is, by the way, all of you can look back on the ICANN Web site dating back to that date.
 My presentation about -- focused on the difference between aiming at providing IDNs as the objective versus multilingualizing the Internet.
 And the presentation talked about that if we focus only on providing IDNs, what we are going to be doing is providing the same thing as what existed in the English Internet, just providing domain names.  Whereas with multilingualization, we are factoring in community, responsibility, policy-making, et cetera, et cetera.
 And I think while you guys -- I give you credit.  The work you are handling is a huge challenge by its nature.
 But I think what needs to happen is perhaps a refocus of the trajectory of where you are aiming to go.
 Because a single degree in the difference can mean you are aiming to the moon versus going to mars.
 And I put it to you here, is while this document shows tremendous hard work, I think it lacks the sense of direction of where we are going at.
 And if we are challenging ourselves to create a multilingual Internet that involves community, and I take it -- I acknowledge that community is being given a degree of preferential treatment, but I believe we can do a lot better to harness that and to provide more opportunity so that it truly becomes a multilingual Internet.
 So since you were around in 2004, guess what?  You are accountable and responsible for what we already knew.
 Thank you very much, and thank you for the opportunity to make the point.
 >>KURT PRITZ:   Thanks, Khaled.
 Is that it?  All right.
 So thank you very much for your time and your interest.  I appreciate in advance you spending time to read the materials, and I am the only Pritz in ICANN, so I would be happy to answer any questions you might have, during this meeting in person or afterwards, via e-mail.
 So thanks very much.
 Have great meeting.
 [ Applause ]