ICANN Brussels gTLD Program Update Monday, 21 June 2010 >> Ladies and gentlemen, if you would take your seats, please. We'll begin this program very shortly. Please turn the ring of your cell phones off so the speakers are not disturbed by it. Thank you. >>KURT PRITZ: Good afternoon, everyone. Are we ready to start? Thank you very much for joining me here this afternoon. This is a -- you know, just a lovely venue and then the lights up here are really bright. But it's a beautiful auditorium, and I feel privileged once again to come before you and talk about new gTLDs. As a young man when this started, when we published the first guidebook and now look at me at the age of 29. The now standard second slide. So I think almost everybody in the room is very familiar with the new gTLD program, but I'll just take a minute to say that we're going to discuss the applicant guidebook, and the applicant guidebook describes the process by which you -- an entity -- can apply for a new generic top-level domain. And so the guidebook is divided into six modules, and those modules kind of track through the process. So Module 1 is an overview of the entire process, but it also describes who can apply, how much you've got to pay, the process you go through in the application describes the online, you know, application process, the TLD application process known as TAS and provides time lines and time frames for how long your application would take to be processed. Module 2 of the guidebook really is the most important part, I think. It's the process all applications go through, the initial evaluation where applications are evaluated six different ways to determine their suitability to be awarded a top-level domain. So it contains the criteria -- the questions and the criteria by which the answers are measured by to test the financial viability of the applicant, the technical wherewithal, whether they applied for a string might break the Internet, whether a string is so similar to another one that user confusion would result, whether services offered by the potential new registry will not disturb the DNS stability and security. So I think I missed one or two, when you those are the tests. It's certainly not the intention of this process that the evaluation rises to the level of a venture capitalist, but rather tests whether the applicant meets certain baseline criteria. The guidebook is actually intended to help the applicant understand what's involved in operating a TLD. If the applicant goes out and gets help in filling out an application in a competent way, that would help inform the applicant as to the requirements for operation of a TLD. So the application process and the evaluation itself is meant to be more of an aid to potential applicants in operation of a TLD, and not a bar to attaining one. So the remaining modules, 3 and 4, about the evaluation we hope play less of a role. Module 3 describes four areas of objections, so certain entities or people would have standing to object to potential TLDs. All the rules around those objections and how the objections are heard, the dispute resolution processes, are in Module 3. Module 4 describes what happens if strings are in contention. In other words, if two entities apply for the same string, the same identical string, or strings so similar they're deemed to be identical. How do you break that tie. So that is described in Module 4. And then Module 5 sets the applicant on the road to delegation. So the delegation process, the proposed registry agreement, and all its attachments, are in that module. So that's Module 5. And then Module 6 is a brief module that contains the terms and conditions for that. I should add a slide for that, but I do not. But I think we're among old friends here. To get to the very last slide first, one of the presentations later this week -- I think it's on Wednesday, is it, Karla? -- is new gTLD basics, and so for those -- Excuse me? Tuesday. So those of you not familiar with the new gTLD process, you'll take the advanced course here first, and then you can go back second. So it's sort of ICANN-ish, isn't it, Katim? So what's today about? ICANN recently published the fourth version of the guidebook, and still there's a good -- a good bit of red in the red-line version, so there's been a lot of listening to public comment, face-to-face meetings, public consultation sessions, input we received in the Nairobi meeting. That was a great meeting. That was a few months ago. And so this is -- this is about that. But it's really about some other things on the path to launching this process. First is the public participation success that I think we all enjoy as, you know, the big ICANN, with all capital letters. All of us in this room that have banded together and worked together to get to this stage of the game. So I want to talk about that. And then about the remaining guidebook issues and how close we are, we think, to resolving them. And then what have we done? What have we done through all of this? Well, we hope we've improved the namespace. We've made it more friendly, more secure, more stable. So new TLDs offer competition and choice, but they're also designed, through the work that's been done, to make a more stable, more secure, more user-friendly namespace. And then finally, to let you know what have we got to get ready to launch. So let's talk about that because, you know, hopefully that getting ready will be three of the four bullets on my -- on the next presentation that's given on this issue. So the big success here isn't really about new gTLDs. It's really about the ICANN community and how we work together. The policy development process is purposefully deliberative, and sometimes show, and, you know, there's relatively few consensus policies. But in order to get a good product that ensures DNS stability and security and encourages competition in the right way, the community has really come together in a very unique way over the past several months to solve several thorny issues associated with the guidebook. So whereas a few months ago, you know, we couldn't even say, IRT or STI or ZFA or HSTLD, you know, or TDG or IDN working group, now we -- what's happened is these working groups have come together in a relatively short -- not even a relatively short -- a short period of time, formed, solved very difficult issues, and had those results and those solutions inserted into the guidebook. And so, you know, I think it's gratifying for me and gratifying for the ICANN staff to be able to label this as really a success of the ICANN model, the bottoms-up multistakeholder model, where, you know, two-thirds of the way through this implementation we all looked at each other and said, "Well, here's a problem that shouldn't just be left for staff to solve." And we formed these multistakeholder cross-functional groups that really have different interests, different areas of interest, and came together and got to consensus on a lot of difficult issues. So I think -- I don't know, I think we're all -- I think that's one of the big stories of this meeting as we talk about, you know, accountability and transparency in the ICANN model, and Internet governance and how this should occur going forward. While we -- while we come in here and talk about new gTLDs and the rules around them, it's really become a model of demonstrating the success of the ICANN model. So I've beat that to death, but I just want to use this graphic to point out, since the first guidebook, all those many years ago, all these groups have formed along this time line and resolved issues associated with versions of the guidebook, so the next version could be published. And along the way, there were consultations, you know, all over the world, and a couple -- a couple in Latin America, a couple in Asia, Abu Dhabi, London, New York, so a lot of face-to-face meetings, a lot of conference calls. These teams that formed worked long hours, met more than once a week over the phone at very odd times for some of them, because there were global teams to come together and do this. So all that work, what's resulted? So we have Version 4 of the guidebook. We -- we publish a red-line version. The differences from Version 3, so everybody can clearly see the changes that were made. In order to explain the thinking behind those, we publish explanatory memoranda in a model that's used in many other areas. In addition to the explanatory memos, we have independent reports from six working groups. There's also a couple other papers published this time. A new gTLD budget that I'll talk about in a little while that's separate from the ICANN budget because its timing doesn't coincide with the ICANN fiscal year and defines the costs necessary to finally launch the program and then operate it. And then Phase 1 of what's going to be a two-phase economic study to answer final questions about the net benefits of new TLDs. So I could wax on about all that work, but what I want to talk about is so what do we think that's left? What did we hear coming out of recent meetings, most recently in Nairobi, what did we hear coming out of the Nairobi meeting that required resolution? And these issues were really made clear to ICANN staff and the community in the different consultations. So for example -- this is kind of shining in my eyes. So for example, in the registry agreement, there were two big issues: Vertical integration and the process for amending the registry agreement. So both highly contentious issues with interested parties and interested members of the community. And so, you know, solutions for both those are published in the guidebook. Issues around geographic names, whether country names and territory names should be delegated new TLDs. There were IDN issues outstanding. Whether the -- whether the three- character requirement for top-level domains should remain when we have IDNs in the root that -- in languages where -- I'm going to say this wrong, right, because I'm American, but, you know, symbols are used instead of letters and so a three-character requirement might -- you can imagine might hobble the use of TLDs in communications in those areas. And then trademark protections. We've -- we've published models for trademark protections now, finally getting them into the guidebook proper and memorializing them and firming up that these rights protection mechanisms were going to be part of the plan. And finally, mitigation of malicious conduct. So we're going to talk about these all a little bit, and to do that, I'm going to ask Karen Lentz to come up. Karen -- almost all of you know by now -- is more singularly responsible for all the words in the guidebook than anyone else because she wrote them all. She writes them all, in consulting with our experts at ICANN and experts in the community and meetings and reports and stuff like that, but still in the new gTLD Hall of Fame, you know, her marked-up version of the guidebook will be there. So I'll turn this over to Karen. >>KAREN LENTZ: Thank you. So there were a number of changes made between Versions 3 and 4. If you scroll through the red-line, you'll continue to see a lot of those. The ones that are on this slide are kind of the major ones that I'm going to be talking about today. There are also a number of smaller changes in terms of clarifying something that came out in the public comments that wasn't clear or people asked for examples or further explanation or detail on something. So that's also a lot of the -- the source of changes. I'm going to go through these by Module. Modules 1, 2, and 5 are the ones that had the most changes in this go-round. So as Kurt mentioned, Module 1 is kind of an introduction and overview of the entire process, so it includes a lot of -- it covers a lot of areas. One of them is -- you know, to start out with -- what types of entities can apply for new gTLDs, and one of the sections that touches on that is the discussion that's been going on in the community concerning vertical integration. That is, co-ownership between registries and registrars. And so what's -- the position that's been included in draft Version 4 is a default position, which essentially prohibits co-ownership between those two entities. And it's a default position because we know that there is this ongoing work and discussion, collaboration going on in the community, and it's expected that the result of that would supersede the position that we have in there right now. Also, in Module 1 is a section on IDN requirements, so for an applicant that's expecting to apply for an IDN string at the top level, there are certain additional requirements and information that's needed for that. So in that section, we've added a discussion of variants. Variant characters are characters that can essentially be substituted for one another. So when you're -- when you're in a context of registering domain names, there are scripts where one or two or three or more characters are considered variants of one another and can be substituted in different strings. And so a variant TLD string would be a string that substitutes one of those characters for another. So you might apply for one TLD string and then include in the application other variant strings for that TLD. The position that is in Version 4 of the guidebook is that variant strings -- variant TLD strings are not going to be delegated in the short term. The kind of prerequisite to being able to delegate IDN TLD strings is the development and acceptance and testing of a mechanism for managing variants at the top level. So that's the position that's reflected in Version 4. Additionally, in Module 1, it takes you through all of the stages that an application goes through, or may go through, once it's been submitted. We've been able to, in this version, enhance a lot of areas of the process that were kind of left open or were more -- were less precise in earlier versions, so... Oops. Sorry. So we've been able to include specific time frames and posting periods. Points in the process where an applicant is notified of the status of their application. Points where material about the application is going to be publicly posted. There's some clarification on the public comment period and that process, how that figures into the consideration of applications. There has been -- in addition to the code of conduct that all evaluation panelists or anybody who is in an evaluation role are expected to abide by, one of the things that was asked for in the comments was more discussion of how ICANN will address any possible violations of that, so that's been included. There's more description of how you actually go about registering to use the TLD application system, what kind of questions are asked, how that process works and how you actually finish filling out the application and send it to ICANN. And finally, there's a description of the background check that occurs that ICANN is going to conduct on those applications and how that works. So moving on to Module 2, Module 2 considers all of the various reviews that an application goes through. There are two areas that I'm going to talk about here. One is the -- the IDN three-character requirement, which was in previous versions a requirement that all -- any string applied for as a gTLD had to be at least three distinct characters. That was a concern to a number of people and groups within ICANN, within the community, especially in regard to IDNs, and so there's been -- in response to work that's been done -- a revisiting of that requirement so that the IDN requirement is now two characters, subject to some other tests in a particular case where a string might cause problems. The other area of change here is in geographic names at the top level. Based on advice from the Government Advisory Committee in some of its recent communiques, applications for country and territory names have been excluded from the guidebook for the first application round, so applications for those would not be approved. The -- you know, that area is expected to be impacted by the policy development process that's going on within the ccNSO right now, having to do with IDN ccTLDs. Also, on the topic of geographic names, we also included a -- an example of a letter of support from a government. In the case of any other type of geographic name that's applied for as a TLD, there is a requirement that the applicant also provide evidence of support or non-objection from the relevant government or public authority, and so that was an area where we got a lot of questions about, you know, what needs to be in it and who needs to sign it. And so we gave, kind of as guidance, an example of what that type of letter might look like. Okay. Module 5 actually is where a number of the changes are, and Module 5 covers the transition to delegation, and it's where you find all of the requirements that will be in place for a TLD applicant that's successful. Once the application is approved and that applicant goes on to sign a registry agreement with ICANN, they become a gTLD registry operator, and so a lot of the changes here are requirements and standards that are going to apply to that new registry operator. So first among them here is the trademark clearinghouse. This is an area that's been talked about for -- I don't know, over the last year or so. What it is is a central repository for trademark information to be stored and disseminated regarding rights that have been submitted to the clearinghouse. It comes into play in terms of new gTLDs in that there's a new requirement for all registry operators to offer a prelaunch service that will help to protect those trademark rights, using data from the clearinghouse, and that would take the form of either a sunrise period or a trademark claims service. And the details of that are available in the guidebook. The Uniform Rapid Suspension System is another new requirement. This is something that goes into effect postlaunch, so once a new gTLD has launched and is accepting new registrations, it's another remedy that a rightsholder can take if they believe that a registered domain name is infringing their rights. It's meant to be supplemental to the UDRP. The UDRP continues to be available, and the intention with the URS system is that its -- you know, provides a rapid means of suspension and it's also at a reduced cost as opposed to the UDRP. It's also, you know, as a result of how it's evolved, it does include defenses for registrants. It incorporates varied uses of domain names. It's really intended for clear-cut abusive cases. Post-delegation dispute resolution has to do with, again, once a registry has launched and is accepting new registrations has domain names registered in the TLD. There may be a dispute filed against the registry operator on -- for a couple of reasons. One of those could be trademark-based, so if a -- a rightsholder is alleging that the registry operator is systematically encouraging or -- encouraging bad-faith registrations or acting improperly to infringe rights, that's a forum where those types of cases would be heard. The other is the community registry restrictions dispute resolution procedure, which has to do with the case of a community-based application where a member of the community believes that -- or, you know -- or a group believes that the registry operator is not fulfilling the community-based mission that they noted at the time of their application, and that would be written into their agreement in the case of a community-based application. So those are two mechanisms available to deal with those types of disputes. Okay. The zone file access requirements are another area that's been incorporated into the draft registry agreement. Currently, there's a model where gTLD operators are required to make access to their zone files available. That is kind of done on an individualized basis now, so what the ZFA working group has done is to come up with a standardized model for doing that, so in an environment with a large number of gTLDs, those who are interested in accessing and using the zone file data can have a single point of access for that. It's also expected to reduce some of the administrative work to -- for the registry by standardizing the access and the data formats. There is still room, however, for the registry operators and others to introduce individualized services that would fit their particular circumstances. Also, in Module 5 in the agreement is a discussion of the registry transition process model. There's an explanatory memorandum on this topic that goes into a pretty good amount of detail about the steps that ICANN could take in the event that a gTLD registry operator would fail in one of its critical functions. So the intention with this is, in an environment with a number of gTLDs, to have a process that's preestablished for a case where: (a) there's an emergency and we need to find a backup provider to continue the critical functions and continue the service to registrants; or (b) there's not an emergency but there is a circumstance where somebody is going out of business or wishing to transition for some other reason. So both of those processes are laid out in the guidebook and the agreements are written with those processes in mind. Okay. Finally, the registry agreement itself is an attachment to Module 5, and these are three of the key changes up here. The first is the process for future amendments, so there is a current draft of the registry agreement. There may be a case where one or both parties would wish to change provisions in it. And so the process that's been included there allows for future amendments when they're supported by ICANN and the affected registries, and there's a process for how those can get approved and implemented. There's also a new provision concerning change of control, and that has to do with if a registry operator is being acquired or sold or in some other way assigning their agreement or their responsibilities to another party. So that is a new provision that requires ICANN consent in those cases. The intention with it is to ensure that a party is not taking over a gTLD registry who has never been vetted or reviewed or looked at by ICANN at all. Finally, there are some alternate passages in the agreement that are meant to apply in the case where the applicant is an intergovernmental entity or a governmental entity. In those cases, there are certain provisions that would be slightly modified and so an example of those is included in the registry agreement. And I will turn it back over to Kurt Pritz. >>KURT PRITZ: Thank you, Karen. We're back on? Thank you. That was great. So as an example of how we've listened and the amount of change that's gone in, I don't know if we can pull this off, but this is the new gTLD proposed registry agreement. And if we can scroll through, it's the agreement -- you can scroll through pretty darn fast -- but it is the changes that have been made since Module 1. You can even go much faster than this. There is not much left. There is not much black left. So I think -- you know, two things, one is we didn't do such a good job when we wrote the original version, but I wouldn't say that about us. [Laughter] And, two, though is there has been a lot of consultation and community discussion and negotiation about what these terms should be and how they can best protect registrants and form a competitive environment where new businesses can flourish because those are two of the goals of this process in particular and they are also embedded in ICANN's mission statement, of course. So one of the ways we want to do that, if we can go back to the presentation -- thanks very much, that was great -- is that the end result at the end of the day, we really want to improve the DNS. We really want to improve the namespace, make it stable and predictable for those that are using it but make it flexible so we can encourage innovation. So the introduction of new top-level domains really provides us with a platform and kind of a singular opportunity for doing that. And, you know, at the urging of the community members, if you remember way back at the Mexico City meeting, I think this is where we identified two of the so-called overarching issues of trademark protection and mitigating malicious conduct. And as Karen described, there's firms rights protection mechanisms that are now in the guidebook that formally were in the -- in the prenumbers, they were outside in alternate guidebooks or some other document. And those are the trademark clearinghouse which supports sunrise and IP claims services, the URS, the Uniform Rapid Suspension service, and also a way of handling post-delegation disputes where rights holders can assert claims against registries for their affirmative conduct in how to conduct the registry if they are violating agreements. So these -- these new rights protection mechanisms are intended to provide protections across the continuum of registry operations. And what I'm trying to say is they cover registry inspirations in their prelaunch and launch phases and also provide protections in the ongoing operations. So in prelaunch, before the registry actually opens for business and takes registrations, the clearinghouse and its support of the trademark claims and the sunrise process provides protections for rights holders as the registry starts up operations. And then once they're open for business and the registry's launched, there's other rights protection mechanisms there to provide those safeguards for rights holders and property rights holders. And those are the Uniform Rapid Suspension, the post-delegation process. There's a requirement that new gTLDs maintain thick WHOIS databases to facilitate searches by investigators and then, of course, we also have UDRP which is existing already. So if you look at the environment with current gTLDs which is a very stable environment where businesses are thriving and many opportunities are generated. Going forward for these new gTLDs, we have additional rights protection mechanisms both at the top level and at the second level. So I won't read that because it will be boring and you have already heard those terms. In addition to rights protection mechanisms, we heard a strong message from the community that we should act to mitigate the opportunity for malicious conduct as there's many more times new gTLDs or gTLDs, does that mean there will be many times the opportunity for malicious conduct? And Greg Rattray, who is ICANN's chief Internet security advisor, ran this community consultation and delivered these results. So I will let him talk. >>GREG RATTRAY: Thank you. Good afternoon, everybody. As Kurt mentioned, this portion of the work effort related to new gTLDs was initiated, basically, out of the Mexico City meeting last spring as one of the four overarching issues. So both Karen and Kurt have touched upon aspects of this. What I will probably try to do here in the next few minutes is really just show you the package of things that have been developed in order to deal with the community concerns that have been raised related to malicious conduct. So, you know, as the slide shows, we started a -- basically, a consultation asking a variety of groups and the types of groups that we interacted in -- interacted with during that four-month period, the real crux of this was the Sydney meeting last June where we had a series of panels on malicious conduct and different expert groups provided us perspectives on what the issues are. And based on those -- sorry, yeah. Okay. Based on those -- I have to moderate the actual force in my voice if I'm going to speak into a microphone. Based on the issues identified by the experts, we published a study which occurred last October -- and the next slide -- do I have the slide flipper? I do. They are listed here. What we decided to do was create a series of mitigation measures that would be incorporated mostly in the draft applicant guidebook. And I'm going to specify where these things are specifically located but also to initiate some work on two programs which have already been mentioned: The zone file access and the high- security TLD programs. So the first six of these measures are actually incorporated in one aspect or another in the draft applicant guidebook. Vetting registry operators, there are provisions for understanding who is the -- the qualifications but also the background and, basically, checks on who are operating new gTLD registries. It is specifically called out that applicants must have a plan for DNSSEC deployment, and that includes being able to sign zones with DNSSEC at the initiation of operations, that new gTLDs are prohibited from wildcarding. And this was also reinforced by a board resolution on the same topic. There's an identification of a relatively small but important issue, which is orphan glue records in domain name files are sometimes a place upon which malicious conduct is conducted. Therefore, there was a prohibition that new registries have to show us the plan for how they plan to remove such orphan glue records. And with the trademark protections, similar requirements for those who work on investigatory activities, thick WHOIS is in the draft applicant guidebook as well as the requirement at the registry level to document an abuse point of contact as well as a procedure or policy for handling abuse complaints. All of these things were actually in Draft Applicant Guidebook 3 and continue to be obviously -- or they are in the new version of the draft applicant guidebook. There is another measure which we had put in place largely as a result of the Conficker worm response which ICANN participated with, with probably many of the organizations including some of the individuals in this room. And what we had done in light of that process was provide for an expedited request from registries and potentially registrars if there were issues that they needed dealt with quickly related to combating a situation. The particular case in Conficker was it was going to misuse large number domain names and there were a variety of ways to block the use of those domain names and we wanted to have a quick procedure where there would be no contractual issues if a registry wanted to take action quickly in the case of a security situation. So we put that process in place and it currently is in place. And the draft applicant guidebook points to the materials on malicious conduct point to where you can find the details of the expedited security request process. The real work that's occurred since about the -- oh, probably after the Nairobi meeting when we stood up two advisory groups, one on zone file access -- Karen has actually described some of the current state of the proposal that that working group has put together. I think, though, one thing I would add on zone file access is the requirement for this was that, you know, in a situation where there is a limited number of registries, you can work 13, 12, 10 separate agreements, if you are an anti-abuse organization or trademark protection organization. But if the new gTLD program scales to scores even hundreds of top-level domains, the responders would like to have some sort of single place to go and standardization as they get information related to zone files that allows them to do their work in terms of identification of malicious activity. So that working group -- and I'm going to show you the link in a second to their efforts, but that group has been underway. Has actually concluded their work and out for public comment in the explanatory memorandums of the draft applicant guidebook is their recommendation about how to stand up a clearinghouse that helps users of zone files get information in a standardized fashion and helps those registries provide that information in a lightweight and effective fashion. Then probably with a little explanation as well, in October along with Draft Applicant Guidebook 3, we published a concept paper for what we called a high-security top-level domain. At that point it was called a verification program. We tended to refer to it as a certification program in the work that's currently ongoing. The notion here -- two important notions here, first, it is a voluntary program. It is not part of the draft applicant process. Therefore, there are not specific provisions for getting a high- security TLD certification in the DAG. It is an option for those who might stand up new gTLDs as well as existing TLDs. We've left the scope of the program open to basically be about what constitutes a high-security zone to include what has to happen at the registry and registrars and even some obligations to the registrant level, the full set of processes and controls that might be necessary to provide a certification all with the intent of providing increased trust to users to such a zone. There is a strong input particularly from the banking and finance communities but others in the security community that to be able to create zones of such a nature would be a highly value-added proposition in an environment where there are a large number of TLDs. Next slide. sorry. Obviously I have a normal procedure for this. So the way forward. Really, we believe that the work that's been done so far, both the work that had been done up through October and put into Draft Applicant Guidebook 3, there are current really strong efforts in creating a workable approach with strong participation both from the registries involved as well as the people who use zone files to create a viable concept for zone file access clearinghouse. In addition to the work in progress that's ongoing with the high- security TLD advisory group constitutes a set of measures. We'll show you kind of a before and after slide next. It really creates a prospect for new gTLDs to be a more securable environment where we're actually making progress on the issues related to malicious conduct, not worsening the situation. So listed on the slide we have, basically, a synopsis of where these nine measures have been, where they have been either implemented already or, you know, the progress that's been made and the effects we believe they'll have. That's located at the first link on the slide in front of you. And then the proposal made by the zone file access advisory group has the link listed as well as what we call the snapshot or the work in progress for the high-security TLD advisory group. I will note that that group has done most of its yeoman's lifting in terms of identifying a very comprehensive set of controls they think are necessary in a high-security TLD. So if you believe -- you want to look into what sorts of controls that, you know, the security community, in particular, felt like would be necessary to provide confidence and trust, that work is listed as a matrix of that controls structure in the high-security zone advisory group snapshot at the link there on the slide. All of these are listed as part of the explanatory memos as draft applicant guidebook 4 and, therefore, we are open to comments on either the work that's been done on the other measures. Certainly look forward to whether the zone file access is something ICANN should move forward and implement and the high-security zone advisory group would certainly welcome any comment on their work as it progresses. I'm not going to say that one more time. I only have one more slide. So where do we think we're at is, you know -- we see some security measures related to today's generic top-level domains. What we hope we've done through the work we've put into the DAG and the proposals of the working group is create a possible future names situation which is stronger for both users and in the enforcement potential for malicious activity that might occur in those domains. Again, anybody who wants to understand better the expedited registry security request process, we can do that explanation as well. So, Kurt, I think with that I will leave it and turn it back over to you. >>KURT PRITZ: Thanks, Greg. That was terrific. So getting ready. Be still heart. What do we have to do -- what things do we have to get out of the way in order to launch the process and how is ICANN getting ready to administrate the application process, the evaluation process itself and then be able to provide service to a large number of new top- level domains. Well, the first two have been with us for a while and won't be surprising to you. But marching towards the end, the phase 1 of a two-phase economic study was published just before this meeting. It's a -- it's really a survey of the existing marketplace based on studies that have gone before but also reflects the opinions of the economists performing the study, Greg Rosten and Michael Katz, as to what the potential benefits or for new gTLDs, what the potential costs for the new environment are and what's the net of that, what's the net benefit? If the net benefit of the program is positive, well, then it is a good thing. And it describes competitive benefits, you know, benefits to the TLD owner and social benefits, the benefits that will accrue to the rest of us. And then describes the costs -- trademark holding costs, costs of malicious conduct, other costs, the costs of running a TLD associated with an environment with a lot more gTLDs. There's a lot of suggestions in the report about how additional benefits or the maximum benefits can be realized. At this stage, you know, those are in the reports as suggestions to be investigated. Phase 2 of the study, which will be delivered in the next few months, will really tell us what the net benefits of new gTLDs are and how they might be maximized or how the costs might be minimized. And so where we are is that there's an agreement in principle that phase 2 of the study will take the shape of case studies that will include some data gathering -- data gathering and empirical analysis in order to derive some quantitative results to describe the net benefits of new gTLDs. And, of course, we'll all anxiously anticipate that. Root zone scaling is an issue where there's been a lot of work by ICANN's technical community and is meant to address not just the introduction of new top-level domains, of course, into the root zone but the nearly simultaneous introduction of DNSSEC, which is a great success that's been talked about at this meeting, IDNs, another great success, IPv6 and additional TLDs, almost simultaneously. A perfect storm for the DNS but also a perfect storm of remarkable successes, I think, for this community. And so an independent study was delivered. Staff prepared a paper that forecasted delegation rates for various volumes of gTLD applications, and our collective technical community are looking at those reports going to provide advice. So how are we funding this? We have talked often in the past about a new gTLD budget. So why do we need a new gTLD budget. Well, first because we have to -- there's some significant expenditures that need to be made. And what should the timing of them be? Well, it is uncertain. We want to time those expenditures in a fiscally prudent way. In other words, if we need to lease new office space in order to evaluate applications, you know, we don't want to lease that office space until we're pretty darn sure the program is going to be launched and we know when, so we don't have white elephants and we are not ineffectively spending the money provided to ICANN by the Internet community. And so this budget is naturally out of sync with ICANN's annual operating budget. And so thought the best way to do that is to create a separable budget. And so that budget has been posted for public comment. After public comment, proposed budget will be posted and approved in much the same way the ICANN annual budget is posted and then discussed and approved. So it's in an open and transparent way. The other reason why we want this to be a separable budget is the operating budget for administering the program, most of us have done the back of the envelope calculations if the application fee is $185,000 U.S. and it's a revenue-neutral program, that means we're -- ICANN will be receiving quite a bit of funds and expending quite a bit of funds. And taking that whole thing and making it separate from the day-to-day operations of ICANN is important so that this one budget doesn't kind of swallow the whole or become commingled with the whole. That's very important. So I encourage you to read that budget. And we will take the public comment in and formulate a budget that can be approved by the board. We're also looking for ways to support applicants. There is a board resolution that came out of the Nairobi meeting that tasked the community, again, with developing ways how applicants can be supported. You might immediately leap to financial support. But there's many forms of support given to applicants through education, helping with DNS or DNS operations education, technical education and the like. So cross-SOAC group has been formed since Nairobi and has already developed a charter for their ongoing work. So that charter is published by -- published for comment. So during those preparatory things, how is ICANN getting ready to administer the program? We have to implement the process for evaluating these applications. TAS is an acronym because we don't do anything without an acronym for the TLD application system, the online system by which applicants will apply. We have to retaining evaluation panels, evaluation panel service provider and we need to support all that with infrastructure. And so a lot of work's been done. We have a procedure book that's going to govern day-to-day operations, so procedures have been written for all these things here. Some are administrative procedures for how the organization that evaluates applications is set up, and some are the processes by which the applications are evaluated. And then we also have to retain panelists. So there's an open way of doing this where ICANN is publishing requests for proposals for those who wish to provide evaluation services. There's a vetting process to identify the top candidates that can provide quality services, enough of them in a global scope at a reasonable cost. And so winnowing down of candidates, interviewing top candidates and then selecting those candidates. So you can see in many cases, we're three-quarters of the way through that process and on the cusp of retaining evaluation services in time for this so this might be an eye chart in the back row because I -- in preparation for this, of course, we put our slides up and then we stand in the back and squint. But what this is intended to indicate is that for panels for a technical evaluation, financial evaluation, string similarity, geographic names, and community priority evaluations, a lot of this process is through and we're ready, after a very careful evaluation, to make recommendations to retain certain firms. And there's a couple more panels on there that I didn't read over. Also, we're interviewing and retaining dispute resolution providers, so it's been described in the past for the different types of objection in the new gTLD process that providers have already been retained, and they are listed there. And now we've embarked on retaining dispute resolution providers or service providers for the new trademark protections that are now in the guidebook, so the Uniform Rapid Suspension System and the clearinghouse, for example, you'll see posted soon requests for proposals to provide those services. So how do we get to "done"? Well, we're about at that line there. We've just published Guidebook 4. The public comment period is open through sometime in July. At that time, I think everyone here that's read through this material is familiar with the process that ICANN will take all the comments in, those made at the microphone here later today and throughout this meeting and then written in later, and do analysis and make some adjustment to the process. So is this -- is this the last draft guidebook? Well, it's really up to you and the ICANN community. When the board can look at the comments and determine that the iteration or the change between this guidebook and the next one is reasonably small, so that it is felt that everyone in the community is really on notice for what's in the guidebook and the conditions for applying for a new TLD and is satisfied with them that the subsequent change won't be so great as to really change what people have already commented on. Then I think we'll feel comfortable in saying that this is the last version of the guidebook. So, you know, let me say again that a lot of solutions in this version of the guidebook really came from the community. The process for amending the registry agreement, the PDDRP, which is the post- delegation dispute process rights protection mechanisms, came from the community. So it's atypical as an ICANN staff member to feel somewhat comfortable that what's in the guidebook will be met with some level of agreement by members of the community. So we'll take the public comment in and then make a recommendation for community and board decision whether this should be the last draft version of the guidebook or not. We have to finish the economic study, finish the program budget and get that approved, continue on with our operational readiness activities that are tracking to a program plan, continue executing on our communications strategy and the policy recommends a four-month communication. Well, we would just want to hit that over the head with a sledgehammer in an attempt to ensure that nobody in any region of the world comes up after the process is launched and says, "You know, I didn't know about this." Finish the root zone scaling study and then provide applicant support. And those are the remaining tasks to getting done. So I encourage everybody to read as much of these voluminous materials as they can stand because it's -- you know, we're on the verge, on the cusp here, I think, of making some big decisions that are going to change for the better what the DNS environment is, and we'll all have played a role in it and we want to feel good that we took advantage of our last chance to comment and change the guidebook for the better. And so you can do that here by asking questions, comment in the comment forum, and also there's more sessions here in Brussels. As I mentioned earlier, there's a TLD basics session on Tuesday, an IDN session on Wednesday that will focus on variants in the fast track process. A great success. Wednesday, there's also a trademark session that is -- focused on brand management in the new age of gTLDs. Wednesday also is a workshop, "Reducing Barriers," which is really about supporting applicants in accordance with the ICANN resolution that came out of the Nairobi meeting. Thanks to the great work of our chairman. And then throughout the meeting also, there's a -- throughout the sessions, there's briefings for different stakeholder and constituency groups. And so I encourage you to attend those sessions and participate, get up to speed in everything that's going on. So thank you. I want to thank Karen and Greg for helping in this, and -- but really thank the ICANN staff for the work they did. And mostly thank everybody here for their participation in the ZFA, HSTLD, STI, IRT, IDN working group, and the VI working group. So thank you very much, everybody. [Applause] >>KURT PRITZ: So I'm -- we have a team here and we'll attempt to answer any questions you have now or answer your questions later that are put on the record. Hi, Steve. >>STEVE METALITZ: Thank you. Steve Metalitz, here on behalf of the Coalition for Online Accountability. I do have a number of questions but I want to focus on some of the issues that Greg talked about in the high security TLD zone proposal. I agree with the -- it's clear that the guidebook has raised the baseline for the things that a registry would have to do to try to protect against malicious behavior in the new gTLDs, and I think that's -- that's definitely a step forward for which I commend ICANN. But as Greg stated, there are some top level domains where it is, quote, necessary to provide confidence and trust by hitting a higher standard, and that, as I understand it, is what's in the HSTLD proposal. But this proposal remains a voluntary program, and it remains a program in which there is no incentive given in the evaluation process for anyone to meet this higher standard. And to give the example that has been given so many times, if someone wants to apply for dot bank, they gain absolutely nothing in the evaluation process by meeting the HSTLD standards, as long as they meet the baseline standards. Now, we have repeatedly pointed out this problem and urged that at least some of what's in the HSTLD level be made part of the baseline, and we have a -- obviously have not persuaded the staff that that should be done, so let me offer another possible approach to this. Is there any way, in the guidebook now -- or should there be -- for someone who believes that meeting the baseline is not enough for a particular top-level domain to bring an objection or in some other fashion require ICANN to consider whether applicants should meet for that TLD should meet a higher standard. Such as what's embodied in the HSTLD. You can object if someone is infringing your trademark in their TLD name. You can object on community grounds. There's various grounds. This is not a grounds for objection, which is that someone meeting the baseline will be opening up a TLD, if approved, that will be too vulnerable to fraud and illegal activity than it should be. So I would ask whether there should be some method for raising that objection, and I'll suggest that perhaps that could be a job for the independent objector. Thank you. >>GREG RATTRAY: Steve, we actually have had these discussions quite a bit with some of the industries -- again, particularly banking and finance -- that were kind of the origins of the high security work. In our dialogues with them, you know, Karen, I want to be sure I don't misquote, but I remember in the October time frame specifying that there would be language -- you know, an example of an objection could revolve around a community's belief that a zone -- you know, that an applicant would not have a high enough security, you know, posture in what they've provided in their application. So I believe we have noted that as a potential objection criteria for -- >>STEVE METALITZ: But Greg, that would only apply in a case in which the objector met the standing requirements for a community objection, and in which they could satisfy the other standards. So in other words, someone who is not -- to bring an objection on this ground, you would have to organize an entire global community to point out that a -- that someone who is not putting adequate protections in place has applied for dot bank. My suggestion is, those two are two separate questions. The community objection is that you're not properly representing or you're improperly exploiting my community. The security objection, if you want to call it that, is this TLD, while it may meet the baseline, simply doesn't have enough protections against malicious behavior and should therefore be scrutinized again. And I think those are two separate standards and I don't see why someone should have to meet the community standing requirements, which are not insignificant. And Kurt and I have talked about this many times. They're significant. And they should be in the community area. But it seems to me that that's totally separate from the concern that malicious behavior is not adequately protected against. >>KURT PRITZ: Thanks, Steve. Philip? >>PHILIP SHEPPARD: Thank You. It's Philip Sheppard, speaking in this instance on behalf of AIM, the European Brands Association. I've got a specific issue to do with the trademark clearinghouse, and I think in the current version of the DAG, you have, alas -- perhaps as part of the horse trading that went on -- introduced I think some complexity discrimination and potentially arbitrary judgment, all of which you will note are bad things. Let me explain. There was a choice given to registries in how they use the trademark clearinghouse to have either a claim, a notification system, or sunrise, but there was a nuance you have introduced into that, in that if it's sunrise, you're saying the trademark has to have gone through what you're describing as "substantive review." Now, putting aside the fact "substantive review" is actually not an easy term to define, and maybe there's better phraseology that we could help you with in direct conversation on that, what you're doing essentially by that is introducing a discrimination between different trademark registries around the world. And in so doing, you are making a judgment which is arbitrary about the quality of those trademark registrations around the world. And the review itself is not an issue to do with the quality of a trademark. It has to do with the choice of the trademark registry -- be it international, regional, or national -- as to how they wish to administer the system. Basically do we want a fast-track system for our users for innovation, system of the country, or do we want a slower, more thorough one. It's nothing to do with the ultimate quality of the trademark. And by introducing that difference between those who have substantive review and those that don't, I believe you are guilty of making that arbitrariness and discrimination unnecessarily, and for you and for the community, in terms of understanding this system, introducing some complexity. So I'll simply say: Don't do it. Let's just have a trademark clearinghouse. If you're in it, then it's either one or the other that apply. But this concept of substantive review is unnecessary complexity that is going to lead into all sorts of issues that frankly we don't need. >>KURT PRITZ: So, you know, we can -- we can talk more about this, but there's -- there's other ways that a trademark can be honored by a registry, so one is if it's from a jurisdiction where there is substantive review but another is if it's validated through some court process or ruling, or a third, if the trademark clearinghouse validates the trademark by -- by the same process that essentially it would go through as a prerequisite to a UDRP hearing. So we -- we tried in the -- with the input of the community and the board, to remove that discrimination and inequity that was indicated by a lot of comments that we got when we published the STI version of the clearinghouse. So I want to talk to you more later, because I thought we kind of addressed this and I'm looking at Amy to see if I'm getting the answer right. >> (Speaker is off microphone). >>KURT PRITZ: That's right. And so -- and if you use IP -- you know, there's a difference between IP claims and sunrise, too, but I don't want to get into the detail, but if -- in IP claims, every trademark that's registered anywhere in any jurisdiction, you know, will -- has to be honored by registries and IP claims. >>PHILIP SHEPPARD: Yeah, but that is exactly the point. I think that that is an element of discrimination you're introducing, and doing so unnecessarily. That's the point. I mean, having that distinction between the "why one or the other" is a discrimination that I think, as I said, is adding this unnecessary complexity for the wrong reasons. Because ultimately the objective here is fulfillment of public trust, you know. We're not looking at IP protection as an end in itself. It's because of brand protection, public perception, et cetera. And if the trade-off is some sort of private interest somewhere else down the line, well let's say that clearly, and then let's make that balance between the public trust in terms of the millions of users out there and some narrow public interest which might happen to want to that as a distinction. >>KURT PRITZ: Yes. So everything you say is exactly right. In IP claims, it's a notification -- you know, a notification. In sunrise, it's more of a right the name is registered. So in the case of IP claims, it was thought reasonable that even if a trademark's -- you know, any registered trademark, you can be provided a notice that that -- that trademark exists. So there's a difference in the result in IP claims and a sunrise process, so the thinking was there could be a difference in the rules by which registries must honor those trademarks. But anyway, we could talk about this for a long time over several beers. Thanks for your comments. So I think -- well, let's take a comment from -- is it all right to take a comment from remote participation and then we'll kind of -- we'll kind of watch the queue? >>KARLA VALENTE: Hi. This is Karla Valente from ICANN staff. I am speaking on behalf of our remote participants. We had between 41 and 45 people attending our chatroom. We have three questions, Kurt. Or actually one suggestion and two questions. The first ones comes from Erick Iriarte. "We suggest to add in the Paragraph 2.2.1.2, the four regional organizations of ccTLDs -- AfTLD, APTLD, CENTR, and LACTLD -- like reserved names. Like ARIN, LACNIC, AFRINIC, RIPE and APNIC, for IP numbers, the regional organizations of ccTLDs are involved directly in the process of ccTLDs and ICANN. The four ROs have liaisons in the ccNSO Council and participate in different working groups and are recognized by the community. >> Excuse me. Karen, you're speaking so quickly the scribes can't follow you. Could you just slow down a little, please? >>KARLA VALENTE: Absolutely. Do you want me to read that back? Okay. So that was a suggestion. I have a question. >>KURT PRITZ: Go ahead. >>KARLA VALENTE: The question comes from Charles. How the clearinghouse data will be viewed, please. Compiled from different trademark databases or there is a faster way? >>KURT PRITZ: So, again, I'm going to look to Amy to make sure I get the answer right, but the clearinghouse is built by trademark holders applying to be included in the database, so trademark holders that have registered their trademark in other jurisdictions or had their trademark validated through some court proceedings or wish to have the clearinghouse validate their trademark can apply for inclusion. So the database gets built up by the one-time application of each trademark holder. And then of course the savings is, there's only one clearinghouse, even though there's many, many registries, and so it is looked to be an economical solution to trademark holders. >>KARLA VALENTE: Thank you. Can I read the last one? >>KURT PRITZ: Ask Zahid. >>KARLA VALENTE: Can I? Okay. How will non-ISO-3166 applications be considered? For example, how will dot England, dot ENG and dot English be handled? >>KURT PRITZ: It depends. So in the -- in the first round, there will not be a delegation of country or territory names. Country and territory names are defined very carefully in the guidebook and I'm going to attempt to do it here but -- I'm sure I'm going to be off a little bit, but there are the short- and long-form names in the ISO- 3166-1 list. There are the three-letter abbreviations of those names that are also on that 3166 list. There are the two-letter abbreviations. There's -- there's also some special lists that are called out from ISO. There's some work ICANN staff has done to remove some of the ambiguity in those country names. So if there's a combined name, we'd reserve both those names, its permutations of those names, and then translations of those. So read that carefully and then, you know, look for "England" on the ISO-3166-1 list and see if it's there. >>KARLA VALENTE: There's another question and then I'll come back. >>KURT PRITZ: Okay. Zahid? >>ZAHID JAMIL: Hi, Kurt. Zahid Jamil. I speak in my personal capacity to share a parallel example. Karachi, my home, is a port city which has, at times, reclaimed land from the sea. A possible mass reclamation project idea had been floated. It would have benefitted government revenue, land developers, real estate agents, and cheaper housing to citizens. The geological analysis and environmental impact assessment was agreed that it would be done, but it was not made a prerequisite. After lengthy negotiator processes, rules and even legislation were drafted. The geological analysis and environmental impact assessment arrived subsequently. The geological analysis cautioned mass reclamation based upon unknown risks associated with soil strength and seismic fault lines. The environmental impact assessment said that much analysis was not possible, since little or no data statistics were unavailable, and recommended collection of that data and also said that the process should, unlike as currently proposed -- sorry -- be based upon a balance of social and private benefit, but the negotiated process outcomes had already reached near finalization. So when asked, "How come we went ahead with all of this without enough hard statistics, feasibility studies, and analysis, et cetera?" Here I would caution against a wholesale launch of new gTLDs in the context, similarly, of the root scaling study and economic studies, and caution -- and the cautions that have come out in the recommendations, such as recommendations for surveys, et cetera, and the fragility and the risks to the Internet we heard all about at Nairobi. Did we -- and my question is -- put the cart before the horse? [Applause] >>KURT PRITZ: So I -- Zahid, I think those are excellent points. You'll remember that, you know, whether or not to launch new gTLDs and take -- measuring the benefits and costs of those are really a policy consideration, and so the -- the initial work about this was undertaken by the GNSO when they -- during their policy development process and they decided, doing that balancing, that ICANN must launch this process for adding new TLDs to the root. And so that -- that was a policy direction created by our -- you know, our bottom-up multistakeholder process that -- where those stakeholders determined that there is net benefit to the launch of new gTLDs. So in implementing -- so then we were directed to -- by that policymaking body and the board approval implement that process. As we did that, questions were raised about net benefits of gTLDs, additional information became available with regard to trademark, you know, protection costs and potential malicious conduct, and mitigating that, that created in people's mind additional questions with more specificity. So I think -- you know, I think your points are valid. I think it's -- I think it's reasonable, given the policy direction by all of us, to go ahead and prosecute the implementation plan while getting this work done. So, you know, there's some preliminary information about root zone scaling and there's some, you know, already economic analyses that have been done and published that indicate this could go ahead but still more questions remain. And so I -- you know, it is with an abundance of caution that we continue to undertake economic studies and finish the root zone scaling, and certainly if we saw an indication in the -- in the data that indicated that we shouldn't go ahead, you know, our board would tell us to stop our management and -- or we'd go to the community and say, "We think we should stop." And if we see those indications, we can. So, you know, it's all a balancing, in determining the alacrity with which we prosecute the program. >>ZAHID JAMIL: I'd just caution that the economics analysis, economics study, basically says that there should be -- the bottom line, the last paragraph, says there should be limited rounds and asks that you go out and get this data. Which I know you're going to be doing. So I hope that will have not just a -- will feed back into the DAG, but that the things I notice from the study of the economic analysis meant that the structure and the basic principles by which the DAG moves forward may also be impacted. So just wanted to caution that that should not be considered an impossibility. If we do need to get it right by changing the structures, I think we should do that. Thank you. Thanks for the answer, Kurt. >>KURT PRITZ: I understand. Yeah. >>WERNER STAUB: My name is Werner Staub. I speak in a personal capacity. >>KURT PRITZ: Hi, Werner. >>WERNER STAUB: Just a couple of small things, actually. We saw that there is a registry restrictions dispute resolution policy. What is striking, I feel, is that it is only for community TLDs. There could be, you know, a standard TLD that commits to certain policies that suddenly then says, "Now, instead of just using it for that specific purpose, we're using it for something totally different" and thus affect other communities. So I think the same thing should apply just about to anybody who does not respect the initial commitments. That is one element. The other one is somehow related to an earlier question specific about -- what Steve said about representativeness. I think we lack, in the current guidebook, a clear definition of what we mean by "representative organization." It sounds sometimes as if "representative organization" was just an organization that is, as I said previously, a specimen of the species. You know, one bank can go and say, "I want dot bank," because you're -- you know, you're a bank. But that should not be the idea. We should add specificity in the sense that you should be an organization that has recognition to be able to speak and act on behalf of the community. There's other questions, of course, that are related to the fact that for a given community, there may be more than one such organization, and I think we -- I repeat it -- we have a bug in the guidebook if you say that one community that has -- or a representative organization that has standing to object would automatically be protected against anybody else objecting, even if that other one also has standing to object and could possibly have good reason to be objecting. Finally, a small one that's the communications strategy. I hope that once you launch, you inform people like those who are sitting here before they read about it in the press. That, you know, a certain statement is going out. >>KURT PRITZ: Thanks, Werner. So I'm embarrassed to say I can say the word "RDRP" really fast, but the registry restrictions DRP was really narrowly targeted. When you apply for a top-level domain and identify yourself as a community TLD, you get a -- you get a benefit for that, right? You get a chit if there's -- if there's contention between two identical strings and you're a community TLD, you get a chit in that argument and you can prevail as a community TLD. It was -- it was a policy direction, and so with that came the strong urging that with that chit, there be an obligation that you be obligated to follow the restrictions you said you would follow in order to get that advantage in the first place. And so the reason why that's -- and we can talk more about it. But the reason why that's limited to community-based TLDs is that there is no advantage granted -- granted to others that they're regarded as -- as businesses that they become registries and can, within restrictions that they don't, you know, harm DNS security or stability, and aren't anticompetitive and, you know, do all the -- all the things that are in ICANN's mission, that they be free to operate their TLD in a way so -- you know, so long as they do those things and don't harm registrants. So it's an interesting discussion of whether ICANN's role should be to continually monitor the original mission of TLDs and make sure they adhere to that or give them the freedom to change their business model as conditions change and under what circumstances. >>WERNER STAUB: I wasn't understanding that it was complaint-based, so if somebody found it to be -- you know, there to be harm, they could complain and say, "Look, they shouldn't be allowed to do that," so it wouldn't be placing any burden on ICANN, if it was extended to just about anybody who makes a commitment. >>KURT PRITZ: No, it would be -- no, but it would be -- yeah, but it would be placing a burden on the registry, and that's the philosophical discussion is whether a registry should be allowed to change their business or whether they should forever be required to follow a business model proposed in their original application. >>WERNER STAUB: No, it would not be changing the business model. It would be causing harm to others. >>KURT PRITZ: Yeah. >>WERNER STAUB: So if somebody says, "No, that's okay, as long as they're doing that, we're not going to object," this is actually a contract with all those who did not object. >>KURT PRITZ: I got it. >>WERNER STAUB: So there should at least be some remedy for them -- >>KURT PRITZ: Uh-huh. >>WERNER STAUB: -- if it turned out that they were deceived. >>KURT PRITZ: Yeah. I got it. Yeah. Causing harm is bad. So one question? Okay. Thanks, John. Go ahead. Karla. >>KARLA VALENTE: Hi, this is Karla Valente from ICANN staff on behalf of our remote participants. We have one question from Jim Fleming. Is ICANN aware that industry-wide software, hardware changes will likely render your plans moot? Example: You are focused on DOS and users will be on Windows by the time you finish your studies. >>KURT PRITZ: Thank you. >>KARLA VALENTE: You're welcome. [Laughter] >>KURT PRITZ: You know, there's a joke to be made about the length of time the new gTLD process has taken so far, and many things being moot by the time it's launched. John? >>JON NEVETT: Thanks, Kurt. First, I want to -- This is Jon Nevett from Domain Dimensions. I want to commend you and your team on the level of effort and work that went into this DAG and all the accompanying materials. It's obvious that you guys are incredibly dedicated and working very hard in getting this done. To the extent we do talk about a time line, I want to make one practical suggestion, in that in light of the fact that the next ICANN meeting is 5 1/2 months from today, that we put a placeholder in September for a summit on new TLDs, where we could get together as a community anywhere in the world and knock out the rest of the -- the remaining issues that might arise. We did this during the GNSO policy development on new TLDs. We were actually here in Brussels, and then had a second face-to-face meeting, a summit on new TLDs, in Los Angeles, so we -- we had those two face-to-faces, as I'm sure you would remember. I would suggest that we get a placeholder in now and I'm sure the event team is probably not happy with me right now, but I would suggest that we put something on the calendar for September prior to the board retreat, so that way we could, as a community, get together, knock out the remaining issues, and move on on the -- you know, the next phase of this new TLD odyssey. Thank you. >>KURT PRITZ: Thank you, Jon. [Applause] >>KURT PRITZ: Antony? Can you excuse me for one second? So, Jon alluded to a board workshop that's being held in September and that's going to be a two-day session dedicated primarily or solely to new gTLDs and getting through the remaining issues. So thank you, Peter. Anthony? >> Yes, I'm Antony Van Couvering from Minds and Machines. I was reminded by Mr. Sheppard's remarks about substantive review that there is an issue I would appreciate some guidance from ICANN which has to do with the widespread practice of registering trademarks for new gTLDs. At least I can presume the intention of challenging others later. And we know that in the United States, which has substantive review, these have been disallowed, whereas in other jurisdictions they haven't. Obviously, I feel this is to the detriment of the program to do this, and I would appreciate some guidance from ICANN, which I haven't seen, as to the validity of these sorts of registrations. I've certainly heard people talk about that but there's nothing written. Thank you. >>KURT PRITZ: So I think, Antony, I think some of that guidance is in the guidebook and it's -- you really have to hold your finger on the page but for the sunrise process which is the process by which an entity can get a name, there is some validation or substantiation of a trademark required before the registry is required to honor that trademark in its sunrise process. >> ANTONY VAN COUVERING: I think you misunderstood my point, Kurt. I'm speaking not of trademark registrations from the point of view of second-level domains but at the top level. So the registration of, for instance, dot whatever it is, as a trademark, in order to prevail in some kind of dispute between the same or similar -- >>KURT PRITZ: I'm sorry for interrupting. So registering the name dot something as a trademark? >> ANTONY VAN COUVERING: Yes. >>KURT PRITZ: There is a fairly specific clause in the guidebook that says that those -- even if registered as trademarks, those wouldn't be honored as trademarks in the launch process. Did I say that right, Amy? >> ANTONY VAN COUVERING: I would love to see that. I haven't seen it pointed out. Thank you. >>KURT PRITZ: Okay. I will look it up. I will look it up. Mike, are you going to ask a question? >> Bertrand has the mic. >>KURT PRITZ: Bertrand? >> BERTRAND DE LA CHAPPELLE: I want to repeat in the public setting the exchange that we had -- that I had with Kurt suggesting to use the potential typology for the batching and if you could elaborate and return to that. Second thing is the main period in the new gTLD program will be the post-delegation period by definition. It's the years and years and years when we will have the TLDs operating. ICANN may have a tendency to overemphasize the a priori framework and de-emphasize the compliance and enforcement mechanisms afterwards inasmuch as possible try to incorporate rules that are as simple as possible with a stronger enforcement and monitoring mechanism even if it is a mechanism that takes into account a type of wrongdoing that is not anticipated but can be addressed later on. So don't overengineer it first and stress the compliance. Finally, as a lot of people have read with very great interest the economic study that came out, I think a lot of people share the regret, not to say the deep regret, that this didn't come three years ago because it would fundamentally have changed in many respects the general approach of the new gTLD program. We're now going to evaluate the impact of this study on the things that have to change or may change. But, actually, I would like to support spontaneously the suggestion that Jon Nevett said -- made, and I would make an analogy. In any parliamentary process, you have huge preparatory work before you draft a law. This preparatory work usually brings a pile of documentation that is about as high as the Eiffel Tower. But then when you draft the law, you want something that is thin, understandable and very concise. I'm beginning to wonder whether the work done with the draft applicant guidebook, all the ancillary documents, is not the equivalent of the preparatory work and the summit or the main session of the conference that Jon was alluding to would not be the opportunity to produce the 20-page document that would have the regime for the string evaluation and the applicant evaluation, the delegation as a second-part mechanism and the post-delegation mechanism that are exactly what we've been discussing. But that would be much easier for you to communicate afterwards. I would be happy if we would explore this possibility. Thank you. >>KURT PRITZ: So I think that's a great idea. And, you know, one of the -- if I have a regret about, well, some of the policy implementation that's been done, it's that, you know, we've really focused a lot on edge cases in our debates and discussion and really not on, you know, how does -- the evaluation questions and criteria that have been -- you know, carefully written and continually honed but not really hotly debated in rooms such as this where those are the 20 pages where every single applicant will have to answer questions and be evaluated and so, you know, really the most important material in the guidebook. >> BERTRAND DE LA CHAPPELLE: I'm not sure I was clear. The 20 pages would be the regime, i.e., not the questions you have to answer, the process. The 20 pages would be the result of the work we've done. >>KURT PRITZ: I do understand what you're talking about. And, you know, just so you know, Ray Plzak, one of our board members, said exactly what you did about the creation of rules that are simple and easily enforceable when we're having a meeting with our policymakers. I thought that was well-put. Mr. Palage? >>MICHAEL PALAGE: During this time, has ICANN staff been able to find the reference in the guidebook to Mr. Van Couvering's question about them being prohibited? >>KURT PRITZ: I didn't hear what you said. No, not yet. >>MICHAEL PALAGE: Not yet, okay. I would like to follow-up on Mr. Van Couvering's point because I have actually written an article on this detailing, if you will -- I called it TLD frontrunning. And, fortunately, there are some countries such the United States and the U.K. that specifically in their trademark examining guidelines have prohibited such registrations. That, however, is not uniform across all countries. And in my most recent research I've identified about over 100 applications, U.S., South America, E.U., throughout the world, where people are clearly attempting to game the system. Now, while I respect ICANN's ability to deny those applications, that still does not answer the question of what happens when someone gets a TLD and one of these parties do not try to get the TLD but actually sit there and try to extort money by enforcing those rights in a country. And I think this is something where ICANN needs to go to the Government Advisory Committee as well as the World Intellectual Property Organization and perhaps ask their advice because these are people that they are experts in this particular subject matter. And it would really be detrimental if we have people trying to enforce trademark rights and take out TLDs from the zone. That's not good for security and stability. Now, on that point, carrying forward, one of the earlier comments talked about adding some names to the reserve list. I think it was LacTLD and some others. As Dan Halloran may recall, I participated in a reserved names working group about four years ago when we started to talk about these reserved names. And at the time, I articulated that ICANN should receive no further benefit that other trademark owners do not have, that if ICANN felt confident in the trademark protections for a Yahoo! or a Facebook, they should also feel confident to use those same rights. I would like to reiterate a point I raised over four years ago. There should be no exclusions. ICANN should receive no preferential treatment. Now, if it does remain committed to receiving preferential treatment, I think it needs to look at expanding the names list, specifically as a U.S.-California non-profit corporation, the U.S. has passed statutes regarding 70 designated terms, including Red Cross Olympics. The IOC has written to ICANN raising these points. So I think from a consistency standpoint, what's good for the goose is good for the gander and you really need to reevaluate the reserved name list. >>KURT PRITZ: Thanks for those excellent comments, Mike. >> CONSTANTINOS ROUSSOS: Hi, Kurt. This is Constantinos from dot music. I would like to discuss the outreach campaign, the communication campaign. I know I have been running with my initiative for years now. And in the DAG, there is no protection for someone like me. To Michael Palage's point, I do have a trademark in dot music. And we've been working on this for years now and trying to communicate what we're doing to the whole world, and that's what we've been doing. However, the DAG does not ensure myself and any other applicant that has been around and working on it any fairness, I might say. I will give you an example. Let's say the applications start. Some other dot music applicant comes in and says, "Hey, pay me $400,000 to work. We'll do auction or we'll do that." These are real-life scenarios. So there's a few things that need to be considered. So if outreach and communication is important, maybe in the DAG you guys can add a point somewhere that says, Hey, if in your community application you've done sufficient outreach," let's say a year, "then you get an extra point," or something that gives a good job for doing something and reaching out. My second point is in regards to the fee structure. I know I'm very interested in looking into IDNs, so dot music in different languages, whether it is Russian or Chinese. The problem I see, I looked at the fee structure and since everything is under one application, translation that is, does that mean I have to pay $185,000 every single time if it is an IDN gTLD? And why is that, if it is? And my other thing is why did the IDN ccTLDs only cost $25,000 or there was a waiver when I'm doing one application with seven different strings and each one costs $185,000? I want to see the fee structure and why I have to pay that amount so many times. And I'm sure companies -- maybe VeriSign wants to do dot com, in a few scripts or Afilias wants to do dot info. I don't know what they are doing, but I know some other people have the same concerns in regards to the fee structure. We just want to pay for what's fair under one application. Thank you. >>KURT PRITZ: Thanks for those comments and those very many questions. We recognize the difference in fees between ccTLDs and gTLDs and, in fact, it's the first time ICANN has requested an evaluation fee from ccTLDs in recovering costs. I'm sure you know, because you have been around this a long time, that the new gTLD fee is a cost-recovery fee and is calculated that way and that there's a lot of uncertainty and risk as ICANN, you know, goes into what is an undertaking -- that's the word I'm looking for -- an undertaking for ICANN that's really going to involve for our environment high levels of fees and high levels of costs. And so at this early stage, it's difficult for ICANN to say, well, if you're the same entity that's applying for a TLD, you know, your first string, the fee could be 185,000 and your next fee might be less than that, whether it is a translation of a fee or it's because you're the same organization so the evaluation should be streamlined. There are many ways for entities to combine to reduce their fees. So without understanding what that landscape really is, it is difficult in understanding the risks -- it is difficult to come up with sort of a tiered fee structure in the first round where we feel comfortable that all the risks are ameliorated. So I understand the points you're making exactly because you can sit at a whiteboard and draw out the costs. But the way that the fees are now for each TLD, there's another fee. And I also -- I also understand, you know, the almost frustration of you -- of you all that have been here for a long time working on this process and honing it, invested your time, not only in building up your brand but also in giving your efforts as a volunteer to making sure the process is as robust as it can be and as fair as it can be. I understand it will be for us to think about how those who have participated in the process might be rewarded. So, anyway, thanks very much for your comments. Ron? >> RON ANDRUFF: Good afternoon, Ron Andruff, dot sport, LLC. I follow on when Constantinos and what he said. And, actually, I put a different spin on it. You mentioned community-based applications, and you said that community-based applications get a chit and it gives them effectively a priority. Many communities speak multiple languages or use different scripts. And I use the ICANN community as an example. We translate our ICANN documents into multiple scripts for the benefit of our global ICANN community, so I ask the same question as my colleague, why does the staff refuse to apply some -- the same standard to community-based applicants? In other words, it's not cost recovery to charge a single community that would like to use multiple scripts $185,000 for each IDN script that they need for their community. So this needs some thought as well. Thank you. >>KURT PRITZ: Thank you, Ron. So, Nancy, we have about 15 minutes left, is that right? >> Yes, that's correct, more like ten. >>KURT PRITZ: All right. Mr. Foody, put a sign on your back that says you are the last guy in line. Karla, you have a question from the -- >>KARLA VALENTE: From the remote participants. This is Karla Valente from ICANN staff speaking on behalf of remote participants. The question comes from David Cohen. Actually, it is a statement. "It is likely that further delays will occur in the new gTLD process. Why are IDN gTLDs allowed to continue and finalize regardless of the (inaudible) gTLD process at least in the countries where idn.idn ccTLDs are live? The way it is now is clearly an unfair advantage to the community." >>KURT PRITZ: Thank you. And so -- and, you know, even though it is a statement, the IDN fast-track process and the new gTLD process are both being prosecuted as quickly as possible with the right precautions being in place with the idea that one would not hold up the other. So that's where we are now. Hi, Mr. Foody. >> PAUL FOODY: Hi, Kurt. Thanks very much. Has ICANN effectively accepted this economic report, or will there be an opportunity to challenge its findings? >>KURT PRITZ: The economic report? >> PAUL FOODY: Yeah. It says something about 90% of searches now are done using search engines and, therefore, this is going to mean that there is less of a cost to consumers. >>KURT PRITZ: Yeah, so the report's published for public comment. And if you have different data or different information, I think that would inform the work of the economists as they undertake phase 2 of the study. So if you think some of their underlying facts are in error, I would encourage you to go to the comment forum and provide your source of information in the like. >>PAUL FOODY: The idea is that search engines actually provide definite information, Google has sold off Louis Vuitton to a competitor, and then they sold Gordon Brown off to the (inaudible) department. >>KURT PRITZ: There you go. >>PAUL FOODY: So thank you. >>KURT PRITZ: Thank you. Hi, David. >> DAVID TAYLOR: I was picking up a point earlier from Philip and the substantive review and the trademark clearinghouse and more a question of: Are we looking at unintended consequences? And I think is what's good is that we have included a lot of the European trademark countries within the DAG Version 4. But the fact that we have the substantive review in there, if you're not a country which has substantial review, you can still get in and play in sunrise, if you'd like, provided you join the trademark clearinghouse. So really I'm just wondering if there is an unintended consequence if you have something like 600,000 community trademarks out there, which isn't necessarily a substantive review country. That's arguable. You have got 600,000 trademark owners having to join the clearinghouse or else they cannot participate in any sunrise period going forward. I think that's quite fundamental because then when we also look at fees for that, if you are looking at a $50 fee, for instance, with no figures on that to join the clearinghouse, that's $13 million per year which is pretty big. So just whether we are getting into unintended consequences here. >>KURT PRITZ: Okay, thank you. >> Thanks. >>KURT PRITZ: And with the last comment? >>KARLA VALENTE: Hi, Karla Valente from ICANN staff. I have a question from a remote participant, George Kirikos. And the question is -- oh, sorry. Give me one moment. I'm sorry, Kurt. >>KURT PRITZ: George is going to smell a conspiracy. [Laughter] >>KARLA VALENTE: Okay, I'm sorry. Hold on. Here we are. I'm sorry. It is just moving the chatroom. Hold on. So here's the question: Has anyone read the document by Tim Berners-Lee tied to new TLDs considered harmful? >>KURT PRITZ: Yes. >>KARLA VALENTE: That's it. Thank you. [Applause] >>KURT PRITZ: So if that's it, I want to compliment you all on all the hard work that you've done and help ICANN get to this stage to date and the constructive manner in which we conducted this and your interest and your time invested here today and the expense you went to in coming to this meeting. So thank you very much again. [Applause]