34th ICANN Meeting Mexico City, Mexico 02 March 2009 Applicant Guidebook Q&A. >> Ladies and gentlemen, please take your seats so that we can begin our program. I'd like to introduce Senior Vice President, Services, Kurt Pritz. >>KURT PRITZ: Thank you, everybody. If you'll take your seats, we'll just take one more minute, okay? Thank you, Nancy. Okay. Can we get started, everyone? Thanks for coming in and I appreciate you taking a seat and letting everybody around you hear. So we're going to spend the next hour and a half talking about progress in the implementation of new top-level domains in the Internet. There's been meaningful and significant comment made to ICANN's first publication of an applicant guidebook. An applicant guidebook is the direction manual for those who wish to apply for a top-level domain. ICANN published the first version of it in October for public comment, with the anticipation that there would be significant change to it. For those of you who have had the opportunity to look at the second version, you'll see that there was a meaningful response to the public comment that there's significant change to the guidebook, there's lots of red-line in it, and it's -- and we hope that you see your comments reflected in that. So let's go through the agenda. I'm going to spend a little bit of time on background on the new gTLD program, and then discuss -- we're here to discuss, really, all the comments that have been made about this program in the last several months, and how those comments were addressed, analyzed, and then resulted in many changes to the new gTLD process in response to those comments. And then after talking about the process, we'll talk about some specific meaningful changes that have been made to the process specifically. So I hope that meets your needs. We'll have some time for questions and answers afterward. So I'm assuming this audience is a mix of, you know, experienced and new ICANN participants, and so with that in mind, I'll provide, you know, a very brief background to the new gTLD program, with pointers to where people can look in order to get additional information on it if you're not familiar with the program. The new gTLD program, the expansion of the namespace at the top level, has been in the contemplation of ICANN since its formation. A reference to it has been in every agreement that ICANN has had with the U.S. government since its founding in 1998, 10 years ago, to define and implement a predictable way for selecting new top-level domains. All that foundational paperwork going back to the white paper in 1998 that prophesied the formation of a NEWCO, stated that new TLDs would foster choice and competition for users of the Internet. And the white paper said that this new corporation should oversee a policy for determining how to implement these new top-level domains. Given that and -- given that, and trial rounds where selected new TLDs were introduced, ICANN's policymaking body, the generic name supporting organization -- GNSO, as you all know -- initiated a formal policy development process to provide direction to the company, to ICANN, for the implementation of top-level domains. It was a very intensive policy development process that took place over a year and a half. Several sessions at ICANN meetings, intersessional face-to-face meetings where people -- sometimes at their own expense and certainly at the expense of significant time -- met to determine these terms of references. So the policies sought to answer four basic questions with regard to the introduction of new top-level domains: Whether or not they should be implemented at all, and in what form; and if so, you know, what should be the string selection criteria, under what criteria should there be for strings; and another question would be how top-level domains should be allocated and what should the contractual conditions be for granting somebody a new top-level domain. The conclusions of this process were that new gTLDs would benefit registrants and provide additional choice. Another basic conclusion was that IDNs -- internationalized domain names -- should be introduced at the same time in order to foster full participation in the Internet in all regions. A primary consideration was that the new TLDs should not impinge on DNS stability or security and that also that various important interests and safeguards should be implemented in the system in its implementation. So translating these a little bit into the principles of implementation, the first in the work we're doing is a principle of care and conservatism. That we want to implement this process and procedure and the introduction of new TLDs with all due efficacy and efficiency and speed, but not at the expense of the protection of registrants and not at the expense of the DNS stability and security, whose interests are paramount. There's also an implementation principle that this whole process be a cost-neutral process to ICANN; that applicants in the process and those that will directly benefit will pay -- will cover costs. Another principle is that this procedure or this process provide a clear, timely roadmap to applicants, so applicants deciding to embark on this adventure know the route they must take and the criteria they must fill before starting. And finally, so what are those interests we want to protect? What are the safeguards we want to put in here? Well, TLD strings and labels shouldn't be introduced if they clearly incite misappropriate behavior or infringe the rights of others or are a misappropriation of a community label. So those of you that have spent considerable time studying this process see the processes in place that are intended to avoid risks to the process, risks to registrants, risks to Internet users, that are built in. So result of this policy development -- and I'm going to provide two charts that are a little bit difficult to see, but I'll also point you to the ICANN Web site where you can see them. But the result of this was, in very simple form, a process that's embodied in the applicant guidebook. So you can see -- if you can see, the applicant guidebook is divided into modules that map to stages of the process, where an applicant provides an application, there's an initial evaluation. It's thought -- and many of you know this -- that most applications will only require initial evaluation before a delegation of the TLD. In the case of certain controversial or objectionable applications, there are those processes sought to identify and quarantine risk and those are the objection and dispute resolution procedures, or if there's applications for two identical strings, there's string contention procedures, and -- to handle those applications that are somewhat problematic. And then finally there's a transition to delegation where an applicant signs an agreement and gets delegated into the root zone. So that's a very simple form of the process, but it maps the process and the guidebook together. And my last bit of background is this that's impossible to see, so I'm trying to encourage you to go on the Web site, but it's a map of all the documents that are posted associated with the new TLD program. So in the baby -- baby blue, in the baby blue on the left side is -- are all the modules indicated and their attaching documents. On the right side are explanatory memo and supporting organization that help describe what's in the guidebook. So with that bit of background, let's talk about what we've done over the past several months. And when I say "we," I meant all of us, because many, many of you in this room contributed to this process. As I mentioned at the outset, ICANN in October published the initial draft of this applicant guidebook and requested public comment, providing several public comment fora on its Web site. From that date in October, at the end of October, through January when I think the comment period -- the last comment period closed on January 9th, ICANN received hundreds and hundreds of thoughtful and constructive comments from everybody here. It represented considerable thought, considerable time for those that were contributing to this process. I think it's -- you know, we think it's the ICANN process at work. Many of the comments were expected. The depth and thought behind them were sincerely appreciated. And so then it was for ICANN, starting in January, to take these comments and provide an analysis and response to them in some sort of way, so I'm going to talk a little bit about how that was done in a second. But the torch of -- the burden of work was then passed to ICANN staff to somehow organize and respond to the comments. At the end, in the last couple weeks, that response is evident in the publication of a few documents. One is the analysis of public comments. That's quite a voluminous document. It's 160 pages or so. That analysis, necessarily, indicated where there would be changes to the applicant guidebook. So the second version, the draft version of the applicant guidebook, was published along with that. It's published in red-line and also in a clean version. And then associated with that, there is also some more explanatory memoranda to describe some of the thinking that's gone on -- that goes into the changes to the guidebook or the existing guidebook. So there's an update on resolving string contention, that situation where two identical applicants apply for the -- well, not identical applicants, but two applicants apply for identical strings. An update on the DNS stability paper describing string requirements that won't upset DNS stability. A new paper on registry/registrar separation requirements and the potential lifting of those. And finally, the description of an independent objector model for discussion. So how did we get there? How did we analyze all these comments? Well, if you -- reading the comments, they can really be divided into two camps. There's a set of comments that can really be handled in what I'd call the typical ICANN style, although I think we all agree there's nothing typical here. And that is that ICANN posts a position, either in an advisory or in a proposed agreement or in a proposed process, and then there's public comment. And the public comment is read, analyzed. There's an amendment made to the proposed position. And that gets iterated. There's more comment. And the final -- the final process gets iterated down. So for example, there were implementation questions on fee structure or contract terms where parties that are participating in this comment period made suggestions or urged ICANN to make a change of position, and, you know, often justified that position with a lot of thought. So that's one type. Another type of these comments would say, "You know, there's kind of a blank here in the applicant guidebook. You haven't really fleshed out the refund approach," or, "Can you provide some more detail behind dispute resolution processes?" So I think, you know, maybe 80% or a large percentage of the comments really went to this, and they fit well within the time line. There are -- many, many, many of them are addressed in this version of the applicant guidebook with either a revision or a proposed -- or an explanation why there is no revision. Then the second kind of comment really went to some fundamental overarching questions and I'll talk a little bit more about them. But these overarching questions didn't require, you know, an iteration of the guidebook. They were more about fundamental questions regarding the introduction of new top-level domains. They were the sort of question that require more consultation and study than could be considered, analyzed, and answered in the six weeks between the closing of the comment period and the start of this meeting. So let's talk a little bit about those more typical comments, first, and how they were responded to. So the analysis -- this analysis work has been going on since December, and as I mentioned earlier, in mid-February we published a summary of the analysis of this. How did we go about this? We have -- we had 300 commenters, many of whom had multiple issues or multiple comments within one letter. We've conducted additional face- to-face Fora since the meeting in Cairo, got additional comment there, had teleconferences with the GNSO and the GAC to discuss new gTLDs and the introduction of new gTLDs. So all in all, we're sitting there with, say, a thousand different comments. So first, these comments were parsed into major categories. So we need to organize them so we can respond in some finite fashion. So we organized them into 13 or so categories and then those into subcategories, 50-some-odd subcategories. And so then for each subcategory, we wrote -- "we" meaning ICANN staff other than me -- wrote individual papers that addressed the issue. So for each subcategory, there were a number of comments. Those comments were distilled down into a list of issues associated with that subcategory. And then there's this analysis that went on, this balancing of the issues. You know, "Here's the present, you know, default position in the guidebook; here's the suggestion; here's the environment." So this document, this great big document, 160-something pages is trying to do something really nuanced, which is very difficult to do, and that is to demonstrate that every single comment was read and every single comment was considered, and that we -- that there was a balancing that went on, a sincere balancing in trying to make an accommodation for that comment in the guidebook. And if it could, it would be reflected in a red-line, and if it couldn't, then it needed to be reflected in some sort of discussion. Now, a fully fleshed-out discussion would take pages and pages and multiply that by 50-some-odd subissues and you would have a totally unwieldy document, so that's this nuancing or balancing that's trying to go on. And one of my missions here at this meeting is to enlist you all, as partners in this implementation, and try to communicate that to those who are studying this process for the first time or don't understand it or those who aren't participating here, that the big message behind this document is that all these comments were considered carefully and then a response made in the guidebook. So the last really tough-to-see thing is this flow that's also on the Web site, but in more detail, but reflects the process through which the comments were analyzed. And so on the far left is the first version of the applicant guidebook, and you'll see it's divided up into its component modules there. Module 5 includes the contract, and then the next white box that you can't read is the public comment period that was 45 days. After that comment period was closed, we parsed those comments into those 13 or so categories. One of those categories is the registry agreement. Associated with that registry agreement, there are several subcategories that you can see there. One of them is whether or not there should be price controls. So a separate paper, then, was -- several issues around price controls and registry agreements. A paper then was written about that and inserted into the analysis, one of the papers in the analysis. As a result of that, some changes were made to the applicant guidebook, some weren't made and would be explained elsewhere. So that's -- when you're reading those analyses, if you can't sleep, that is the process by which we went about doing it. So I want to -- I want to transition for a minute. That's how all those issues that are handled in typical ICANN fashion were addressed. What about these overarching issues? Well, we identified four of them, or parsed them into four categories. The first is trademark protection and user confusion issues. So how can the process be launched in a way that addresses legitimate property and rights concerns? And a very -- there's several aspects to this, but also, you know, how do we address potential abuses at the second level, second level registrations, if there's many, many more TLDs. Another overarching concern is that new TLDs would become a multiplier for malicious behavior. If there's -- you know, there's 21 gTLDs now and 249 ccTLDs, if there's several times that number in the DNS, will that mean there's several times more malicious behavior that occurs? Under what conditions would malicious behavior increase or perhaps decrease? And how can that be managed? Another issue is the demonstrated demand. What is the demonstrated demand for TLDs? And what are the market impacts? There were several questions associated with this. And finally, what are the technical aspects or impacts of new TLDs into the root zone? And the capacity of the root zone to handle many more top-level domains has been addressed and written about, but we're now in an environment where there's a lot happening in the domain name system. It's near -- we're planning for the nearly coincident implementation of new top-level domains, IDNs, IPv6, and DNSsec. Now, what about the combination of those things and how they augment individual records and how -- how would that affect DNS stability, security, behavior, responsiveness, predictability, interoperability. So a separate study needs to be undertaken there. So these issues, which I think are very important and well-put require additional study, additional consultation, and that can probably best be addressed in the shortest time frame in a few ways. One is to use existing Fora or forums where people are coming together to discuss these issues and ICANN would participate in that, in order to generate solutions to these problems. And the next step will be for ICANN itself to conduct some of these meetings and bring the interested parties together who have developed solutions in order to arrive at, you know, some sort of a final accommodation, some sort of final version of the implementation that can be launched. ICANN also is publishing in the very near term -- the next day or so - - a set of economic studies that seeks to explain some of the issues associated with demand and market behavior. The ICANN board has resolved that the -- that its SSAC and RSSAC undertake studies that study the -- that look into the impacts, the technical impacts, into the domain name system and the root zone, given the multiple introduction of all these new products and services. So what's that mean to you, the applicants that are out there, the potential applicants? Well, we published the second draft guidebook in mid-February, a week or two ago, that addressed many, many of the implementation issues that are regarded as typical. But these other consultations, these other overarching issues, are going to take a little more time. So it's anticipated that this will require a third draft version of the guidebook. The impact of that would be to push out the project for a few months. Those of you that are well-steeped in the planning for this recall a plan that called for the final version of the draft -- final version -- not a draft version -- of the guidebook to be published in June before the ICANN meeting in Sydney, and that's in -- the next version of the guidebook is anticipated to be a draft that -- because we anticipate there to be many changes between the second and third guidebooks. And so there should be an opportunity for public comment. So at the end of the day that would -- that would delay or push out the time at which the first applications would be received at least to December 2009 and potentially the first quarter. And what has to be done in order to meet those dates is to publish the final version of the applicant guidebook, to wrap up all these issues that we've been discussing, conduct a broad communications outreach defined in the GNSO policy as a 4-month communication, for ICANN to complete its operational readiness work to be ready to process applications and then administer many new top-level domains. And finally, and what's on the critical path here, is to complete these consultations and studies on overarching issues. And so for those of you that want to participate and move this process to a close, these are -- these are areas where you'll want to comment or ask where you can play a role or suggest solutions to the applicant guidebook. So what I'm going to do now, if that was -- if that was understandable, I'm just going to take a minute and go through some of the changes that have been made to the applicant guidebook in sort of broad brush. There's many significant changes. I think there's 50-some-odd areas of change. I selected some here that I thought would be the most important for the people sitting in this room. And so I'll go over them. I think the changes show responsiveness and also the analysis shows quite a bit of responsiveness. Regarding all the fees associated with the whole program, annual registry fees were reduced from $70,000 -- a $75,000 floor to a $25,000 floor. There was a -- many comments that the higher baseline fee created an uneven playing field with existing top-level domains and that the high minimum fee also would exclude some smaller participants. And also the transaction, the variable portion of that fee was simplified to be 25 cents per transaction after a certain level instead of a more complex percentage of revenue model that would require administration both at new registries and at ICANN that's not really value-added. Also specified in the guidebook is a refund structure for those who drop out of the process. So that's fairly well-defined. Also included is a partial refund for certain participants in the 2000 round based on the criteria set there. So it's very specific criteria that have to be met in order to receive a partial credit. And then, finally, we've essentially eliminated the comparative evaluation fee. Remember, comparative evaluation is a type of evaluation intended to benefit a community-based applicant. This community-based applicant can avail themselves of this process to gain a preference in the program. And, in order to participate in the comparative evaluation process, the community-based applicant, often the smallest and least well-funded of all the applicants, would have to pay a fee. That seemed to be somewhat ironic. So that fee was eliminated. I'm just going to touch on this for a second. But, regarding string requirements and IDNs, we -- there was -- there's technical writing in the application -- Application Guidebook regarding rendering problems with IDN strings and guidance on how to apply for them, information on how to submit IDN tables, which is important, and updated reference to the IDNA protocol, which is presently being -- presently being produced and then clarification on words like hexadecimal and octal. I don't really understand all that since grade school. Regarding geographical names -- by the way, this is my first use of a footnote in a slide in 13 ICANN meetings. So let me know what you think of it later. But the requirement for geographical names was clarified that a meaningful representation of a country name in any language required relevant government approval. In the previous version, it was the six U.N. languages and the official language of that country. Languages of that country, which seemed somewhat arbitrary. And then the guidebook better clarifies the content of the government support. It provides guidance to the applicant in garnering government -- relevant government support so that the applicant can more easily understand what the requirements are because they're more specific. Regarding technical and operation criteria, you know the initial evaluation? Some of the questions were clarified or made more objective. Sometimes strings of requirements were put into bullet form so the reader could understand that these were all required. The questions were reorganized a little bit, so the reader could more easily understand which evaluation criteria went with which questions. RFC references were updated. And there are certain changes to scoring. It's proposed in here, but not certain, that a higher score be given to an applicant who summits to escrow thick registry data. And I think the discussion about thick versus thin and the benefits or costs will continue. The criteria also award an extra point for referencing, including takedown procedures, rapid takedown procedures as a way to restrict potential results such as our -- as -- such as -- let me start that again. Such as phishing or pharming. Dispute resolution: There are significant changes made in the guidebook but not really big changes with regard to how ICANN intended to address these issues. So, for example, where the guidebook was silent on morality and public order standards in the previous version, these standards are now fleshed out and complete in the guidebook. What those standards were proposed before in an explanatory memo in the last version of the guidebook. So after considerably more discussion, those standards are promoted from an explanatory memo and put into the guidebook for discussion. So I just want to take time out for one commercial here. That is, still, it's a draft version of the guidebook. So there's a -- there's a -- one might intuit that putting standards or putting a position in the guidebook indicates it's final. But it's certainly not since it's draft. And also I think that putting a proposed position in the cold, hard language of the applicant guidebook really points up the discussion. Having an argument or a discussion about things in a memoranda about position is somewhat speculative. And where you think you have agreement, then you transfer that into a contractual document or an application document. And those that took part in the earlier discussion said, "Hey, that's not what I meant." So we think it's better to put these proposed positions right in the guidebook so those who want to comment or observe can see how they will look in final form. And there's agreement about form. And then the right substantive discussion can take place after that. So we're back on track now. The -- also, in morality and public order, standing requirements are not precise yet. But the issue is more pointed about where the guidebook might go as far as who can object to a morality and public order issue. There's brand-new dispute resolution procedures. So the dispute resolution procedures were embedded in Module 3. Now they're taken out separately as an appendix to Module 3. They are the procedures that the ICC, the ICDR, and WIPO have all agreed to follow and administer in these dispute resolution procedures. So they're pretty much in final form. Each provider will still have some rules that they follow. And finally in this section, the concept of independent objector is introduced. What their role would be, how it's independent from ICANN and how the scope of that objector might be limited. String contention, remember, is where two identical strings are sought by different applicants. And there was a lot of comments about this. This is a -- there's scoring involved here and a lot of particular procedures. So there was a lot of comment. The guidebook first seeks to clarify what "user confusion" means. In one instance in the application process, only visual confusion between strings is measured. In another part of the application evaluation process, all types of confusion are measured. So an objection can be made that two strings are similar and would result in user confusion if they look the same, sound the same, or mean the same. The comparative evaluation, remember, is where the process seeks to give an advantage or a preference to a community-based applicant. After considerable discussion and comment in the Cairo meeting and in writing, that scoring mechanism was altered somewhat to provide more granularity and more objectivity. In another area where a proposal is taken out of a memo that was published in October and put into the guidebook, auctions are proposed for a mechanism of contention resolution of last resort. So that if applicants -- if applicants vying for the same string cannot -- that issue is not settled in comparative evaluation, or in an -- in a discussion or agreement in the parties, auction would be the last means to resolve that dispute. There's two other points to be made here. The guidebook indicates the formation of a foundation to use funds with a clear mission, clear guidelines, some form of independence to dispose of those funds. It also should be noted that ICANN and all of us are going into this part of the process with our eyes wide open. Now, one of the reasons for being -- for auctions is really to encourage parties to settle. The specter of auction means, you know, paying full value for the string. And parties would be incented to settle their contention before an auction because it will be more economic for parties to settle among themselves instead of going into a blind auction. So we think at the end of the day, there will be very few auctions. And, really, it's a tool for encouraging settlement. There's several changes in the proposed registry agreement based on public comment. One is proposed lifting of the current restrictions on -- or the current requirements for separation between registries and registrars. ICANN commissioned a report by Charles River Associates, who studied the marketplace, issued a report recommending a gradual lifting of these restrictions. First to test and then perhaps subsequently take all restrictions off. ICANN held a couple of face-to-face consultations -- one in Washington, D.C., and one in Los Angeles. Both were available worldwide via conference phone to discuss and develop models for how this registry/registrar might still work. And so a model is -- a model is proposed in the guidebook that's the synthesis of this discussion. And so I encourage you to read that. I've already talked about fees and the reduction of fees. In order to better protect registrants, we've included a requirement for a 6- month notice of price changes. So, if there aren't price controls in the agreement, at least there's some notice period. There's also a requirement that registries offer 10-year registrations for registrants who want them so they have certainty of price over a 10-year time. A couple other issues that arose in the Cairo discussions and after are the proposed process for modifying the registry agreement. There was considerable comment on that. This agreement proposes another way that the registry agreement might be modified. It could be modified at the suggestion of ICANN in certain -- on certain terms, not all terms, and can be vetoed by a vote of the registrars or majority of the registrars. And also, you know, of course, any contract change requires board approval. And, likewise, registries can propose modifications to the agreement in the same fashion, too. And then the -- the second issue that came up in discussion was that in streamlining the agreement, certain requirements for ICANN to behave in a transparent manner and treat registries in an equivalent manner were taken out along with pages and pages of other texts. So it's thought that ICANN has that obligation in any event. But those terms were reinserted. So that's kind of, like, it. So to get involved, I think Kieren earlier discussed the question box that's open for this meeting. So that's going to be around until March 4th. And then certainly we're going to take questions here, anybody who wants to ask a question. There's also a public forum with the board on March 5th where comments can be made. And then the applicant guidebook Version 2 and all that analysis and the explanatory memos and all that -- that public comment period is going to be open until April 13th. I will say that going forward we're doing a few things. One is there's a few areas in the applicant guidebook that will probably be updated before the next version. So we've undertaken a study of the technical and financial evaluation criteria and are looking to amend that. So we will -- and we're looking at the technical string criteria, too, and looking to make additional clarification there. So you might see some updates to the guidebook in the interim. Because if there's -- you know, if there's an adjustment, we want to get that out as soon as possible. And then going forward you see these global outreach and consultations to discuss the overarching issues. So you'll see those four advertised. We have a communication plan to promote program awareness. This is only going to be effective if the programs communicated in all regions so that entities in different countries feel they have the same opportunity to avail themselves of the processes anywhere. And we'll also publish a calendar of all these activities coming up. So I refer you to the new gTLD web page that you get to by going to ICANN.org. And all this information is there. And all the stuff in small font that you couldn't read is there. But I wanted you to see it anyway. So thanks for bearing with me through this kind of somewhat difficult material without a good story. And I hope it was informative. And if anybody has any questions, we can start. >> We have a question on microphone 1 in the center of the room. Microphone 2, I apologize. >>STEVE METALITZ: This is Steve Metalitz from the intellectual property constituency. Kurt, thank you very much for this presentation. I wanted to ask a question about what I think was your third overarching issue and the economic study. In our view, this is actually kind of a gateway issue on the entire question and we're pleased to hear that the economic study will be released soon. We're looking forward to it. But as you described it in your bullet point there, I think the phrases were -- the questions that you were trying to answer were, is there demonstrated demand and what are the market impacts? I'm not sure those are exactly the questions that needed to be asked or that the board asked to be asked. But maybe the market impact one translates to what I think is the true question here, which is will the introduction of new gTLDs increase competition and consumer choice? And if so, how do we fashion the scope and the pace of the introduction of new gTLDs to maximize those benefits? There are people in this room who are far more expert than I am on the 1998 white paper that you referred to, but I don't think it says in the white paper that, "The more, the merrier. As many new gTLDs as we can get will increase competition and choice." And if it does say that, I would just point out that that paper was not handed down from Ira Magaziner on Mt. Sinai. We need some current and objective information on that question to try to answer what new gTLD rollout should there be to maximize competition and consumer choice, minimize consumer confusion. So I hope -- and perhaps you can give us some insight as to whether the economic studies will help resolve those questions. Thank you. >>KURT PRITZ: Well, I think your framing of the questions is much better put than my shorthand of bullets up here, so I appreciate that. And I will need to reform that statement when we discuss it in the future. To the extent I'm familiar with the content of that report, it does seek to address the benefits -- you know, it is about benefits to consumers and benefits to registrants in a potential expansion of the name space. And that report should be posted in the next day or so. We had consultations with the GNSO and GAC and ALAC here and voiced concern about publishing a paper in the middle of an ICANN meeting because sometimes that's not welcome. In this case, it seems like the feedback is to publish it as soon as it can. >> We have a question, microphone 1. >>GUANGHAO LI: This is Guanghao Li from CNIC and also a board member of dot Asia actually speaking for the CDNC, the Chinese Domain Name Consortium. Actually, I have two comments to make today regarding RFP Version 2. First, I would like to thank ICANN for all its efforts in cooperating, all the comments received for the new gTLD RFP going into the drafting of the V2. When we were reading the V2, we discovered in Module 2, Section 2.1.1.3.2, which is the string requirement for the IDN strings, it has not been modified to lift the restriction on the length of an IDN TLD. It still requires an IDN TLD must have more than two visually distinguished characters, although there is a remark that welcomes further comments. So we would like ICANN to provide the rationale of imposing such a restriction in order to accrue better suggestions to resolve the concern because such a policy, such cost has not been coherent with the GNSO new gTLD principle regarding IDN TLDs which that states for single and two-character IDN strings at all levels, single and two-character U- labels on the top level and second level of the domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case-by-case basis in a new gTLD process depending on the scripts and language used in order to determine whether the strings should be granted for allocation in the DNS. So if the original intent was to avoid confusion with the two-letter ccTLD, we think this may not be effective based on the following reasons. The first reason, the restriction on the length of IDN ccTLD will not be limited to two characters. It will reveal the IDN fast track Version 2. The current 63-letter Punycode length limit will allow IDN characters to be more than three and also allow just one character to represent a country or territory's name. So this is mainly due to some countries' or territories' name are not just meaningful by using two characters. And second reason, there is already a string confusion check mechanism in place to avoid confusions in the RFP. That mechanism not only works effectively with Latin-based scripts but also works well with non-Latin-based scripts such as Chinese, Japanese, Korean, (inaudible), although they are not likely to cause confusion in the current ccTLDs. Even when they do, I think we also have a mechanism to make it reject it. So, indeed, we think this requirement can seriously impact the interests of many Chinese users. In a real live case, the case of a Chinese IDN TLD, the limitation to three or more Chinese characters will be a substantial deterrent for the adoption of Chinese TLD because most meaningful Chinese words are composed only by two Chinese characters. This requirement can harm the interests of more than 300 million Chinese-speaking Internet users. Thus, we respectfully urge ICANN to follow the GNSO principle recommendations to lift the restriction or modify the cost to make it become script-specific. That's my first concern. And second we would like the RFP to address issues of variants of IDN TLDs such as variants of simplified Chinese and traditional Chinese in order to better protect users' interests, avoid potential use of cybersquatting, phishing by using variants. An example to add to such a concern we can learn that from the IDN ccTLD fast-track Version 2 which has set up rules and requirements and script tables for the variants. Thanks. >>KURT PRITZ: So are you looking for a job? [laughter] I'm going to pretend to understand part of your questions and answer it briefly, and we can discuss it more later. There has been considerable discussion at ICANN -- and when I say "at ICANN," I mean among ICANN staff and in the big ICANN -- about the three-character requirement that's historically based from ASCII TLDs to avoid confusion with country names and clear understanding of the difference in different scripts such -- so I would label them at idiographs but that's not quite right, I don't think. And in those discussions, it's been difficult to draw a bright-line rule around which scripts would qualify for the exemption from the three-character requirement. So at the time of publication of this version of the guidebook, such a bright-line rule or clear rule that would make it clear to all applicants was not yet developed. But it is still sought and we understand -- we all understand the GNSO advice and implementation through the reserved names working group and we aspire to create that rule. So this discussion surely isn't done, and so there are two steps. One is to develop a position, a set of rules that's bright-line that would work, that would be acceptable across users of all scripts; and, two, to vet that through the ICANN management, staff and board and community as the new set of rules. So my commitment to you is that work is really ongoing. It is taken very seriously. And we didn't want to publish a set of rules we didn't think would be clear and effective. And to the extent you want to play a role in that, that would be terrific. >>GUANGHAO LI: I already have a job. If that's the job you are mentioning, yeah, I would like to do it. [laughter] >>KURT PRITZ: We pay good money, not much but good. Then on the question of variants, that's a very interesting question. So, for example, in the IDN ccTLD allocation, it is anticipated that the IDN of dot China -- I'm sure that's not the correct name, and I apologize -- in simplified and traditional Chinese would be allocated as a ccIDN. It is a harder question in the gTLD space. One of my reactions is the protections you mentioned in the first part of your discussion about user confusion would prevent somebody from using the variant in a malicious way. So I think that discussion -- I think there are safeguards in the gTLD process for that, but I think that discussion on variants needs to continue also. So thank you very much for your thoughtful question. >> We have a question on microphone 3, and I would like to suggest that we ask one question to give many people in the room the opportunity to ask their questions. Thank you. >> My name is Rudi Vansnick from the At-Large Advisory Committee representing the work group who worked yesterday all day on the new gTLDs. And we are still surprised that in the new version, the second draft, we are missing the participation of communities, especially the user communities we are representing. So far I thought we have seen a lot of comments popping up in the past period. And up until today, as well as in the red-lined version as in the analysis, we didn't see the comments coming from the community in the sense of why are the comments of the geographical communities-based applications have not been considered in the sense that we are asking for a split of the process so that the geographical communities who are in collusion sometimes with ccTLDs will have also the possibility to participate in this process. In the draft, we didn't see the remarks we have made and we are still requiring the participation of the user community in the whole process. So I'm wondering why in the whole new version there is no space actually for the participation of the At-large community. I think that we are representing a lot of the Internet users. We can say 1.6 billion if we want. That's the user community. So we would like to have our voice and would like to know in which part of the process we can participate. >>KURT PRITZ: Can I ask a clarification? Are you asking about community-based top-level domains that are geographically -- with geographic names? >> RUDI VANSNICK: Yes, that's indeed what we are focusing on, the geographical community-based. I can give some examples. The dot cat is a beautiful example which is running already. We have a lot of other geographical community-based applications such as the cities, such as parts of countries who want to have their space and they are representing a lot of the Internet consumers. So that's the reason why we ask for participation of the at-large at least in this process. >>KURT PRITZ: So I want to talk to you more about this later because I'm sure my answer is not going to address your question. But the process anticipates community-based top-level domains that self- identify as community-based, gain a preference in the system in cases of string contention and that the policy discussion that formed these community -- the preference for our community-based top-level domain specifically described geographic names. So city names or country names, subregion names all were identifiable with communities. And so the process' design was sought to give a preference to those applications. That's my answer. I'm sure I'm not hitting on your point so I would like to talk to you about that later. >> We have a question on microphone 4. And if you would please state your name, we would appreciate it. Thank you. >>MARILYN CADE: My name is Marilyn Cade. I am, first of all, pleased as all of us are to have the opportunity to acknowledge the significant amount of work that the services staff has put into the implementation process. It is, in fact, an awesome amount of work and I think all of us want to recognize that. But I'm also, as a member of business, aware that sometimes we decide to create a product or a service and we find that, in fact, that product and service is not well-designed for the marketplace. I must say that as I read all of the comments, as I participated earlier in the GNSO process, I have always read all of the comments that were submitted. I'm very aware that the participation in this phase of the public comment process is not about the GNSO. It is about the broad stakeholder community across all of ICANN. Significant concerns have been raised. There are threshold issues. Kurt has identified some of those and has suggested that ICANN is now deciding to listen to comments that have been raised over and over. It is going to be very important to ensure that those threshold issues are identified and are addressed. The fact the economic study has not been delivered and presented to the community for analysis and agreement or rejection or request for refinement is a threshold issue. An economic analysis could have told us, for instance, that as we evaluate the over 175 million gTLDs -- domain names registered in the world today, that the vast growth is in the cc's. It could have told us that new space and new users are actually coming from the developing world. Developing countries where ASCII characters and generic names are not in English is not the primary language of choice. It could have told us that our priorities should have been IDNs from the beginning. We have to adequately address concerns in that space. We're now doing an economic study and releasing it. We are also going to do an assessment of technical and other issues. I'm reminded from my years of work in the high-tech sector of an admonition that we give to companies when we try to convince them that their services and products need to work. Build it in, don't bolt it on. So I'm really concerned that in these four threshold areas that we are now going to address and the rest of the guidebook is speeding forward, that we're going to be retrofitting the fixes and we are going to be bolting it on and not melting it in. And I think that's a threshold risk. >>KURT PRITZ: So thanks for that, Marilyn. My only response would be to try to provide assurance that the many implementation issues that are being discussed and resolved that the process wouldn't be launched without the deliberation required that you were mentioning and that I don't think a process could be launched in a bolt-on -- with a bolt-on style that you're concerned with. I think we're pretty much in lockstep with that and I want to provide whatever assurance I can from up here right now about that. >> We have a question on microphone 2, and I want you to all know that we are very aware there are a lot of questions. We are going around the room to make sure that everybody gets an opportunity. So state your name, please, microphone 2. >> EVAN LEIBOVITCH: My name is Evan Leibovitch. I was a participant in the gTLD portion of the summit working groups yesterday. And I have one question but before that I would also like you to revisit the question that Rudi had regarding listening to the public user's voice. There was a general feeling in that working group that the end user voice, the at-large voice has basically been rejected in a whole bunch of fields. I would really like you to comment on that. My specific question goes to the issue of the independent objector clause that has now been added in, and this seems like a perfect opportunity for ICANN to engage its At-large community because it seems like the main rule of the independent objector is something that would uphold the public interest. Have you considered giving at-large a role in that component of the process? If not, would you consider it going forward. >>KURT PRITZ: Thank you. So your first comments -- well, misdefine is the wrong word, but the whole At-large Summit and ICANN facilitating that and holding that at this meeting at considerable expenses all around trying to energize the community of users and give them a voice and give them a forum in which to say that voice. And this has been, you know, Denise or nick Ashton-Hart could talk to this better but this whole progression of the development of the At-large community has had this in mind through the creation of the RALOs initially and then the more formalization of the At-large community. So I don't know -- Karen Lentz, do you remember any of the specific issue that is were brought up from this? If you don't, you can say no. That's my knee-jerk reaction to that. The independent objector is intended to address the very interests you are talking about. I think we need to divide the at-large or user role or the ICANN community role in defining what that is and creating the role and then separate that from the operation of the role which really needs to be, I think, independent of ICANN and have its own operational responsibilities. So I don't see a role of the At-large community or any of the other constituencies in ICANN in a case-by-case basis making decisions on TLD applications but I see a big role in defining what the independent objector is. There is also a role for public comment in the process so there is a section in the applicant guidebook that describes the role that public comment takes in determining the outcome of the evaluation of applications. That is supposed to address opinions of the community. >> Microphone 1, state your name, please. I'm sorry. You want another answer? >>KURT PRITZ: Yeah, I have really dissatisfied my questioner. >>EVAN LEIBOVITCH: Just a follow-up to what you said. Isn't the very definition of the at-large role within ICANN to defend and protect the public good, is that not totally in lock-step what your intention is for the independent objector? >>KURT PRITZ: I think so. I think so. >>EVAN LEIBOVITCH: So if that's the case, I would just recommend that you consider perhaps a deeper involvement. >>KURT PRITZ: Consider? >>EVAN LEIBOVITCH: A deeper involvement of at-large in that, not just in the design but perhaps even in the implementation. >>KURT PRITZ: I hear you. >> Now we have microphone 1. Once again, I see all of you waiting and I know the whole room. So we are trying to do it in pattern. >>MICHAEL PALAGE: Michael Palage. Kurt, I would like to echo Marilyn's initial comments about the recognition of staff's hard work and the continued evolution in the draft applicant guidebook. My question, though, goes to Steve Metalitz's question regarding the economic study. On Saturday morning, you had consulted with the GNSO and said that that report was done and staff was consulting when it would be released. I'm a little concerned, you said a day or two. Is there any reason that we, the community, could not have that report today? And the reason I would ask for it today would be to allow the community to review this document so that when we interact with the board on Thursday we engage in an informed decision. I think it is important as well to have early release. I assume this document is going to be in English. Although as an American lawyer, I will be able to go through it rather quickly. For those non-English speaking participants in the ICANN process, having those extra couple of days may be able to help in, again, creating a good dialogue on Thursday with the board. >>KURT PRITZ: I'll check. >>MICHAEL PALAGE: Is there anyone in the community that would not like to see it immediately? >>KURT PRITZ: I want to see it, too. I'm with you Michael. I will work on it when I step down from the stage. >>MICHAEL PALAGE: For those board members in attendance, there was no one objecting. So perhaps the board could direct and let the bottom- up process work. Thank you. >>KURT PRITZ: Thanks, Michael. >> I believe there is someone at mike 2 that is anxious. The person in white that keeps standing up and down, we'll take that question. >>WERNER STAUB: My name is Werner Staub from CORE. Point of order first. The set up with microphones mobile is extremely difficult, and it makes it difficult to speak, especially for the ones that are not English speaking. For even those that are, when the person speaks, we don't know where the person is. The traditional form of the microphone in the middle where people queue up is really much better. It is also for the benefit of those that are here that whoever speaks should be visible. The lady who just called people, it would be better if everybody who is organizing this is on the stage so we know who we talk to. It is very difficult if it is spread in the room. >>KURT PRITZ: Thank you. >> Thank you very much. We'll take that in. We have a question on microphone 3. Do you have a question? >>WERNER STAUB: Yes, I do. That was just my point of order. The timeline, of course, is our main concern and we understand the concerns are being voiced by many people about potentially contentious applications, applications where things have to be resolved. There are, however, a number of totally uncontentious TLDs that are being delayed and that are readily being drowned in the problems caused by the delays. I'm not sure if this new delay is the last one we are going to have, which is why I made the suggestion -- I want to repeat it -- to divide a round into more than one application window and enable people who choose the first application window in the round, which could actually be early this year, to apply under the condition that if they sustain an objection other people might apply in the same round but in an ulterior application window for the same TLD. That would actually be a nice sort automatically non-contentious one might go through because it would not sustain objections. Those that could sustain objections could sustain it from the independent objector or there is something wrong from the TLD but it would not kill their proposal. They could possibly withdraw it and apply in the subsequent window. It would remove drastically the pressure we have on all of us. >>KURT PRITZ: So, Werner, when you say sustain objection, do you mean that an objection isn't lodged against that so the preliminary round would be for non-contentious TLDs? >>WERNER STAUB: Indeed. >>KURT PRITZ: Okay, thank you. >> This person on 3 has been waiting equally long. Could we have you state your name and stand up, please. We have had a request that everyone be seen. Thank you. >> My name is Naomasa Maruyama with JPnic. I don't go into detail on the criteria written in this book, but I want to mention to the overall structure of this guidebook. So this third round is very important and it will have tremendous impact in the various industries so we have to keep in mind that the -- really lots of people who are not familiar with ICANN process will read this guidebook. From this point of view, I think this guidebook should be self- contained. But I'm very afraid to say this, but I have to mention that this guidebook -- draft guidebook, either Version 1 or Version 2, is just like very badly written computer software manual that is only understood by experts, not by novice users. This should be improved, I think. To improve this situation, I gave one comment which was completely ignored. That is, to give a preamble to this guidebook, which will explain the -- what the ICANN process is, what the GNSO PDP process is, and the history of the -- this new gTLD process, and how this guidebook is built up. That is my comment. And I urge to reconsider my comment. Thank you. >>KURT PRITZ: Naomasa, have you ever seen a very well-written computer software manual? [Laughter] >>KURT PRITZ: I'm sorry. It was just a joke. I take your second comment very seriously, and we actually discussed your comment and, you know, maybe it was the wrong decision. We'll revisit it. We decided to separate explanation and history from the strict set of instructions for applying for a guidebook, thinking that that information is, you know, all wrapped around the gTLD Web site, all the explanatory materials and background information. But I see where we've -- you know, so we discussed your comment specifically, and, you know, I think it's a good one, so we'll see what happens in the third version. Thank you. You. >> Microphone 1. Please stand up and state your name. Thank you. And then we'll go to 2 next. >>ANTONY VAN COUVERING: Hi. My name is Antony Van Couvering and I'm interested in these threshold questions from the session yesterday. They're not resembling so much a threshold as a -- one of those long walkways in the airport, because I was reading through the Yokohama meeting that was 2000 where we discussed technical stability, we discussed threats from spam, we discussed all of these things. So let me just go through those, because I think there's only one issue that we're dealing with here. Malware, as Antonio Harris said yesterday, exists. It exists today in the TLDs that we have. It is trivially easy to register a domain either in a ccTLD or a gTLD, and I'm puzzled how new TLDs would affect that in any way whatsoever. Technical stability. Your own staff said -- and I agree with them -- that this is simply not a serious issue. And I'm happy to quote you chapter and verse. You know, the -- we can't keep going over the same issues again and again. I'm glad there were a lot of comments. I'm pleased that there's a lot of participation. However, some of the comments are worthwhile and others have been resolved already. ICANN cannot simply consider the same comments over and over and over again. So as to demand, is there demand, well, obviously we can't poll the whole world to see if they want a new TLD, but right outside this door are a number of people who have paid good money to ICANN, and a lot of money elsewhere, based on the fact that they see demand. And these are people who know the field and understand. So they think that there's demand for new TLDs and I'm personally one of them. I would like to see that question turned around: Show me that there's not demand. We see the domain name area growing very, very fast. We know there are new, especially community, TLDs that have popped up already, so we see that happening. So what we are left with, really, are trademark issues, and I notice a lot of those comments from people in trademarks -- and there are legitimate issues -- are very, very similar. So they -- I would like to see us concentrate on fixing that problem and not stopping it. And I urge people to show up at the meeting at 4:00 p.m. today where there's at least one extremely interesting solution for this. Thank you. >>KURT PRITZ: Thank you, Antony. [Applause] >> We have a question that's been waiting on 2. Then we'll go to mic 3 and I see another person back at mic 3. So mic 2, stand up, say your name, please. >>JOE CADY: Hi. My name is Joe Cady. I'm with a company called STG Interactive. We're a future gTLD applicant, and we've been looking at the question of the registry/registrar separation issue, and I was wondering, after reading the last response to the CRA report if there's a body in particular in ICANN for -- whose responsibility it is to take the last suggestions and move it towards policy for the application process or are we also going to have more public comment? That's it. It's brief. >>KURT PRITZ: Yes. So that model, the responsibility for taking the CRA report and moving it to a model is us, and so the first step was to have a set of consultations with -- taking the CRA report and other -- the opinions of other experts in this area into opinion and developing some models for registry/registrar separation, and the synthesis of that is what you see in the guidebook, which is a proposed model. And so now it's for everybody here to comment on that model, so that we can arrive at a final version of that. So did that answer your question? >>JOE CADY: (Speaker is off microphone) I didn't actually see in the guidebook reference to this issue. >>KURT PRITZ: It's in the registry agreement. >>JOE CADY: Yes. I actually just found that out recently. In fact, here in this room. I would have liked to -- well, is it going to be more visible in a future versions? I saw, for instance, in your chart on the process, that it's set -- it's treated somewhat separately. We don't see it actually in the guidebook. Okay. We've seen it now in the registry agreement. But for applicants to shape their strategy, to understand where they're going, and what's the endgame basically in business -- it would be nice to see a little bit more transparency. >>KURT PRITZ: Right. So as a potential registry, you will have to comply with your registry agreement, and so the place to spell that out clearly, and definitely, is in the registry agreement. So necessarily, the only place it will appear in the applicant guidebook is in -- is in the registry agreement, to flesh out the thinking behind that and some of the explanation, there's that explanatory memo associated with it. So if your comment is that the term in the proposed registry agreement isn't clear enough for you to understand what your obligations would be as a registry, that comment's really well taken and we'll look at it. >> Microphone 4. Please stand up and say your name, please. >>TONY HARRIS: My name is Tony Harris. I would like to address the issue of -- I would like to address the issue of demonstrating demand for TLDs. I think you could probably respond to that pretty easily, because if you try and register a new name in dot com which is relatively short, I think you have a 99% possibility that you will find that it's taken. So per se, dot com, which is considered the default prime target for somebody wanting to register a domain name in the gTLD world is, for all intents and purposes, taken. So I do hope that when you consider responding to this demand for demonstrating the need for new TLDs, this will be taken into consideration. Additional to that, I would say that it's pretty obvious that with the tendency to develop the mobile Internet, dot mobi foreseeably could be a pretty heavy contender for identifying content on the mobile Internet, so I don't really think that there is a very solid need to demonstrate the need for new TLDs. It's pretty self-evident. Thank you. [Applause] >>KURT PRITZ: Thank you. >> Microphone 2, and then we'll go to 1. Thank you. >>KURT PRITZ: Thank you, Tony. >>DIRK KRISCHENOWSKI: Dirk Krischenowski from the dot Berlin top- level domain. Kurt, with the first guidebook in October, there came a pretty colorful chart with a time line, and I'm missing this but you may be able to give us a pretty colorful explanation what's going on there, and how the new chart looks like. And the time line. >>KURT PRITZ: Well, the new chart will be in black-and-white. [Laughter] >>KURT PRITZ: Smaller font. And will indicate that an early plan would be that the final version of the applicant guidebook would be published in October, and applications could be received in December, and the 4-month communication plan would start 2 months before the -- 2 months before the publication of the final guidebook in order to satisfy that requirement. In fact, the communications outreach will start markedly before that, and the 4-month window will be -- 4-month requirement will be exceeded. And then 2 months after that, in December, we could receive applications. If the critical path, which I -- you know, I think Anthony did a really good job of pointing out that the critical path to this is resolving these trademark issues. If they're resolved, say, in June then we could meet that plan. If they were resolved in July or August, that would require -- you know, that would result in applications being received in February. So that's sort of how the time line works. >> We have time for only one more question because we have to move into the next series of meetings, so no. 1 microphone, please stand up and state your name. >>DANIEL SCHINDLER: Good afternoon. Thank you. My name is Daniel Schindler. I'm the chief executive of CentralNIC, the global domain name registry. I'm also a cofounder of a new corporation named Central Registry Solutions, which some of you will have noticed on your newswires this morning is a joint venture between Network Solutions and CentralNIC and wearing both those hats and as someone who has been in this industry for about 10 years, I'd like to thank Kurt and his teams for navigating this long road, and to encourage, support, and implore the community and ICANN to get us to our destination as soon as possible. Antony Van Couvering stole my thunder a bit, and Mr. Harris at the back, too. We don't want to lose momentum and be seen to the outside world as people who just make promises and never get to the destination. So my support and encouragement to help us get there sooner rather than later. Thank you. >>KURT PRITZ: Thank you. [Applause] >>KURT PRITZ: All right. Nancy, with that, I'd like to thank you very much for all the thought you've put in, all the comments that were made, your time today traveling here. You're really great, so thank you very much. >> Thank you, everyone. >>KURT PRITZ: Can I say something? Yeah, so I was -- yeah. So there's a public forum on Thursday with an open microphone and you'll have a chance to say something there. >> (Speaker is off microphone). >>KURT PRITZ: I'm not sure. >> (Speaker is off microphone). >>KURT PRITZ: Yeah.