GNSO new gTLDs. Session 2. Los Angeles, California. >>CHUCK GOMES: Okay. We are very close to restarting the workshop. >>CHRIS DISSPAIN: Okay. Ladies and gentlemen, please start taking your seats. We're going to start again in a minute. Okay. Ladies and gentlemen, welcome back. Thank you. We're starting with session 2. >> Hello? >>CHRIS DISSPAIN: Did somebody say hello? Oh, okay. >> Hello, hello? >>CHRIS DISSPAIN: That was somebody over there, I think. We'll wait a couple seconds. All right. We are going to start. We're starting session 2, the contractual conditions for new gTLDs, and Chuck will take us through the first set of slides. >>CHUCK GOMES: Okay. Thank you for those of you that returned promptly. We appreciate that. And we know that many of you may have had a very short lunch or no lunch at all, like some of us. We really appreciated the snacks that were in there. So session 2 is going to cover Recommendations 5, 10, 14, 15, 16, 17, 18 and 19, which are all related to contractual conditions. It will also include implementation guidelines I through L, an overview of the base contract and where that is, where that's going, the projection on that from Kurt as well as some additional implementation details from Kurt. The panel, you'll see that Avri, Kurt, and I are still up here. In addition, Jon Nevett from the registrars constituency -- Jon, why don't you wave to everybody there. Ray Fassett from the registry constituency on my left. Mawaki Chango is unable to join us. And Tony Harris -- I guess Tony's still on break -- will be joining us again as well from the ISPs. The first recommendation I want to go over is Recommendation 10: A base contract must be provided to applicants at the beginning of the application process. Use of the base contract without material deviations will shorten the process. And contracts with individual registry operators might vary depending on the particulars of the new gTLD. So basically, what we're recommending is, there's a base contract that everybody sees up front before the process starts -- and by that, we mean at the start of the 4-month period, not the application period -- and if somebody just uses the base contract, it should simplify the time needed to finalize a contract. The extent to which it is customized may extend some time, additional time. Recommendation 5: Strings must not be a reserved name. Now, I remind you that the reserved names working group's full set of recommendations can be found in Part B of the full final report, but we've provided for you, in the reference guide that printed copies were available and it is linked on the meeting site. If you look at the very last page on the back, you will see a brief summary of all the reserved name requirements for new TLDs. Some of those will become part of the contractual conditions; some of them would be applied in determining whether a string would be accepted or approved at the top level. Note that it is recommended that there be no reserved name category for controversial names, for geographic names, for two-character U- labels -- that's an IDN term -- and for single-letter/single-digit combinations at the second level. Excuse me. At the top level, okay? A single-letter/single-digit. Not two letters. We don't mean that there, okay? I call that to people's attention because I think those are very important to note because there were some who requested reservations of some of those categories. Issues related to controversial names and geographic names can be addressed in the new gTLD process -- resolution process, and challenge process, that will be part of the discussion in Session 3. Recommendations 14 and 15 say: The initial registry agreement term must be of a commercially reasonable length and there must be renewal expectancy. We actually spent quite a lot of time on this, and some of the work came from other groups that were working on this topic. This creates a level playing field for new and existing gTLD operators. The base -- the draft base contract, as originally put forward, posted by ICANN several months ago, contained a term of 10 years, but we're not making any recommendation in terms of what that term should be. We just think it should be commercially reasonable length, and we believe that the rationale for that is that a reasonable duration and renewal expectancy provide incentives for a registry operator to make the investment necessary not only to operate the it would in a stable and secure manner, but -- initially, but on an ongoing basis. Recommendation 16: Registries must apply existing and new consensus policies. A couple of the issues that were dealt with here, were talked about, concern was discussed regarding special situations where a gTLD serves a specific and well-defined community for which they believe a specific consensus policy may not readily apply. An example there may be in the historical context some of the sponsored TLDs that were serving a very specific community. There could be need to negotiate an exception, but it would be an exception to this recommendation. ICANN will maintain and enforce the requirements to adhere to consensus policies. Recommendation 17: A clear compliance and sanctions process which could lead to contract termination must be set out in the base contract. And that's an area that staff is working on. Recommendation 18: If an applicant offers an IDN service, then ICANN's IDN guidelines must be followed. Following the IDN guidelines, we believe, will support the diversity, security and stability of the domain name system. Existing gTLD operators already have this requirement, and ICANN staff and others are working to ensure that IDN gTLDs are introduced in a timely manner, and that the activities of the ccNSO related to the introduction of IDN ccTLDs and activities in organizations such as the IETF with regard to IDNA standards are coordinated as needed. Just to cite one example there, the GNSO met with the GAC yesterday, the joint participant with the ccNSO, with regard to IDN TLDs for ccTLDs, and had a very, I think, productive session there, and that kind of coordination is going to be very important. And of course the IETF has a process that many of you are aware of going on with the IDNA protocol. Recommendation 19: Registries must use only ICANN accredited registrars. Issues that came up in this: Should smaller registries be able to start a registrar if existing registrars are uninterested in serving their gTLD? Another issue: ICANN's current registry agreements require the use of ICANN-accredited registrars, and registries are prohibited from being ICANN-accredited registrars even for their own gTLDs. And then third: Regions where there are no, or few, ICANN-accredited registrars may be at a disadvantage for this particular recommendation. Some discussions are continuing on this topic. In particular, involving registries and registrars, and I -- it's impossible to predict right now whether that will result in any things coming back with regard to this recommendation, but I just want to point that out. Implementation guidelines I: An applicant granted an it would string must use it within a fixed time frame which will be specified in the application process. That's the one I referred to in the last session. J: The base contract should balance market certainty and flexibility to accommodate a rapidly changing marketplace. K: ICANN should take a consistent approach to the establishment of registry fees. And L: The use of personal data must be limited to the purpose for which it is collected. Now I'll turn it over to Kurt for some implementation comments. >>KURT PRITZ: I think the big picture here is that the council has provided a lot of the reasoning behind their recommendations for certain contract provisions. Chuck, can I have the remote, please? >>CHUCK GOMES: Oh, sure. >>KURT PRITZ: Thanks. And so this is a fairly forward -- not repetition, but reaffirmation of the council direction in this regard, and the direction that the base contracts that are posted will take. So the base contracts that are posted in the standard form of agreement -- so in the case of new TLDs, we're looking toward moving to a standard agreement that most, if not all, registries would sign. And in order to create that agreement, we would certainly look to the current sponsor and registry agreements. The registry agreements were rewritten just in the last three years, and streamlined some -- considerably, and so we would look to that as a source for much of the language. And then of course there's the policy recommendations from this new gTLD policy consideration that's just finishing up, and also there's been a policy effort for -- to discuss new registry contract terms, or all registry contract terms that is also going to go before the board. We'd also learned to incorporate registry -- the registry failover plan, the findings of that study, and in particular, registry best practices. So in order to ensure ongoing operations and to ensure the best protections for registrants possible, either through an ongoing operation or some sort of procedure, in the case of a failure, we would incorporate certain best practices into the document. And then of course, you know, to follow -- that's supposed to say "RFC" not "RFP." Wrong version. And other technical requirements. So in very straightforward fashion, then -- and this is almost a repetition of what you just heard -- the base contract will be of a commercially reasonable term. Registry contracts have been running from seven to ten years, so I think that's a starting point, and a renewal presumption absent being in breach of the agreement, not following consensus policies, repeated breaches that are cured. Exactly the form of the presumption isn't determined, but certainly existing agreements might be a guide. Consensus policies would be incorporated by reference into the agreement, as well as a requirement -- you know, RFCs would also be incorporated by reference. Those that apply. There would be specific auditing capability -- the ability for ICANN to audit compliance with the agreement, and then penalties or sanctions enumerated in the agreement in order to enforce the -- enforce the compliance. There would be a requirement to follow IDN guidelines, and also other IDN technical requirements, in the case of a non-ASCII it would. And then finally on this slide is the requirement to use accredited registrars. Now, there's one other issue I'd like to put a stickpin in that's not on that slide, but we also discussed the reserved names document, the reserved names working group working product, and specifically the recommendation that geographical names are not reserved. I think for discussion later will be whether country -- country names are reserved or not, or whether country names are part of the objection process for this. So I think it's a good discussion for the multiple constituency groups' supporting organizations and advisory committees later on. So there are some issues associated with the base contracts detail, but one I just mentioned. Second, we -- just to restate the position we'd like this to be a standard agreement that are followed by all applicants. We don't want to stifle innovation, so to the extent that a form contract may prevent some improvement to the DNS or a new product, we want to avoid that. But certainly a fixed agreement would facilitate processing. Many of you are familiar with the effort and time required to negotiate and then approve new agreements, and a standard agreement is a way around that. And I -- to restate, so the base contract will try to balance, you know, fixed terms with permitting innovation, so that amendment to the agreement is not needed in order to enable innovation. And then again, the council has directed us to take a consistent approach with respect to fees, and so we'll look for that consistency across all the agreements, while again trying to encourage some business models. So, for example, in the -- in a recent case, GNR had a proposal to sell names at the third level in bulk, but ICANN fees would essentially prevent them from pursuing their market model because the ICANN fees would be many multiples of their per-name price, so we worked with that name to find a way to lower ICANN fees in bulk sales in the third level, so we want to take a consistent approach to fees, but one that encourages new businesses and new models. So Chris, I think that's the end of my comments on this section. >>CHRIS DISSPAIN: Thank you, Kurt. Do any of the other panelists want to make any comments at this stage before we take questions? We're going to take questions in a minute if anybody has any comments or questions. Please grab the mic -- line up at the microphone. Anyone else? Are you coming to the microphone? Thank you. >>ELLEN RONY: Hello. My name is Ellen Rony and I wasn't fast enough on my feet to ask this question at the last session, so I hope you'll permit me to do so now. I work in the education industry and often when there is a paper that a student has to produce, a rubric is designed and numbers are assigned to the various criteria in the rubric, and there's been some mention about providing an objective criteria for this process and I appreciate the thought that has obviously gone into giving this process structure. So do you intend to have such -- some sort of numerical assignment to the criteria, so that any applicant that meets the criteria is accepted, or have you proposed a threshold of only so many will be introduced? Have you given that thought? >>CHUCK GOMES: The intent is -- and the recommendation is -- that if anyone recommends the -- satisfies the requirements, they would be approved. >>ELLEN RONY: Okay. My second question -- and this, I -- forgive me if I -- if you mentioned this and I missed it. It almost seems so obvious I shouldn't ask, except that I remember the process from November of 2000. Have you included any language that would require any board member that has any affiliation with any of the applicants to recuse himself or herself from the consideration process? >>VINT CERF: If I could respond to that. I think that this would fall into the conflict of interest criteria that we apply to all board members, so if there were an issue of that kind -- I don't know that they need special language for that purpose in the gTLD. If there is a conflict of interest and if a board member reports that, the conflict of interest mechanism, in the normal course of board business, would exclude that board member. >>ELLEN RONY: Okay. Thank you. >>CHRIS DISSPAIN: Thank you. Go right ahead. >>NAOMASA MARUYAMA: Hello. My name is Maruyama from JP. I want to talk about the -- one condition about the mandatory use of the registrar -- registrars by the registries. And I want to express my opinion about this. I am fully in favor of this proposal. Probably everyone thinks that this condition is very important in the aspect of the fair competition, but I want to give another aspect for this clause. That is the -- related to the explosion of the root zone. To think of the -- if there's not this kind of a limitation, then one thing I fear is that the -- some major company sister top-level domain for itself -- for example, the dot IBM for the IBM company for itself, so let me call this kind of usage the proprietary use of the top-level domain. So if the proprietary use of the top-level domain occurs, then other major company also wants to have that kind of top-level domain. To look at the current proposal, the mandatory use of the registrar by the registry prohibits this kind of proprietary use of the top-level domain. In that aspect, I think it's particularly important to have this kind of condition for the registries. So actually, this condition will prohibit the proprietary use of the top-level domain, but probably to think of this aspect, this clause -- this proposal should be a little bit strengthened because the -- like this: The registry must use ICANN accredited registrars, and the registry cannot refuse any ICANN accredited registrars when the registrar wants to be -- to have a contract with the registry. Thank you. >>CHRIS DISSPAIN: Does anybody want to comment on that? Chuck? >>CHUCK GOMES: Just a quick comment. Actually, what you suggested there is the intent, and I -- in fact, I think, John, you were the one that helped us get the more complete language to address it that way. Is that correct? >>JON NEVETT: Yeah, that is definitely the intent, that a registry can't prohibit a registrar from selling names. One clarification to something you said, at least from my perspective. I'm not so sure that recommendation 19 would have the impact that you're suggesting with regard to a proprietary use string that you suggested. For example, dot -- IBM could register or apply for a string for dot IBM, and then make it only for its employees, for example, but those names would have to be sold through ICANN-accredited registrars for the accountability reasons that we've talked about during the process and I'm sure we'll address shortly. >>NAOMASA MARUYAMA: So I mean that if the registry -- registration is open to all registrars, then everyone can apply, not only the IBM company employees? >>JON NEVETT: Right. Well, the string -- I'm sorry. The string could be just like dot KRO now is restricted or dot -- some of the country code TLDs are restricted on certain objective criteria. Certainly a company could apply and ask for certain criteria to be included in the string -- for example, IBM could say only IBM employees are eligible for the string. And that could be part of the application process. I'm not saying, you know, how this group would treat that, but that could be an outcome, so my only point is that the requirement of the use of registrars would not preclude, in my opinion, the proprietary use of a certain string necessarily. >>NAOMASA MARUYAMA: Well, I think the -- if the registration is open to the -- all registrars, then the -- everyone can apply, not only the employees are limited for the registration. Anyone can apply through the -- any registrar for that top-level domain. That will prohibit the proprietary use of the top-level domain. >>CHRIS DISSPAIN: Coming from Adrian Kinderis. >>ADRIAN KINDERIS: My name is Adrian Kinderis. I'm the registrar constituency rep to the GNSO. I think on this it's fair to say that the business plan, if IBM were to do this, that IBM would only do their registrations through a sole registrar. You can open up for many registrars, that's fine, but it's up to IBM to choose who they want to choose. To do their registrations. So the model still works. Are you still opening up for all registrars. It's just up to you to choose which registrar you do it through. >>CHUCK GOMES: I don't think that's totally accurate. I think that any registrar that wants to participate under existing practice would be allowed to participate. >>ADRIAN KINDERIS: Isn't any registrant allowed to choose which registrar they want to sister their names under. >>CHUCK GOMES: Sure. >>ADRIAN KINDERIS: So and if the registrant in this case is IBM -- >>JON NEVETT: That's right. The registrant could choose who they want to register the domain name through. >>ADRIAN KINDERIS: That's what I'm saying. >>JON NEVETT: The registry cannot change an exclusive is registrar as to sell the domain names through. >>ADRIAN KINDERIS: But if the -- in order to pick up the proprietary point of this is that the registry is the registrant, because IBM, who happens to be running their registry -- right? -- chooses to register names for their -- >>CHRIS DISSPAIN: No, no, that's not correct. Let me try and see if I can understand it as a non-GNSO person, all right? >>ADRIAN KINDERIS: Sure. >>CHRIS DISSPAIN: The whole point about this is to open up competition with the registrars. What the point that's being made here is that that has the effect of meaning that you -- a proprietary it would cannot be restricted to having names registered in its only two employees of a company. And that's not correct. It can have that restriction. I'm right, aren't I? >>JON NEVETT: Right. >>CHRIS DISSPAIN: So all of the registrars have to have the opportunity to offer the names. >>ADRIAN KINDERIS: Yes. And -- >>CHRIS DISSPAIN: And -- but there's no limitation -- but the registrants can be limited to a particular group. >>ADRIAN KINDERIS: Yes. And those registrants can choose -- if all of those registrants chose to choose one registrar. >>CHRIS DISSPAIN: That's fine. >>ADRIAN KINDERIS: That's what I'm saying. The model still holds is what I'm saying. >>CHRIS DISSPAIN: Yeah. That's right, right? >>CHUCK GOMES: Yes. The -- are you clear, Adrian, on that? I think -- [Speaker is off microphone] >>CHUCK GOMES: Yeah, I think so. I think it's just terminology is what we're doing here. It's important to recognize -- so this requirement would mean that the IBM employees would have to register their name through an ICANN accredited registrar, and any registrar that wanted to participate in that particular market would be eligible to do so. >>CHRIS DISSPAIN: Yeah. Okay. Next question. Speak slowly. >>BHAVIN TURAKIA: I'm Bhavin Turakia and my question -- the earlier question that I was asking in session 1 was relatively similar to what -- the discussion we just had. I actually want to use the same example in a tangent of that. For instance, a company like IBM, as was mentioned, could choose to apply for an it would solely for its employees and I'm happy to hear the clarification that that's possible. As long as they use registrars for registrations of names. Second scenario is that IBM could potentially decide that it wants to register dot IBM only for itself and have its homepage hosted on home.IBM and, you know, it's job portal hosted on jobs.IBM and doesn't really want to give out any registrations and that, you know, does not bring in an element of a registrar at all. I'm trying to figure out where the scenario fits in. I actually have -- and that's what I was referring to when I spoke about -- >>CHRIS DISSPAIN: Can we do one thing at a time, so can we deal with that one first? >>BHAVIN TURAKIA: Right. No. Let me just complete. A third scenario is where a Web hosting company decides that they want to apply for an it would. I'm not going to say dot Web. There's already been sufficient controversy there. But -- and give out a domain name free with every hosting package that they sell, or to every customer that they have. They're not really selling a domain name. So my question here is: One, with respect to the requirement of there having to be a registrar to make those registrations, what happens when those domain names are given out free to either employees or to customers? Is there a need to be a registrar involved and has there been any consideration about that? Two is with respect to usage, where there's a norm that says that an it would has to be used by the company that applied for it, if IBM chose to use it only for itself, you know, to -- only for its own Web site, would that be quantifiable use. And the third element that arises from this set of examples is consistency with respect to, you know, registry fees from ICANN's perspective. If -- if an applicant decided to, you know, come up with an it would that they only wanted to use for self-consumption. >>CHRIS DISSPAIN: Okay, got it. >>CHUCK GOMES: With regard to the free domain names, I believe this requirement would still require the use of ICANN-accredited registrars. I'm not sure how motivated ICANN-accredited registrars would be to support that but the registrars, I suppose, could still mark it up. >>JON NEVETT: There is certainly a model for that. And dot info, for example, had a free promotion for quite some time. >>BHAVIN TURAKIA: I am not talking about a promotion. IBM wants to give domains to its employee, it will be free for lifetime. >>JON NEVETT: Let me just finish. My point is essentially whether it is free or there is a cost is irrelevant. If you look at the recommendation, it says it is the process of registering the names. So the registration process for a customer to come in and register the name, it's got to go through an ICANN-accredited registrar. The point of that is accountability. The point of that is essentially registrars sign a registrar-accreditation agreement with ICANN. There are certain protections in that agreement. There are a number of requirements in that agreement. So it is important for the process, for the registrant community, for the registration community essentially to follow those procedures for competition reasons, for accountability reasons. And if you look at what we're doing right now in another forum, we're looking at changes to the RAA or the registrar accreditation agreement. We're looking for more requirements on registrars. We're looking for more enforcement and more tools for ICANN to enforce the RAA. So essentially, we're looking for more regulation and we need to have the registrars under those contracts. So whether it's -- they're given away for free, all they have to do is sign a registrar accreditation agreement and then we'll be bound -- or they'll be bound by the WHOIS requirements, the data retention requirements, the requirements for certain topics in the registration agreements with their customers. So that's essentially the purpose of the RAA and the purpose of the requirement to use registrars. >>CHUCK GOMES: With regard to the usage requirement, as far as I can recall -- and anyone can correct me if my memory is bad -- but I don't think we said they had to use it in any particular way. So I would see no problem with them using it in the hypothetical situation that you suggested. And that would be fairly easy to document and show that they're using it. The intent there was to not just have people cybersquat on TLDs and sit on them, not using them for something is, I believe, the intent of the committee in the recommendation. >>CHRIS DISSPAIN: Okay, thank you. Next question, please. >>MATTHEW HOOKER: I'm Matt Hooker. I'm up here at the mic with a different question and represent a different entity. This time I represent lowestpricedomain.com. We are reseller of registrar services, and the problem is we're getting hit with massive amounts of chargebacks due to credit card fraud. And guy can steal credit card data somewhere in Vietnam or wherever. I mean no slight to Vietnam, but that has been a particular problem to us. Register, sign up as a customer or reseller under our program, register a number of domain names. We don't find out that the card is an unauthorized usage and that was stolen for 30 or 60 days, but, yet, the agreement that ICANN has made with the registries doesn't allow them to revoke the registration and give us our money back. So the registry doesn't -- it would be very simple for the registry to revoke the registration, give us our money back, you know, due to credit card fraud. But the registry won't do that. So the registrars and the resellers for the registrars are left holding worthless domain names. They're almost always worthless and a chargeback. So that's something -- I would like to know, has that been addressed and do you think you might be able to do anything about that? >>CHRIS DISSPAIN: This is a registrar issue. It is not an issue for new gTLDs as far as I am aware. >>AVRI DORIA: It's not -- >>MATTHEW HOOKER: Item J? >>AVRI DORIA: It is not specific to new gTLDs. If this issue exists -- and I'm not assuming it does -- it exists now and it would be a general issue, you know, across the board that we might need to deal with or might be dealt with, but it certainly isn't a specific issue to new gTLDs that is somehow different from all that we dealt with. >>MATTHEW HOOKER: I think it falls under Item J. It certainly looks like it does, but it would also apply to current agreements. And I would ask you to consider this because it doesn't seem fair, and it could be changed to make it a better way, a more fairer way. Thank you. >>CHRIS DISSPAIN: Thank you. Next? >>JORDYN BUCHANAN: Hello. I'm still Jordyn Buchanan, and I'm still only speaking for myself. So I want to go back to Recommendation 19. It may be that there is a secret recommendation or one that I just didn't read, but is there actually a specific recommendation requiring that there's ongoing equal access provisions to all registrars? Or is that just assumed to be the current policy and, therefore, it persists? Or is there a specific recommendation to that effect? >>JON NEVETT: Within 19, it says the registries can't discriminate against registrars. So, essentially, there's that requirement in there. As well as in the current registry agreements, there are certain requirements for equivalent treatment or at least equitable treatment, I should say. >>AVRI DORIA: In reading the full text as opposed to the shorten text, "Registries must use only ICANN-accredited registrars in registering domain names and may not discriminate among such accredited registrars." The full text includes the non-discrimination. >>JORDYN BUCHANAN: Once again, I think -- I don't want to hold this process up. The fullness of time will reveal whether this is a correct observation or not. But it seems to me as we get closer and closer to achieving the goal of registry competition that this notion of artificially imposing some level of registrar competition becomes more and more obsolete. So what I'm suggesting is in the future, I think this requirement that -- I think the requirement to require registrations be done through registrars makes perfect sense. We want to make sure that the place where the registrant interacts with someone that has all the ICANN accreditation and all the rules that flow down through that registration. But I don't think it necessarily will make sense in the long run to require that every registry deal the exact same way with all of the registrars. Especially -- I mean, the first issue here raises one of the obvious points, right, which is there is a very difficult bootstrapping process for new registries, especially smaller registries, to get sufficient number of registrars or any registrars sufficiently interested in their product to have to, you know, treat them all equally. Being able to offer some strong incentives and things that businesses traditionally do in order to encourage people adopting their product, seems like it would be really helpful and often those would have to be tailored on an individual basis. So I think that -- and if there's actual competition between registries, that means a registrar could say, "Oh, well, you don't want to offer me a good deal? Fine, I will take a hike and I will go over to another registry and make a deal with them" and, you know, we would solve this problem through competition as opposed to ICANN regulation which seems like it would be very helpful. Once again, I think this can probably be worked out over time, but I would certainly encourage a literal interpretation of what it would mean to not discriminate in the meantime. >>CHRIS DISSPAIN: Comments, anyone? >>JON NEVETT: Jordyn raises one point I want to address. We're working right now as Chuck mentioned to address the situation of a small registry that is not getting sufficient registrar interest and that issue is being handled and dealt with and discussed and hopefully we'll achieve some consensus on that to give them a helping hand. >>CHUCK GOMES: Just for process point of view, if we're able to have some success there, we could, of course, bring it back to the council. Assuming council is supportive of it, as long as something like that was agreed to before the base contract is finalized, that kind of exception or whatever it might be, could still be implemented in this process. >>CHRIS DISSPAIN: Okay. Next question? >> ROBERT HALL: My name is Robert Hall, and I should clarify what the standard disclaimer that my comments are for my company Momentous Group, although I am the vice chair of the registrar constituency. I think Jon has been doing a great job of holding up that end. I want to see if I can shed some light on a couple different aspects we're talking about here. >>CHRIS DISSPAIN: Slow down. >> ROBERT HALL: Slow down, I know. He even warned me, and he's heard of me and I've met the man. I think what Adrian said is correct. I think what we're mixing up perhaps is that there can be registrant restrictions in a new TLD application, not registrar restrictions. So the IBM example for all their staff, I would assume IBM would be happy or allowed to say in their application "We intend this only for our staff. Our HR department will actually be the registrant" because as someone else mentioned it isn't really for the life of the employee it's probably for life of the employee with IBM. So if the HR department of IBM is the only person that can be a registrant, they are free to pick our registrar if they want, although there could be many other registrars. They just won't get any business. If that helps, perhaps, clarify of how we may end with a TLD that has a single registrant or, in fact, such a narrow use of who can use it, that that, in fact, is what occurs, as we end up with a very small group. I don't want to use dot museum because they are similar but they have different issues. Chuck, I see an expression. >>CHUCK GOMES: Rob, I need some clarification because you said if IBM is the only registrant. I don't understand what you're saying that because a registrant would be at the second level. >> ROBERT HALL: If IBM said we're applying for the new top-level domain dot IBM and we are restricting it to use for our employees and the only person that can apply for a domain is our HR department on behalf of the employees so they, in fact, become the registrant because IBM wants to control these domains, they, in fact, would have produced a situation where there is only one possible registrant in a TLD. We could use any company. You could use Microsoft. What they have done is by placing registrant restrictions, not registrar restrictions, they have essentially said, look, there is only one entity that can register names in this. Similar to what Dot Post is doing. We used to see a lot of this in the sponsored TLDs. But in the new round, we've lost that sponsored versus generic terminology. I'm assuming a new TLD could still come forward and say, This is a very narrow and niche product and in essence we will only have one registrant and they are going to pick which registrar they want to deal with. That could end up there. Every other registrar would be free as far as I know to apply. The other interesting thing that we seem to keep coming back to and Jon alluded to it, the dot museum problem. We keep asking ourselves, will there be enough registrars that take interest in the domain name. I think it's important to remember that so far every single TLD has multiple registrars that are willing to sell it. But we're not the ones often that have to market it. So there are TLDs, and I'm assuming in the new round there will be TLDs that will not be marketable, that no one will want and that the -- it is incumbent on the TLD to go out, in fact, market it and make it usable to the registrant. Com, Chuck's domain -- I can't call it Chuck's domain. [ Laughter ] >>CHUCK GOMES: I'm okay with that if I can benefit. >> ROBERT HALL: So Chuck's domain, you know, is the dominant one because of the marketing and because of the presence that's gone on over the years, not so much by the registrars but by the registry itself before registrars even existed. So it is important to keep in mind, I think, and not lead these TLDs down the path that registrars are going to solve all their problems and if they just had the interest of some registrars, they're going to sell a lot of their TLD. I think dot museum is a classic example of that. They have a fair number of registrars interested in it. They can't sell their product for whatever reason to the end user community. We're going to have that. We're going to have to deal with failures of new TLDs. But I don't think it is fair to say that it is the lack of registrars interested in the TLD that will cause it not to be perfect. Thank you. >>CHRIS DISSPAIN: Thanks, Rob. Any comments from anyone? Okay. Next question? >>MICHAEL PALAGE: Thanks. Michael Palage. Just to try to give what -- hopefully some clarification on this issue regarding choice of registrars. The Appendix S has provided sponsor registrars to select the registrars that they want to enter into contractual relationships. That registry is then required to provide quality among those registrars. This is different from the unsponsored or -- unsponsored TLDs where there is a requirement that they make that service available to all registrars. So I think that is part of the confusion we've heard here and the reason being this new gTLD process has not recognized that distinction between sponsored and unsponsored. It is just new TLDs. ICANN may choose in the baseline contract to provide some flexibility for the applicant to do that. We don't know. There is talk about well-established, well-defined communities. We don't know how that will evolve. But I think that's part of what I have heard, and someone who has followed Recommendation 19 as Avri can tell you, I have probably been articulated this particular point for much of the last 18 months because I see this as potentially problematic. I've accepted the fact it is in the recommendation, will go forward and hopefully after there is an evaluation, after the first round, we may be able to come back and look at this and learn from the applications that we have seen as well as the ongoing experience with regard to dot museum and some of the other smaller oriented TLDs. I just wanted to provide some of those contractual distinctions. >>CHRIS DISSPAIN: Thank you. Okay. Chris, are there any online questions? >> CHRIS AUL: No. >>CHRIS DISSPAIN: Okay, thank you. What we're going to do if that's finished -- okay, good. We're going to take another break because we don't want to break Session 3, so we don't want to start Session 3 and break Session 3. So we are going to take a 15-minute break and only a 15-minute break. All right, quarter past 4:00 back in the room for starting Session 3.