GNSO Workshop on New gTLDs Monday 29 October 2007 ICANN Meeting - Los Angeles >>DENISE MICHEL: If everyone can take their seat, we're going to start the workshop welcome to the GNSO's new gTLD workshop. We have the privilege of having Chris Disspain as our fearless moderator today for the next six hours. Many of you know Chris as the chair of the ccNSO Council. And today he's serving in his personal capacity as a knowledgeable and skilled moderator for this event. I'll now turn it over to Chris to start. >>CHRIS DISSPAIN: Thank you, Denise. Good afternoon, everybody. >> Good afternoon. >>CHRIS DISSPAIN: Thank you very much. Steve. Welcome. As Denise has said, my name's Chris Disspain. I'm the moderator for today. I'm going to run through some introductory slides fairly quickly so that we can get started on the reason why we're all here. The first is the structure of this workshop. As Denise has said, it's going to take six hours. We're going to split that into three sessions, the first two session, probably roughly about an hour and a half, and the last session as long as it takes until we get to the end, provided that we all finish by 7:00. There will be two breaks. The breaks will be of 20 minutes' duration and only 20 minutes' duration. We have a lot to get through, and we will start again 20 minutes after we finish. If you're not back in the room, then you'll miss the start of the session. During the breaks, there will be councillors wandering around wearing beautiful redneck classes -- can you hold up your necklaces, please. If you want to ask a GNSO councillor a question, just look for the person with the redneck class on and ask them a question. Don't proposition them, though. This session is being translated into French, Spanish, and Russian by the people at the back of the room. If you want to listen in French, Spanish, or Russian, there are translation devices over there by the main entrance. I would like to be able to say that to you in French, Spanish, and Russian, but, sadly, I'm unable to do so. Participation procedures. There is a general microphone for the audience. That is right there. There's a special microphone for the GNSO councillors and ICANN staff who are not sitting up on the panel. That is a handheld microphone. And Denise is going to run around -- no, not Denise. Sorry, how silly. Someone will run around with that microphone. When you're speaking, please remember to give your name and the organization that you come from. And please make sure that you speak into the microphone. And please talk slowly so that everyone can understand you. And the scribes can scribe and the translators can translate. Just some guidelines. As I've already said, time management is going to be essential. Please be brief. If we think that we're having time constraints or time problems, we will enforce time limits. Staying on topic is critically important. Please focus only on the topic that we are discussing at that particular point during this workshop. Please identify the topic that you're addressing. If we have time at the end of session 3, we will hold an open microphone. But there will also be an open microphone session following the public forum on Thursday. There are some handouts. There's a quick page reference guide -- is there? Do we have that? Yeah. And a workshop agenda, the list of principles, recommendations, and implementation guidelines, and so on. And, of course, a summary of the report. So, we're going to start -- I've covered everything, and I think I have. We're going to start with the workshop agenda. And session 1 is principles A to F, recommendations 1, 2, 4, 7, 8, 9, and 13, an overview of the draft RFP, projected timeline and estimated costs, implementation details, and then the open discussion. And at that, I'm going to hand over to Chuck, who is going to lead us -- I'm sorry, I apologize. Kieren, having spoken to you for about ten minutes, I forgot to mention it. For those of you participating remotely, Kieren's here in the room. You can't see him, but I can. If you want to ask questions, if you want to send comments in to the public participation site on the blog -- >>KIEREN McCARTHY: There's a chat room on the Los Angeles meeting site. >>CHRIS DISSPAIN: Chat room on the Los Angeles meeting site. We will take questions remotely as well as in the room. Thank you. Chuck. >>CHUCK GOMES: Just for clarification on that, if you just go to the meeting site and click on this agenda item, you'll see the chat room right away. So it's very easy to do. My name is Chuck Gomes. I was the leader of the planning group for this workshop from the council. And that's why I'm up here and giving a good part of the presentation. Chris talked about the agenda. Now, I want to refer to -- and I may do this again -- but handouts -- a key handout for this workshop is the quick reference guide. That reference guide will show you the agenda of the full workshop so you'll be able to know when particular recommendations are coming up in the session. Because as Chris indicated, we want to restrict the discussion, the Q and A of the session to when those happen -- so please refer to your agenda to know when recommendations are coming up. Just in case you haven't looked at that, recommendations 3, 6, and 20 are in the third session. Okay? You can see what those are on your quick reference guide. The quick reference guide will also list all of the principles, recommendations, and the implementation guidelines so that you can refer to those. And then, lastly, note that it is printed on both sides, lastly, there's a summary of the reserved names that will come into play in one of the slides in the second session. So if you don't have one of those or if you'd like to access that online, it is accessible on the online site. So, very quickly, as you can see, session 1 is principles A through F. That's all of the principles except the last one, G, which will come in the last session. And then recommendations -- you can see there -- 1, 2, 4, 7, 8, 9, and 13. And in addition, there will be a brief overdraft [sic] of what's happening with regard to the RFP, some projected timelines and estimated costs, very high-level, don't get your hopes up that you're going to see any dollar numbers there. And then you will -- and some additional discussion about other implementation details. And then, finally, open discussion. Now, with regard to implementation details, I want to make really clear that implementation is a process that is ongoing, and, in fact, not too much of it can happen until the board acts on these recommendations. So please understand that. And we are fully aware of the fact that implementation is crucial. And how the recommendations are implemented are a key element. So we are aware of that. Because of that, we probably won't spend a lot of time talking about the implementation details, 'cause we don't know them yet. But there will be other opportunities for discussion, particularly with regard to the RFP and the draft base contract. Now, session 2 -- and I won't list the recommendations. You can see them on the agenda on the workshop quick reference good. You can see there are several implementations guideline we'll talk about there. In that session, Kurt will be going over a very high-level overview of what's happening with regard to the base contract, a few other comments on implementation, and then, again, like in all sessions, there will be open discussion. Sorry about that. I skipped session 3. Session 3 will be the most fun session today, we think. And that will involve principle G, recommendations 3, 6, 12, and 20, a little discussion -- in fact, quite a lot of discussion in that session on implementation details and some of the issues that are encountered there. And then, again, open discussion. Please refer to the quick reference guide. And understand, because of time constraints today -- and I know six hours sounds like a long time, but there is a lot to cover, and we really want plenty of opportunity for interaction with you both online and in person. So you're going to find us not reading text out of the full report or the summary documents, some copies of which are on the table over there, and it's online. We will ask you to read those sections on your own. Hopefully, many of you have already reviewed those documents. Okay. Session 1. And let's jump right into it. Let me introduce the panel members. From the ISPC constituency -- ISCPC -- sorry about that -- Tony Harris. From the IPC, Ute Decker: From the CBUC, the business constituency, Mike Rodenbaugh. Our council chair, Avri Doria. Myself, and from ICANN staff, Kurt Pritz. Very quickly, just to go over the first -- most of the principles, in fact. Principle A, the GNSO Council has already recommended to the board that new gTLDs must be introduced in an orderly, timely, and predictable way. Principle B, some new generic top-level domains should be internationalized. Principle C, new gTLDs will fill demand and provide more competition. D, technical criteria must ensure stability, security, and global interoperability. Principle E, capability criteria must assure that an applicant can meet its agreement obligations. And principle F, contractual operational criteria must ensure compliance with ICANN policies. Those are, like I said before, all but one of the principles in the GNSO recommendations document. Next, recommendations 1 and 9 -- and let me just comment briefly. I'm sure many are puzzled why we're covering the recommendations in the order that we are. It's so that it's more meaningful. In the actual development of these recommendations, the work was very intensive and we didn't have the picture that we have today. So you'll see that the recommendations were numbered as we covered them rather than in some sort of a coherent way. So please forgive us for the -- mixing the recommendations up. But we do believe that that will be a much more coherent experience for you today. Recommendations 1 and 9 say, implement a new gTLD process that is fair, transparent, nondiscriminatory, and predictable, with objective and measurable criteria fully available before initiation of the process. On this -- on these recommendations, there was very strong support -- in fact, it could very well have been unanimous. I don't recall right now -- four objective criteria. We also recognize that some criteria are easier to measure than others. So a question that comes up with regard to this one, should more subjective criteria be excluded? Should some stakeholder interests be ignored to ensure objective measurability? You'll see as we go through these that we tried to reach a balance there. We don't -- We think that the answer to both of those questions is "no." We will always -- We try very hard to make criteria as objective as possible. But, frankly, there are some recommendations, as many of you have already noted, that that's a much bigger challenge than others. So our decision was to try to address all stakeholders' interests while making criteria as objective as we could in each situation. Implementation guideline A is that there should be a predefined roadmap available. And, basically, what that means is that any applicant that's even considering applying for a new gTLD should know in advance what's involved in that. And that's our goal. And that's a guideline that we have provided to staff. Recommendation 2, strings must not be confusingly similar to an existing top-level domain or a reserved name. The rationale for this is that a confusingly similar string could cause technical or consumer confusion. Some of the implementation considerations there: A string that resembles another string is not necessarily confusingly similar. We recognize that. And this is one of those that, as implementation guidelines are developed, a lot of work will go into try and figure out ways to make measurement of that as objective as possible. Staff has been and will continue to explore various options for implementation of this recommendation, including possibly the development of an algorithm that would provide guidance with regard to confusing similarity. Also providing a capability for a formal objection process. So in addition to how this may be evaluated first time through, we're recommending there be the possibility for someone to object through a formal objection process of confusing similarity, and then that would be evaluated by an independent third party, as you'll see when we get into the last section more clearly. Recommendation 4, strings must not cause any technical instability. We didn't have any disagreements on this one when we developed it. This was one of the easier ones. And the criteria for what that means will be in the RFP. And the review of that is expected to be done by ICANN, drawing on technical expertise as needed. Recommendation 7, applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. Now, it's important to understand with this one, we spent quite a bit of time, even on this one, although it seems like a fairly straightforward one. But it is the recommendation of the council that there be minimal technical criteria for all applicants to ensure security, stability, and interoperability of the Internet. Same for everybody. Other technical requirements may vary depending on the purpose and use of the TLD. Applicants will have to demonstrate that their operation of the new gTLD will not adversely affect security and stability of the Internet. And of the DNS. Recommendation 8, applicants must be able to demonstrate their financial and operational capability. This is another one that we spent quite a bit of time on. And it's the belief of the committee that developed these recommendations and the council in approving them that financial and operational obligations may vary depending on what is proposed by the applicant. Principle E states that, "A set of capability criteria for a new gTLD registry applicant must be used to provide an assurance that an applicant has the capability to meet its obligation under the terms of ICANN's registry agreement." Applicants will be assessed to ensure that their operation of a new gTLD will not adversely affect security and stability of the DNS and that they are capable of implementing the gTLD in the manner in which they have proposed. Recommendation 13, applications must initially be assessed in rounds until the scale of demand is clear. And our recommendation to staff in this regard -- and this is a big one for us to ask them to do. We're cognizant of that. They are very well aware of it -- suggested that ICANN, to the extent possible, staff to accommodate what are demand occurs, while recognizing that it's really not possible to accurately predict demand. The intent of this recommendation is that applications would be processed in rounds until such time that possibly an ongoing application process could be put in place. Okay? It's expected that the date for a second round will be communicated in the RFP for the first round. Within a round, all applicants will be evaluated on the same grounds, i.e., order of receipt within a round will not be an evaluation criterion, nor will it be used to resolve string contention, but will only be considered with regard to processing order. So it's anticipated, as you will see later, that there will actually be at least a 30-day application period. There will be no advantage in terms of whether or not an applicant is awarded a TLD whether they submit it on the first day or the last day. But if, as we predict, there are lots of applications, the processing order will be in order of receipt during that period. Implementation guidelines C and D you can see on the screen there. Leading up to this process, especially the application period, ICANN -- we're suggesting that they need to provide frequent communications with applicants and the public, including comment forums. So not only leading up to it, but throughout the process. As previously indicated, D says, a first come, first served processing schedule within the application round will be implemented and will continue for an ongoing process, if necessary. Applications will be time and date stamped on receipt. But keep in mind, order of receipt in the round will only be used for processing order, not for evaluation. Guideline E, the application submission date will be at least four months after the issue of the request for proposal, and ICANN will promote the opening of the application round. Now, the rationale for this is to allow time for adequate and broad communication of the round within ICANN circles and hopefully without ICANN circles, so that not just insiders will be aware of this. And number 2, to allow entities adequate preparation time to prepare their responses. The thinking here -- and I'm sure most of you can figure it out for yourselves -- is is that we didn't want to advantage just the insiders, because they know what's coming, we want to make sure that some new players that maybe haven't been as close to the ICANN activities in this regard as possible, plenty of time for them to prepare if they want, while at the same time making sure that they're aware of the fact that there will be a second round. And that date will be communicated. Implementation guideline B says, application fees must cover costs. And fees may vary. As you'll see when we look at implementation details a little bit further, the thinking here is -- and I probably should leave this to Kurt, but I'll -- since I started, I'll make a little comment here -- another -- there will probably be an initial application fee that would be the same for everyone. In some cases, they will require more extensive evaluation, possibly because challenges are filed or things like that. When that happens, the parties involved in those challenges would incur additional costs that wouldn't be borne by the initial application fee paid by everyone. N, ICANN may develop a fee reduction model for applicants from economies classified by the U.N. as least developed. Now, keep in mind, and it's probably good, especially with one like this, to understand that these are called "guidelines." They're not our official list of recommendations, but they're what the council would really like to see happen if it's possible, and certainly we talked a lot about the issue of what about regions of the world where application costs may be very expensive. It is important for ICANN budgeting that the costs of the application process be covered. At the same time, how could we -- Is there a way to help possible applicants. Now, that gets very complicated, and Kurt will talk more about that. Some of the issues here, could an applicant that cannot raise the fees still be able to raise the capital to meet security and stability specifications. That's a legitimate question. Another issue, how would applicants from a least developed economy that can afford the fees be distinguished from those that can't. A third one, how would situations be avoided where potential applicants try to take advantage of any exceptions? So it's not a simple issue to deal with. And I'm sure many of you can think of quite a few other issues there as well. With regard to implementation plans, and I guess I essentially covered this ahead of time, costs for the initial evaluation will be covered by an application fee, and if there are additional steps necessary, those would be borne by all parties utilizing those processes. Not only the applicant, but also the objector. Now, there is concern that financial disparity between the applicant and the objecting party may result in undesired outcomes. It's a legitimate concern. And that will be kept in mind as implementation guidelines are worked on after board approval. Guideline M. Consider establishing a support mechanism to facilitate effective communication that no longer requires all participants to know English. O, provide information about the new gTLD process in major languages other than English. ICANN already plans to publicize the new gTLD process in different languages. But it hasn't yet been finalized which languages those would be other than English. Staff -- Our recommendation or the guideline we recommend is that staff should select the languages that would most effectively communicate the implementation to a wide audience. Now, I'm going to turn the remote over to Kurt so that he can talk about some implementation issues from the staff. And again, let me introduce this by saying that staff has not just sat around waiting for final approval of the recommendations to work on implementation. They have been working most of this year. They may have started last year. A lot of work. And the committee, the council has interacted with staff, and they are working very hard on this already, and a lot of work has been done. But as you will see, there's a long ways to go, and I will let Kurt talk about that. >>KURT PRITZ: Thank you, Chuck. As Chuck pointed out, there's a ton of detail to this, but I think there's a big message to this, especially to this section. For all the strings that are out there, the potential strings that are not controversial, what the council has directed staff to undertake is to provide a clear, predictable roadmap for the application of strings. For the application and process -- the application process for new TLD strings. So that should include things like objective technical and business criteria, pre-published contract terms, evaluation criteria, and a dispute resolution model. And so what we're taking away from this, then, is that ICANN will publish an RFP, and an RFP is a solicitation for TLD applications. And we'll publish this RFP that will clearly define the time line where applications will be considered. It will clearly define for each of several evaluations what the process, procedure, and standards are for those applicants who wish to pursue delegation of a TLD. So just basically the applications has happened before, especially in the startup phase, will be considered in rounds. So there will be a round with an opening date and a closing date. And then those applications will be processed in the order that they are received, but essentially all the applications will be considered in that round. So, for example, if two applications are identical, then those applications will be considered together and it won't be first come, first served situation for the first one received. And then additionally, the RFP, as I stated earlier, and Chuck stated a couple of times, will include a base contract that the applicant will eventually sign if they are approved for a TLD. So the RFP will contain several evaluation points, and these are most of them. It will specify baseline technical criteria, a set of objective criteria where the applicant can demonstrate that they are able to competently operate a registry. So this will be such basic things as fulfilling some Service Level Agreement with regard to up time and response times, but also might include such things as working to protect the registrants against spamming, phishing and things like that. There will also be a set of operating or financial criteria where the applicant will demonstrate a basic business plan. Of course the issue there is to what extent should the application materials be a guarantor of a successful startup and stable operation. So that should be considered as we write the RFP. And of course the string itself on its face -- slow down? Thank you, Sebastian. Somebody get a "slow down" sign for me. Of course the string on itself should not affect in a negative way the technical stability of the DNS. So one example of that might be a string that's purely numbers that might be interpreted as an I.P. address by your computer or by the software. And then of course the string should not be on the reserved names list, which is a pretty black-and-white tests. Strings also should not be confusingly similar either to an existing TLD or to another application. So there are a couple of ways of deciding that. Chuck described one way, which could be that an independent panel considers the applications and determines by some objective means that are written whether or not two strings confusingly similar. Another might be a mathematical algorithm, sort of the inverse of a spell check where a set of open source code could be used to determine whether two strings met a test to be identified as confusingly similar. And then of course if you can do that in ASCII, the next challenge would be to do that for IDNs. So that will be very interesting work. And then finally, there will be -- and we will talk about this in later part of your presentation, but there will be limited grounds for objecting to a string. So these elements you see up here are sort of the headings for the initial evaluation of any TLD application. As Chuck also mentioned, communications is a very important part of this whole exercise. It's important that extended outreach efforts be used to ensure that the widest possible audience is aware of this opportunity in the DNS growth. And the communication will describe the policy development process, the reasoning behind the policy recommendations, and then of course the TLD, the top-level domain evaluation criteria themselves. There's some pretty interesting aspects to the plan. It will have to have multilingual features, and that means ICANN will not only have to communicate out in different languages but will also have to receive communications in different languages. And it's intended that some communication, some direct communication, reach every country or territory in the ISO 3166 list as a sort of matrix attempt. At least there a checklist that every jurisdiction be reached. So some of the implementation issues associated with this section of the presentation are these. One is the communications task is somewhat daunting. So how do we go about informing people in governments outside ICANN? And ICANN has at its disposal many tools. It has our regional liaison network that has already created quite a network of Internet users, Internet community members worldwide. We also have the constituency groups. The GAC, the ccNSO, and other constituency groups that reach around the world. We will also use public communication, so there will be some form of paid placements in periodicals and there will be news stories to announce what we think is a very newsworthy event. And the other part of communications, then, is securing that multilingual talent to both go make -- provide communications out and receive communications in. And I already talked a little bit about fashioning business and technical criteria that will -- that will have to be determined to what extent that's a predictor of success. And writing stringent criteria sometimes prohibits some form of innovation. So the criteria will have to balance that writing very objective baseline criteria with allowing for innovation and innovative models. One of the basic ideas here is to provide for innovation in the DNS. I also mentioned confusingly similar strings and the opportunity to use an algorithm, perhaps, to do the testing there. And then the final challenge with this round has to do with staffing. Are we going to receive 4, 40 or 4,000 applications? There is great of economies of scale to be had there. The application fees and costs kind of depend on the number of applications received. And then finally, one of the bars to delegation of TLDs is the process by which new TLDs get delegated. There's an administrative portion at ICANN, there's an administrative portion at VeriSign, we use IANA services portion of ICANN to do a lot of this work. So growing that in the face of somewhat unforecasted demand is going to be very challenging, but I think fine. So the time line is essentially what we've talked about in meetings past. We're working out -- The tall poll to this strangely is the communications plan where the council has asked ICANN to provide a four-month notice period before we post the formal request for proposal or the solicitation for TLD applications. So taking that into account, and with a presumption that the board will approve some sort of the -- some form of the policy recommendation in the relatively near future, we expect to post a draft RFP in the second quarter of next year and the final RFP in the early quarter of next year. Finally, there's costs and fees. And so there's no numbers on this page. But there are startup costs which are substantial. There's $1.8 million in the current year's ICANN budget for this startup effort. There was a lot of uncertainty in fashioning that number, so at one point we were looking at numbers double that. And certainly we looked at numbers less than that. Those startup costs are legal fees and consulting fees in developing the RFP, the solicitation for TLD applications. Creating dispute resolution processes, the communications program that I described earlier, and finally, wiring all that stuff together into some sort of web-based application system that's easy for applicants to use and easy to understand. And then once the RFP is launched, we'll have operating costs associated with evaluating the proposals, and those are there, too. The dispute resolution costs and the evaluation services of independent panels. The resolution of other forms of conflict, and then just the support of that. So I think there's a -- The council has indicated that this should be a cost neutral exercise. I think at the end, we're going to cost all this out, and I'm not so sure there's not going to be some pricing exercise after that that will take all the cost, divided by a projected number of applications and check that for reasonableness, and then, you know, we don't -- with the objective that we don't want to create a barrier to some bona fide applicants. So that's essentially my reporting on the implementation work so far in this section of the presentation. So I'm going to hand this back to Chuck. >>CHRIS DISSPAIN: Thank you, Chuck, thank you Kurt. We are coming to the first comment and question session. Before we do that, there's a fair few extra people in the room than were here at the beginning and we missed a couple of slides anyway. So if you don't mind, can we just go back to the third slide, which is headed "workshop goals," and we'll just start from there. Just to give everyone some guidance of how we're going to structure this. It will only take a couple of minutes. Workshop goals. That's the one. So just for those of you who came in after we started, the goals of today are to give you a complete but brief overview of the GNSO recommendations for the introduction of new gTLDs. And that includes the major issues considered, the rationale for the decisions, and the implementation and planning progress to date, which is what you have seen Chuck and Kurt do for this first section. It's important to note that a side effect of what you say in this room today is going to provide useful -- hopefully useful input to the board in their decision-making process. And if I could just have the next slide up? Thank you. And again to reiterate, the panel presentation, you have seen that. The staff presentation, you have seen that. And now we have open discussion, and the way that's going to work is people from the panel can make comments. Then we will audience questions and comments, online questions and comments, panel responses to those if members of the panel feel the need to respond, and also, of course, the GNSO councillors are welcome to make comments as well. The next one I want is just important points to note. That's it. It's really important to understand that the GNSO council has already approved the recommendations in this report, and they have approved that by a supermajority vote. In this particular case, this report was approved by 19 out of 23 GNSO councillors voting in favor. And the next step in this process is for the board to act on the recommendations. Only the board can approve the policy. So after board approval, the implementation issues could lead to the need to consider changes. So things that staff come up with based on implementation may mean that changes need to be made. If that were the case, those changes would obviously come back to the council and also go out for comment. I think that covers the areas we need to for that. So the first step, then, is to ask for panel comments on any of the on any of the slides presented by Chuck or Kurt. No? Okay. Yes, Ute. >>UTE DECKER: I wanted to take this opportunity to maybe mention two issues that were discussed and the process leading up to the point where we are now that are not immediately apparent from the documents we have in front of us. One is the question of demand. We now do not require applicants to demonstrate that there is a demand for the new gTLD, and there's been a lot of discussion in the process. The way they are coming out is now we assume that nobody would make an application and go through the pain and the financial risk of going forward also they had already established that there was a demand. And I hope this is going to be the case going forward because as much as new gTLDs are going to be wonderful in opening consumer choice and diversification, there's also, of course, with every new gTLD a risk of a new playing field and new mischief from cyber crime and cyber squatting. So I think the demand point is something to be borne in mind as we see the experience with the first round of applications. The other point is sort of on recommendation 8, applicants must be able to demonstrate their financial and organizational operational capability. We do not explicitly require that applicants can provide a mechanism to protect the rights of others at the second level, to provide a mechanism to resolve any trademark issues that stem from that. And this is certainly something that has been discussed and that I'm sure we will discuss in other pending sessions and will become more obvious, but I think that's also something to bear in mind. >>CHRIS DISSPAIN: Thank you, Ute. Does any other panelist have anything to say at this point? Do we have any comments from the room? If you would like to make a comment, the microphone is here in the center of the room, or if you are Dr. Cerf, your microphone is here on the table. Go ahead. >>VINT CERF: I hope everyone understands the reason I am up here is not to invade the panel but I hear better with the headset so I appreciate the accommodation. I have three questions and -- four questions. With regard to recommendation number 7, there was a word "minimal" in that recommendation. If it's possible for you to bring up the slide, it would be helpful, because the term was ambiguous as I read it. And there was one interpretation which probably wasn't intended. That's 8. Here we are. The first bullet reads "there will be minimal technical criteria for all applicants." One interpretation of that is to say that it is a ceiling, that is to say there is hardly any technical criteria to ensure security, stability, and interoperability. Another interpretation is that there will be, at minimum, a floor of technical criteria to ensure security, stability and interoperability. I assume it was the latter that was intended, but may I have confirmation? >>AVRI DORIA: Yes, the ambiguous wording is in the slide. It definitely is the latter, that basically there is a floor of technical. There may be more criteria for those who are intending a bigger or more complex operation. >>VINT CERF: Thank you. >>AVRI DORIA: And the intent was to make sure we didn't impose large requirements on little guys. >>VINT CERF: Okay. Perhaps if there are opportunities to assure clarity there, it might be advantageous. The second question has to do with guidelines C and D, and it is to do with the way in which the rounds are implemented. FIFO -- first in, first out -- was referred to. What I am wondering is, if you really process them in the order in which they were received, can one of them get stuck? And even if you have the capacity to move in parallel, would you cease processing? If that's not intended, perhaps you can clarify. >>AVRI DORIA: Yeah. The processing -- and in fact, there's a very complicated diagram that the staff has been working through on all these. And in fact, very often -- One thing I should have added is we would make a recommendation on implementation guideline. The staff would try to see, gee, how would I implement it and they would come back and they would ask questions. In this case, certainly -- and in fact I saw the quizzical look pass your face as it was being read, is first of all, there is a certain batching that is done when the first load comes through. And you look at various things, like the name contention in the first place. At any point at which something runs into an objection, a barrier of some sort, the rest of the things keep going. It moves into a side path. You know, I kept using the terminology of a fast path and a slow path. And basically that things would move into dealing with the objection process, dealing with whatever that barrier might be, and then they would get back into a processing queue and in that queue they would again have, you know, the advantage at the next step. One of the things that isn't clearly spelled out in recommendations and is much more of an implementation detail is how a certain amount of batching, a certain amount of, you know, economy of scale can be used. So we're recommending, certainly, a first in, first out ordering. But when the staff can see an economy of scale in doing something in a batch, that's not at all against the recommendations. >>VINT CERF: My biggest concern was merely that we not have the entire process coming to a grinding halt because a particular issue arose with a particular proposal. I would counsel avoiding fast and slow and rather simply different track. The next question had to do with recommendation N. And this was related to concern about costs for parties in developing countries. And there are a number of different cases that one could be concerned about. But the one that I wonder about is, for example, a nonprofit organization with limited capacity in a developing country finding itself burdened because it's -- I'm sorry, in a developed country, in an industrialized country, finding itself burdened because it's in this well-developed country, but it itself has limited financial capacity. So I didn't know whether you'd want the criteria to be applied on the basis of an organization's finances or whether you feel the need to stick to the other criterion. >>AVRI DORIA: I'll put that one in again, because that was actually one of my favorite topics. And I think that we got to a point where it was certainly my personal view and the view that I organized was, yeah, anybody that can't afford it but can find the financial and operational means needs some sort of. But that was a very different criterion for people to come up with. So as a base level, the recommendation sort of took one of those compromise position and says, at the very least, when we're talking about that spread, we need to pay attention. There's other recommendations about thinking about it. There's external recommendations about whether other funding methods could be come up with to help organizations. But, yes, it definitely was a concern that got spoken about. This is, again, one of those base levels where everyone could agree that that is something that we need to pay attention to. >>CHUCK GOMES: Just a further response on that, then. My own opinion is is that as staff works on implementation of this guideline -- because it is a guideline -- it's hard for me to believe that the council would have a problem with some flexibility there if it seemed warranted. So it's not as if this is one of the firm recommendations. But -- in fact, I frankly hadn't thought of that situation, because we were so focused on the developing world. Very good -- very good observation. >>VINT CERF: Actually, I think a solution is hiding in something that Avri said. An organization in a developed area that has limited resources might find additional support from other sources if the intent and utility of their proposal is strong enough. So, anyway, I don't mean to suggest the solution. But it was an issue. The last -- thank you for being so patient. One last question. This is a very generic one. And simply put, I hope that someone will look through the -- both the recommendations and also any implementation proposals and ask the question, how can this be abused? Who could take advantage of this in a way that wasn't intended? Because we have discovered that the world outside is remarkably capable of finding ways around any rules you put in. Let me give you an example of something that might be considered an abuse. Someone decides that they want to have a top-level domain because it will serve their political purposes. They're well funded. There is no demand for it other than the fact that it would serve political purposes. And so they arrive with plenty of money. They're well equipped. It gets instantiated, but it's not going to be used by anyone. It is simply -- its existence serves a political purpose. I'm not suggesting that's the only abuse. But it's an example of one that might be considered an abuse. So I would urge that there be some attention paid to how this whole process might be used in had a way that wasn't intended. And that ends my questions. And thank you for your patience. >>AVRI DORIA: I'm not sure that everyone would necessarily consider that abuse. And as I indicated in the beginning of your statement, that everyone would necessarily consider that a particular abuse. In terms of the general notion of abuse, I think there's certainly been an effort, whenever we could think of it, to look at it. There's also sort of an assumption that these procedures, these recommendations, will be looked at after a first round. And we'll start to notice one of the things that I've certainly learned is that I can't possibly think of all the abuses, because -- and anytime I think of one, well, that's a good one, let me try that one, and then, of course, that opens up several more. So the notion that isn't quite in here is that after the round, all of this really needs to be looked at, because we know that there's certainly much that will be learned from the round. >>CHUCK GOMES: One more point. You mentioned not use the domain. You'll believe I -- I believe you'll see later on in the slides that we do have a guideline that any TLDs awarded should be used within some reasonable time limit. We didn't define what that is. That's an implementation detail to work out. But we did think about that particular aspect. We did try to -- we did spend some time thinking about those things. But as has been already pointed out, thinking of all of them is a challenge. But good point. >>MIKE RODENBAUGH: I think also not only will we wait and re- evaluate after the first round of applications, but a lot of those potential for abuse, of course, is in the details of the implementation procedures that are still, obviously, under development. So we're all going to take a very close look at those drafts once we receive them from staff. >>CHRIS DISSPAIN: Okay. Let's take our first question from the floor. Can I just remind you, please, to say who you are and also tell us what particular point or points you are talking about that we've presented up here so far. >>SEBASTIEN BACHOLLET: -- gives us the possibility to express ourselves in several languages today. I would like to thank all those who are participating in the implementation of this structure, and I would like to take the opportunity to speak to you in French. From the tee shirt that we were given, my language is French, so I will use this language. Thank you. My question is very short. And it is for Kurt. Would you tell us again, because I'm not sure I understand, would you tell us again at what time the proposal will be in the draft version and at what time it will be in the final version. I've had a hard time with the various quarters. Is it talking about calendar quarters or fiscal year quarters? Could you give us those dates in a more precise way? Thank you. >>CHRIS DISSPAIN: I'll try. >>KURT PRITZ: Translated for me. >>CHRIS DISSPAIN: I didn't think you were that good. >>KURT PRITZ: Just for a joke, I'd try out some of my French, but it wouldn't even be funny. Chuck, can you bring up the slide for the timetable? Thanks very much. So a draft RFP would be posted in the second quarter. So that means between April and June of 2008. Now, an issue is that we don't want to give an unfair advantage, say, to ICANN cognizetti or those that watch the ICANN Web page. So I think what's required for that publication is a very broad publication of the draft as part of the precommunication to ensure that there's a global notice that the -- this opportunity is coming. And then after public comment about the comparison between the policy recommendations and the implementation of those policy recommendations as embodied in the RFP, that solicitation for applications for a TLD, we would post the final RFP, which essentially requests submissions. And in the project plan, that's scheduled for late July, but as I stated earlier, that might be plus a month or so due to the requirement that we want to be able to make sure our communications plan is as effective as it can be. So, Sebastien, I hope that answers your question. >>CHRIS DISSPAIN: Okay. Next question, please. >>KARL AUERBACH: Hi. I'm Karl Auerbach, and I have two observations. The first is, there are legacy applicants from year 2000. There are 40 of them who have paid $2 million to ICANN. And they are still pending. And they deserve and you are obligated to give them priority. You have been stringing them along for far too long. Now, secondly, about a year ago, I sponsored a play. It was George Bernard Shaw's "Pygmalion." It's about a man who created a statue so beautiful he fell in love with it. ICANN has fallen in love with its own image of the Internet. And it will exclude any image that doesn't fit into its preconceptions. What you are doing through this process is banning completely lawful activities on the part of the creative minds. This should be reentitled "The Suppression of Innovation and Creativity on the Internet Act." Because you are only allowing those new TLDs that meet your notion of what is proper behavior. The Internet itself would not have been able to grow if the telcos had had this kind of rule over the mentality from which the Internet grew. Anyone who promises to abide by published, broadly practiced technical Internet standards should be allowed to run a TLD. It's not in ICANN's role to make judges of social policy, goodness, economics. When did ICANN become this consumer protection agency? When did ICANN become this government? It's just a microgovernment. When did ICANN get this power? From where did it come? And on top of that, most countries do frown on incumbents, such as Verisign getting together and establishing the terms over which other people can enter the marketplace. We tend to call that restraint of trade. Now, ICANN is walking a very narrow line. Maybe it's illegal constraint of trade. Maybe it isn't. Maybe it is in the E.U. Maybe it is in the U.S. Who knows. But, nevertheless, you're walking a line that has historically been frowned upon by those who believe in free competition of ideas and creativity. I suggest to ICANN that this whole process should be abandoned and replaced by a simple system in which the applicant comes up and says, "I would like a name. I would like a slot in the root. Here's my name, here's my address. I promise to abide by written, broadly accepted technical Internet standards. And if I promise, you should throw me in the queue and throw me into your lottery, throw me into your auction," or whatever. But that should be the limit, and the application fee should be merely the charge to process that, which I suggest is about five bucks. Thank you. [ Applause ] >>CHUCK GOMES: Karl, I just want to respond to part of that, not all of it. I do want to let you know that the committee did look at that particular approach, extremely minimal criteria, both in the case of financial and operational. And we grappled with that some. You'll note the way the wording was on the recommendations -- and I know it doesn't satisfy what you're suggesting, it's a far cry from that, so I'm not arguing with you there -- but the wording was crafted carefully enough so that there is variance, depending on the needs of the TLD. It's not minimal, like you're talking about. I'm not claiming -- >>KARL AUERBACH: Who are you to judge the needs of the TLD? Why did the Google guys -- they just did their thing. >>CHUCK GOMES: Karl, we have a PDP process -- >>KARL AUERBACH: No. You have a constraint of trade process. You're an incumbent. You've already got a billion dollar industry in your company. >>CHUCK GOMES: I'm not going to debate it. I would have been glad to talk about it. But let's go on. >>CHRIS DISSPAIN: Yeah, we need to move on. Otherwise -- is my mike on? Okay. Sorry, I can't hear myself. So -- next. >>KEN STUBBS: Yeah, my name is Ken Stubbs. I'm here as an individual. And I feel like the fellow on the variety show that just followed the act with the kid and the dog. I'm -- right off the bat I'm in trouble there. But let's take a concern that I have that I'd like to have you address. My concern is this, basically: Over the last 18 months, we've had a significant amount of upheaval as a result of financial problems that came -- that surfaced with one of the registrars, with one of the ICANN-accredited registrars. I'm concerned about the fact that there does not appear to be as much significance applied to the capacity of a proposal to effectively manage the names in the future -- and I'm talking about financial as well as administrative capacity. And if we're going to give out new TLDs to people, we need to understand that there are people in the public who will register those TLDs and that there is a basic assumption that they're going to work. And I think that ICANN has to look very, very closely at the idea that you can't just rely on the fact that you'll find somebody to bail them out if we end up in a situation like that in the future. So I think you really have to take a look more closely in the process at the ability of the proposers to be able to manage this on a continuing basis. Bringing a few dollars to the table at the beginning does not -- Chris, you've been involved in managing space. You know what I'm talking about. It's an ongoing -- there's a presumption of a going concern here. And that's my comment. >>CHRIS DISSPAIN: Does anybody want to respond to that? >>MIKE RODENBAUGH: Briefly. I think it's an excellent point. It's a huge concern of the business constituency, of course, as well. And I think it goes a long way to actually refuting the previous speaker. By the way, my name is Mike, not mark. I think it goes to the notion that we really need to take a close look at the registry failover procedures that I know staff has been working on. And it's certainly something that we're tracking. >>CHRIS DISSPAIN: Avri. >>AVRI DORIA: I actually think -- it's actually interesting, having had the two questions at the same time, because that really does represent kind of the -- some of the extremes that we were working within. That is the reason that there is a recommendation that says there needs to be a judgment of financial and operational capability. It's a reason that there isn't a statement that says there has to be a business plan that someone can -- and it is, indeed, one of these places where we did find ourselves in a balance between you come, you pay your five bucks, and you get it, versus you've got to prove to us that you'll be here as long as a 20-year company will be here, trying to strike a balance between those two extremes. >>CHUCK GOMES: And just to add on to that, keep in mind that the group really did grapple with these issues. It wasn't as if we didn't consider that. What we ended up with was a recommendation that there was strong -- that most in the group were willing to support. And that's what the consensus process is about, in our understanding of that. So did we make everybody happy? Perfectly happy? No. But we did reach a recommendation or recommendations that most would support. And keep in mind, that's true all the way through this. >>CHRIS DISSPAIN: Tony. >>TONY HARRIS: I'd just like to remark that I believe in the previous round of applications, I think this was probably done by the applicants themselves, perhaps not required. But some of them did state what would happen if they defaulted from their obligations. In other words, who would take over what they're leaving behind. So I think applicants would probably tend to include this as an added value factor for the evaluation process. >>CHRIS DISSPAIN: Kurt. >>KURT PRITZ: I'm going to steal some of Steve Crocker's words here, but I thought these were all good comments. And Karl's statement and then Ken's statement all surround what happens to registrants during this process where we delegate and then launch these new TLDs. And I think that needs to be a focus of this, that as we consider the business criteria and as we consider how that might prove up their ability to sustain ongoing operations, and then what happens if someday, as seems inevitable, that a registry fails, you know, how do we address the needs of the registrant that have invested not just their money, but a lot of themselves in their part of the business that's tied around this new gTLD registry. So I think we should take each of those comments in that context. >>CHRIS DISSPAIN: Thanks, Kurt. Next question. >>VITTORIO BERTOLA: Thank you. Vittorio Bertola speaking personally. And I start from a consideration -- I was struck when I started to read the principles by how you defined the process. You stated -- I mean, TLDs have to be produced in a timely, orderly, predictable manner, which is a typical business approach. So you seem to want to provide something -- yeah -- which is conducive to an orderly business proposition. And I'm wondering whether you actually considered other possible properties of TLDs. I think that many of the applications that will come will be for cultural or political or social purposes. Yes, there will be many for-profit ones. But I think we're going to see new ways of interpreting TLDs. So you should be careful considering all the recommendations you put forth under different possibilities. >>CHUCK GOMES: Vittorio, we actually hope that there are lots of those. And there certainly was no conscious intent in the wording here to favor those that are just for a commercial purpose. I did read your comments, by the way, before the meeting. And I hope that there's nothing in there that really favors business entities. What was happening there with regard -- a lot of the wording there was that in past processes, they have dragged on. They weren't timely. And we're trying to communicate, let's make this predictable and so forth. It needs to be predictable for the entities you're talking about as well as the business-oriented ones. So I think we're in agreement with you on that. >>VITTORIO BERTOLA: Yeah. The more effective it is, the cheaper maybe it will be, so it will also be easier for not for profits. Okay. So my question is, the first one is about requirements. I'm not entirely buying Karl's comments, but I'm buying many of them. I had the experience -- I mean, until one year ago for ten years, I have been using as my primary e-mail and Web address, a top-level domain .EU.org, which is a for-free registry you get for free with your domain names. It's run by some people in their spare time and possibly on a Linux box or under someone's desk and yet it's been working for ten years, and I never had one minute of outage. So, actually, most of the innovative things about the Internet were born on someone's -- I mean, a Linux box under someone's desk. So I do buy that you have to have requirements and you have to check. But I think maybe what you have to check is the capability of the people that show up rather than whether they -- I mean, they have $1 million or whatever. So my question is, what do you mean by "demonstrate"? You say that applicants will have to demonstrate capability. Do you imagine that will be, for example, (inaudible) what does it mean? And I was wondering whether you consider the idea that has been floating around for a while of a two-stage application fee so that you pay for having your domain -- your application examined, and if you are approved, you pass the requirements, then you pay a second part, pay for the actual setup and negotiation costs. Because otherwise, if you are rejected, you're paying for something you are not using, actually. So you could actually do that. And the final question is, what I guess the implementation guidelines were the result of a compromise. But I think it would be much better also for ICANN's public image if those "mays" would become "musts." At least for two of them, I don't really see any real problem in providing application forms in three or six languages and all the information. So I'm wondering whether -- why didn't you just do that? >>CHRIS DISSPAIN: Who wants to respond to that? Kurt. >>KURT PRITZ: I'll take -- Chuck, maybe I'll take the first two, which are implementation, and the last one seems like a policy-directed question. So I think the capabilities that are required and how those are demonstrated are implementation, you know, questions. And this sort of input and the public input for it are established so we can write criteria. I think the most important part of that is that the criteria should be sufficiently objective so that when you fill out an application, you should be able to look at the criteria and your application and say "i have passed" or "I haven't." So the thrust is to make them really clear. So the applicants can determine the risk before they apply and not after. And I think that's been the direction of the council to us. And I know that several versions of fee constructs have been considered. One is the one you just suggested. There's also one where you pay an initial fee, and then if there's an extended evaluation of that application, then there would be an additional fee and the applicant could decide, given the additional cost and time and risk, whether they want to continue or not. So I think that's a good suggestion. Another suggestion has been if there's demand for TLDs above that that's forecast, then the fees be reduced in some way retroactively. And then there was a policy question, I think. >>CHUCK GOMES: Yeah. I think I can answer your question, Vittorio, with regard to the "mays" that are in some of the language. First of all, I believe it's fair to say that we weren't quite as careful with the words used in the implementation guidelines as we were the recommendations; okay? Because they are guidelines. There were certainly people on the committee that really would have liked to have seen stronger language there. I think because of the fact that it is a guideline, all of us on the committee and the council would really like to see that, if it can be done. I think one of the questions is, and Vint's question kind of illustrated part of this, there are lots of ways it can be abused. How do you do it so that it's fair, and so forth. So I think that's part of the reason why, in some cases, you saw a "may," because we did not spend enough time, nor did we have enough time considering everything else to do that. It's something that we would like to see happen in implementation, but when we get down to see the details, will it work? We hope so, but we don't know. >>AVRI DORIA: If I can add one small thing on that. One of the differences between the recommendations and the implementation guidelines is very -- in the recommendations we were always sure we were in a policy area. In the implementation guidelines, we were really trying to sort of set of direction on things that were largely determined to be implementation issues. And so that was a large part of the difference between those two, and therefore, a large part of the difference in kind of language used. >>CHRIS DISSPAIN: We've gotten minutes to go before we break for the -- the session for a break, so I am going to close the line off where it is and can I ask you to be brief, please. >>JORDYN BUCHANAN: Hopefully. I am Jordyn Buchanan, and I am speaking only for myself. So I want to make a couple brief notes on two of the recommendations, but first I want to note that I am very pleased that there are recommendations and there seems to be a time line when we will have additional new gTLDs. So I would much rather that goes ahead than any of the tinkering around the edges actually takes place. Having said that, I think there's a couple of places where at least we could clarify the intent or the ongoing -- how exactly we're going to implement things and where the language is somewhat broader and ambiguous. Specifically with regards to recommendation number 4, which I think you indicated isn't very controversial, but strikes me as being basically impossible, which is that it must not -- that the stream must not cause any technical instability. It's probably impossible to predict whether this is actually true without actually throwing things out there and seeing what happens. And certainly I would hope that we're willing to take some degree of technical instability. Maybe not very much, but some tiny amount of technical instability in exchange for opening up the space. So, for example, if we have figured out there was one version of someone's name server software somewhere that crashed on a particular string and 17 name servers in the world were using it, I would hope that we wouldn't stop rolling out that TLD because there was some technical instability caused by it. I think the word "any" is very strong there, and I think hopefully as we go through the implementation process, we will clarify that to be somewhat more -- somewhat more useful reading so we're not looking for minor nits to slow down the process. And finally regard to recommendation number 7 which relates to the confusingly similar strings, I certainly echo the footnoted comment that Avri made that it seems much more like a trademark or legal issue than a technical issue. And it seems like probably somewhere where ICANN shouldn't be spending very much of its time. I will note that if it is going to be a legal or trademark thing, we are missing the other half of that equation which is when something has to be confusingly similar and it has to be used in that way that is confusing as well. Here it seems like we are saying the string in and of itself might be somehow be similar without regard to how it may actually be used. I would hope as we look to see whether things are confusingly similar or not, we would take usage into account. At least in situations where there might be multiple potential interpretations of a particular string. The other thing I would note is I really do like the idea of having something algorithmic in order to have these tests to happen. That would allow applicants to check their strings in advance, and they would not have to waste a lot of time and effort if it was going to be deemed to be confusingly similar at a later time. I would note it's probably going to be really hard -- >>CHRIS DISSPAIN: Jordyn, can you slow down, please. >>JORDYN BUCHANAN: Jordyn it's going to be hard to do that without a narrow interpretation of this. So I think it's obvious that if you are something like using a string that looks exactly like dot com using some Unicode characters, that's probably definitely confusingly similar and we can figure that out in advance. There are a lot of things that might sound or sort of vaguely have something to do with dot com that will be very difficult to figure out algorithmically in advance. And I hope if we constrain ourselves to a verry narrow interpretation of what this means, we'll be able to write the algorithm and be successful. And I'll stop now because I talk way too fast. >>KURT PRITZ: Very briefly, our preliminary look, and we need to give this a wider audience, indicates the number of strings that might cause instability is very, very small. And two is, well, I appreciate your comments on confusingly similar. So it's well taken. >>AVRI DORIA: The one comment I would add on confusingly similar, and you can see again that we had a very broad set of discussions, there's a lot of content in the document. And it was one of our harder questions in terms of determining that. And it's, again, another place where we settled on a compromise and those of us on one side of the compromise or the other stated our extra opinions for everybody to read. >>CHRIS DISSPAIN: Okay. Just before we go to the next question, we've got a couple of questions online. Can somebody get Kieren a microphone? Or, Kieren, do you want come up to this microphone? And just tell us -- Ask the online questions. >>KIEREN McCARTHY: Thanks. Sorry about that. There's an interesting discussion going on in the chat room, by the way. I have two questions, one is anonymous. Could you please provide us an update to the selection of the entity that will draft the RFP? Could you not hear that? Could you provide us -- >>KURT PRITZ: Briefly, ICANN received seven responses to the solicitation request, and they are being evaluated now. I think they will be -- You know, the process for evaluating the applicants was pretty clear in the statement of work that was issued, and ICANN will issue some update during the process to advise the community of the steps we're taking to evaluate the applicants, and then after that evaluation, then, you know, that will be forwarded to the board, I think, for approval. >>CHRIS DISSPAIN: Thank you, Kurt. >>KIEREN McCARTHY: And second question from Don Hollander, is there a technical limitation on the number of names that can be put into the root? >>CHRIS DISSPAIN: Is there a technical limitation on the number of names. Ah, okay. Go ahead, Vint. >>VINT CERF: This is a frequently asked question and often highly debated question. I think the answer is the root can stand substantial expansion, technically. You can probably put 10,000 names in the root and have it not collapse. The real issue is not so much the physical ability to put the domain names into the root zone, but, rather, all of the work that's associated with having something in the root zone. The work that's involved in making changes to the root zone entries for movement from one I.P. address to another, and any other interactions that might be necessary between ICANN and the entity that's to whom the top-level domain is delegated. So it's the administrative processes of both getting through an application and also in just day-to-day operation and servicing of a TLD operator that might limit the total that can be sustained. But the technical limitations are not nearly, I think, as constraining as the procedural ones. >>CHRIS DISSPAIN: Thank you, Vint. And thank you for being so patient. Next question. >>BHAVIN TURAKHIA: Hi, I am Bhavin Turakhia, I am with a company called direct I, but my comments and questions are just purely on an individual basis. I have got a couple of questions. I am going to try to keep this short. First question goes to what Chuck mentioned and I think there was a previous question. And I'm sorry if -- >>CHRIS DISSPAIN: Slow down. Slow down. >>BHAVIN TURAKHIA: I'm sorry if I'm not classifying these questions in the appropriate sections, but since there was a mention of it. This is with regards to the element of usage of a gTLD. And this sort of relates to two elements. There's a note inside -- I don't know if it's a recommendation or implementation or one of those elements, but there's a note inside that talks about -- >> Slow down, slow down. >>BHAVIN TURAKHIA: There's a note inside that talks about having to use a gTLD after an applicant has been awarded an gTLD. And there's also a reference somewhere else with respect to registrations having to go through an accredited registrar. Now, the question that I'm asking relates to both these points, which is what exactly constitutes use of a gTLD. Would, for instance applying for a gTLD for self consumption be -- >>CHRIS DISSPAIN: Can I stop you? We are going to have a full discussion on this in session 3, so I am not going to throw that question to the panel now because we're short of time. You need to come up again in session three, though. >>BHAVIN TURAKHIA: I will move on to the other questions. One is if anyone in the panel can throw some light on string contention and resolution. I'm afraid I don't have much of an idea, and I don't know if that's also being covered in this particular session. And then I have -- my next question is with respect to applications, is there any -- has there been any discussion on granting phonetic (inaudible) IDNs for applicants that basically apply for a particular string in, let's say, English or any given language. A couple questions for Kurt, is there any recommendations or assertions made on what potentially will be the size of the first round? And another question is, if the cost calculations -- and you spoke about sort of allocating the total costs across a forecast and the number of applications that you intend, you know, that you receive, if there's a difference, assuming you receive a larger number of applications than you anticipate, will there be some sort of refund process. Or vice versa or recalculation of that cost. >>CHRIS DISSPAIN: Stop, stop. Do you want to respond to any of those that have been asked so far? >>KURT PRITZ: Yes. My understanding of the granting of strings in IDNs is that -- is that presently, there would be one delegation for every application. So there wouldn't be a grandfathering or a duplicate delegation in an IDN or a phonetically similar TLD string, as I understand the present policy direction. And then the size of the round is dependent upon the demand, of course. So that's something I talked about. We're not sure if it's 40 or 400. And so I'm kind of dodging your question here, Bhavin. But then I will cost out, you know, this process, and then I think we'll make a pricing decision after that. And, you know, it's intended to be a cost recovery process, so we intend to fulfill that. >>CHUCK GOMES: And Bhavin, I am not going to give you much of the response but I am going to refer you back to the transcript when it's available. Several of the questions you asked related to implementation details which we have already said are going to be worked. And Kurt in some of his presentation responded to some of those. So I suggest you take a look at that and also go back to some of the detailed wording in some of the recommendations and guidelines. I would be glad to talk to you off-line, if you want. >>CHRIS DISSPAIN: Thank you. The line is closed. As long as they are brief, I will take everyone who is there, but no one else, please. Next. >>CHRISTOPHER AMBLER: Hi, my name is Christopher Ambler and some of you I have seen many times. A little under 13 years ago I applied for a top-level domain with Jon Postel at his urging. That was derailed by the IHC process which was derailed by the ICANN process. I applied again in 2000, and at that time the TLD I applied for, dot web, was also applied for by two other entities who weren't granted that TLD. And Dr. Cerf said at the time that he had, and I quote, some sympathy for pioneers. Unquote. And that dot web would be reserved for the next round. There is still some contention over this entire thing and coming up now on the 13-year anniversary of my beginning this process, I still, as far as I am concerned, have an application pending for dot web. We have been prepared to go live with it for 13 years. We have wanted to compete for 13 years. At this rate, with the current schedule, we'll be coming up on the 15- year anniversary when this finally goes through. So my question -- and honestly, I'm still quite confused, where do I stand? Is my application pending? Do I have an application at all? What happened to the $50,000 that I paid? When can we move forward? Will there be any grandfathering? And I hesitate to use that word, but will there be any consideration given to applicants who are still pending -- >>CHRIS DISSPAIN: I think we understand the question. Avri. >>AVRI DORIA: It's come up twice now. We did not consider it within the GNSO council. That is a board issue. It's probably a good question that you can ask, but it certainly is not something that we considered within our policy recommendations. >>CHRIS DISSPAIN: May I suggest that what you do is that you stand up very early to the microphone in the public forum session on Thursday morning when the board will be here, and you will be able to ask the board that question, rather than the council who didn't consider the issues that you are raising. >>CHRISTOPHER AMBLER: I'm curious why social issues, string contention, confusingly similar things, technical stability, all of the vast myriad of points were considered, but this one fundamental still- pending issue wasn't considered. >>CHRIS DISSPAIN: But it wasn't. >>VINT CERF: If I could just make one observation. It's not going to be directly to respond to your question now, but they were asked to say what to do about new gTLDs, and it isn't quite clear that yours is new. So I think you have -- no, so I think you have a reasonable question. You should raise it, but I think his idea to raise it in the presence of the board is a good one. >>CHRISTOPHER AMBLER: If it's not new, I would like to know where it is. >>CHRIS DISSPAIN: Next one. And I am cutting you short at one minute. >>SUSAN REYNOLDS: Hello. Hi. My name's Susan Reynolds. I'm speaking on behalf of Associacion Puntogal, which represents the Galician social and linguistic community. First of all, we think it's a really good idea to have other languages than English as this would open ICANN to the world's multiculture and diversity. We're also very happy to know that you have established an estimated calendar or timetable, and we would like to thank you for your efforts. Referring to this, the successful TLD application process is estimated in the first quarter of 2009. We would like to know if this is realistic. And if the potential applicants will have this timeline as a real reference to carry out our work, as this might involve some costs for the applicants. >>CHRIS DISSPAIN: Okay. Kurt. >>KURT PRITZ: I understand that concern. And I'm very sympathetic to it. I think the timeline is realistic. As with so many things in ICANN, there are some external dependencies on that timeline. And as we move in the implementation, we will be giving constant updates as to whether there's any deviation from that or not. Since the board has not officially approved the recommendations yet, the implementation hasn't officially started yet. But we've done enough work to have a fair degree of -- we have, you know, a detailed project plan that gives us a fair degree of certainty that we can meet those dates. >>CHUCK GOMES: Just a quick add-on there. Once the process is announced and that four-month period starts of communication, the timeline should be pretty reliable at that point in time. >>SUSAN REYNOLDS: Thank you. >>CHRIS DISSPAIN: Thank you very much. Last comment before we have a break. >>THOMAS NARTEN: Thomas Narten here. I have a narrow question or point. On confusingly similar strings, I've heard earlier today and even in the hallway beforehand that it would be nice if there was like an algorithm or some sort of computer program that you could plug two strings into and get an answer about whether they are similar or not. The question I have is, what work has been done to see whether that's feasible at all? Because, from my perspective, it's not at all clear that that's a very viable direction to go in, if that's even feasible. So I'm just wondering whether that's an idea that's been thrown out or whether that actually shows some real promise. >>KURT PRITZ: Most of the work to date, Thomas, has been in contacting people who write spell-check programs. So we've had discussions with a few. So I'd say between three and six of those people. And the purpose of those discussions is to get enough detail so that we could write a proposal for somebody to do that work. So the next step would be, then, to try to write a proposal to request somebody to help us with that. And, you know, certainly, you know, I'd like you and other people in the technical community to review that proposal to see what you think. >>THOMAS NARTEN: I guess my question is more basic, and that is, do we actually have sort of evidence for whether it is technically feasible to do that? >>KURT PRITZ: You know, I'm not the best person to answer that. But I think there are spell-check programs that work. And there's open source spell-check programs where you can actually adjust the parameters that, you know, give you an indicia, a numerical indicia of closeness. Theoretically, that could be used as a score. >>CHRIS DISSPAIN: Avri. >>AVRI DORIA: The other work some of the staff has been working on, they've also been looking at various research that's been done in homoglyphic sort of recognition software. So there is a certain body of research. Whether that research is practically usable yet is still an open question. And I've sort of been talking with some of the staff, looking at -- but there is a body of research that sort of looks at the glyphs and looks for, you know, sort of looking alike and measures. So it's still an open question, but there is more research than just the spell-checking and such. >>THOMAS NARTEN: Okay. Thanks. >>CHRIS DISSPAIN: Okay. Thank you very much, everybody. We're going to take a 20-minute break. That means that we will start again sharp at ten past 3:00. And there's coffee outside, I guess. But we're going to start at ten past 3:00. Thank you very much, indeed. [ 2:50 p.m. ]