Evolving gTLD Environment Workshop.
 Thursday, 14 February 2008.
 ICANN Meeting.
 New Delhi, India.
 
 >>KURT PRITZ: We're going to start in just one minute.  Thank you, everybody.  We're loading up slides.
 Welcome, everybody.  I'm Kurt Pritz from ICANN.  This workshop is about the evolving gTLD marketplace, and I'm fortunate to have with us here today a few of our associates in the ICANN community that are going to help describe past, current, and, most importantly, the future of significant aspects of the DNS.  In alphabetical order, there's Karen Lentz from ICANN.  She's the manager of business content and research.  Ram Mohan, the CTO and vice president of Afilias.  Paul Stahura, the chief strategic officer of Demand Media and also the founder of eNOM.  And finally, Bruce Tonkin, who is an ICANN board member, former chairman of the GNSO during the period where the policy recommendations for new gTLDs were developed and also is with Melbourne I.T., a gTLD, an ICANN accredited registrar, to my appreciation to you guys for joining us.
 So this workshop is not about the new gTLD application, the fee you have to pay in order to obtain a new gTLD and the technical bars you have to meet in order to obtain one.
 More, it's to take -- because we always find ourselves ordering in on the details of how we're going to do that process and what the timetable is.  But this is more of an attempt to step back, especially since we're in the Asian region here, and sort of look at the DNS, and especially the gTLD space and the DNS, from sort of a gestalt perspective.
 This namespace has been very vibrant and a lot of change has been introduced into it.  A lot of competition and choice for consumers.  At the top level, though, we've had 21 gTLDs.  That number has slowly grown over time.  There's, I think, 249 ccTLDs.  Once every few months, there's a new ccTLD delegated.  In that, but we're on the cusp of seeing some dramatic change -- "evolution" is probably too weak and "revolution" is probably too strong -- in the top level.  
 We're embarking on a process to implement new top-level domains, new generic top-level domains into the root zone and a process for that, and as a subset and a superset to that are the introduction of IDNs, Internationalized Domain Names.  They will necessarily be part of the new gTLD process.
 In parallel with that, we're developing policies for introducing what I'll call -- although it's still a policy discussion and decisions are to be made -- ccIDN TLDs.  The policy discussions are focused around the fast track, so that conceivably, these new TLDs could be introduced in the very near future.
 So all that change brings with it a variety of challenge.  Certainly there's challenge to ICANN, but challenge to all of us as we manage this ecosystem, the DNS ecosystem going forward and also brings a ton of opportunity, and that's why there's so much interest every time we talk about the introduction of new TLDs and the parameters surrounding that.
 So this discussion is meant to provide a brief history of the DNS and especially the gTLD space and the structure there, and then where we see that going with the introduction of new gTLDs and IDNs, and to the extent we can in the workshop, focus on the regional aspects of that.  The regional challenges, the regional opportunities of how that -- those innovations would change the marketplace locally and through Asia.
 So the order of battle here is that Karen is going to describe for us sort of the structure of the gTLD space, and then Paul -- is Paul next?  Yeah?
 Paul is going to dive into that a little bit and talk about how that structure sets us up and the new gTLD process sets us up for change.
 Bruce will discuss the policy development process itself and some of the goals of that, and what the opportunities coming out of that will be.
 And then finally, Ram will apply some regional perspective to that.
 To the extent possible, we want it to be iterative and interactive, so if anybody has a question at any time, I encourage you to stand up.  Otherwise, we'll -- we won't pause for questions, but we'll just take questions at the end.  But that's not -- that's certainly not asking you to wait to the end.  If you have a question that is pertinent to the discussion being had, I really encourage you to stand up then.  I think that would be great.
 So unless there's any questions now, I'm going to ask Karen to start our discussion.
 >>KAREN LENTZ: Can everybody hear me?
 Okay.  Thank you and welcome, everybody.  My name is Karen Lentz.  I will be -- I'm from ICANN staff.  I will be covering today some pretty basic information about the gTLD space and how it works, the registry-registrar model that's applied there, and then a little bit of background and history as to how that came about, and finally, a little bit about the contractual relationships that are in place between all the parties that are involved here.
 I think we have a couple of slides.  The next one was the agenda.  Right.  The objectives that Kurt covered.
 Next one was the agenda, which Kurt also discussed.
 So next should be me.  Yes.  Okay.  Next slide, please.
 Okay.  So I think most people here probably already know this, but gTLD stands for "generic top-level domain."  It's generic in the sense that it is open for registration on a global basis, so you have all of the country code TLDs, which are delegated to a particular country or territory.
 In the generic space, there's really no geographical factors applied.  They're intended to be generic in the sense that they're completely global.
 gTLDs that are under contract with ICANN operate on a registry-registrar model, and that means for each gTLD domain name that's registered -- say, for example, ICANN.org -- there are at least those two parties involved.  There's the registry and the registrar.  And they both have a defined role that they play.
 Next slide.
 So the registry maintains the -- it's to find another hard for the registry besides "registry."
 It is a literal registry of all the names that have been registered under that top-level domain and so they maintain all of the records of names that have been registered, and they're responsible for all of the technical operations at the top level.
 The registries typically interact with the registrars directly.  They for the most part don't have a lot to do with -- or a lot of direct interaction with the customer or the end user or the registrant, the person who's actually going out and buying a domain name.
 Currently, we have -- ICANN has 16 gTLD registries under contract.
 Next slide.
 Then the registrar.  Registrars are those who do the actual processing of the registration transactions.  They sell -- typically, you know, there's a charge for it.  They sell domain names to the party that's registering that.  Whether it's a company or a group or an individual.
 In order to register -- be able to register names in gTLDs, a registrar needs to be accredited by ICANN, and currently ICANN has over 900 registrars that are accredited to be able to sell names in the gTLD space.
 All of those 900 and some are accessing the same registries through the same type of system.  That's called the shared registration system.  "Shared" because all of the registrars are sharing it.  It's also called the SRS.
 And once a registrar is accredited, they go through some operational testing and they then are enabled to be able to access the registry and perform transactions, whether that's adding a new name or performing some sort of maintenance on names that are already registered.
 So they could be changing an address, changing a nameserver, performing a transfer, any of the transactions that need to be done, they do through the SRS.
 And finally, registrars are able to decide which TLDs they want to offer to their customers.  If I'm a registrar, I may want to focus just on one TLD or a particular type of TLD, or I may want to offer a whole range.  So that choice is up to them.
 Next slide.
 Now, how this SRS came about is fairly closely tied to the formation of ICANN and the history of ICANN in November of 1998.  
 Prior to this time, the registry and registrar functions that I described were both performed by the same entity.  That was a company called Network Solutions.
 ICANN was identified in November 1998 as the entity to oversee the transition to competition in domain name registration services, and one of the responsibilities that ICANN was given was to develop an accreditation procedure for registrars, and procedures that subject registrars to consistent requirements designed to promote a stable and robustly competitive DNS.
 So there was interest in opening up the space to other participants and of course there was interest in maintaining the continuing stability of the network.
 Next slide.
 So how this -- the next step in doing that was the statement of registrar accreditation policy, which was adopted by the ICANN board in 1999.  There was community involvement in doing that.  There were some draft guidelines and public comments.
 And the board at that time resolved to implement a program for registrar accreditation for the dot com, dot net and dot org top-level domains, consistent with that statement of registrar accreditation policy.  And I've put the link to where that policy is at the bottom.
 Next slide.
 So throughout 1999, ICANN accepted applications from entities that were seeking to participate as one of five test bed registrars for the SRS, and since that time, we have many more than five.  We've continued to accept applications for registrar accreditation and as I mentioned, we have now over 900.
 There have been some positive results to this development, particularly the price of domain registrations in gTLDs has decreased and the amount of choice and diversity of services available has increased.
 Next slide.
 So the registrar accreditation process today, we accept applications for accreditation on a rolling basis.  There's no limit to how many companies or entities could become accredited registrars.  And there's no deadline or fixed time period when that -- you know, applications can be submitted at any time.
 And the link at the bottom is where the information can be found on how to become accredited.
 Next slide.
 Finally, this is a diagram of the contractual relationships that are in place between all of the parties that I've been talking about.  They have -- I see the arrows are a little bit hard to see there, but a lot of the agreements that are up there have names that sound very similar to one another, so the diagram is supposed to make it a little bit clearer.  ICANN is on the left, and we have a registry agreement with the registry on the top there, and we have the registrar accreditation agreement or RAA with the registrar on the bottom.  And then in the middle, the vertical line is the registry-registrar agreement between those two parties.  Those agreements, all three of those agreements are posted -- publicly available, posted on our Web site.
 And then on the bottom right-hand corner, you'll see the registrant, and that's being, again, the person who is actually registering the domain name.  They have a registration agreement with their registrar, so you can see they don't have any direct contractual relationship with ICANN or with the registry.  The registrar is typically their main point of contact for managing their domain name registration.
 Next slide.
 Finally, I'm going to close.  These are the 16 gTLDs that we have under contract now, and as I've been talking about the growth of -- in the number of registrars from zero to five to 900, we are also kind of looking ahead to what happens when this number starts to multiply by potentially a large factor, and some of the next speakers are going to be discussing what the impact of that will be.  Thank you.
 >>PAUL STAHURA: I guess I'm next.  They asked me to do some slides on the gTLD marketplace, and to cover these topics.
 Next slide.
 These are -- I mean, you could write a book on some of these topics.  Hopefully I could, you know, squeeze all this in.
 But if anybody has any questions about what I'm talking about, you can save them till the end or you could just come up to the microphone or shout them out or whatever and just ask me.
 So I'm going to talk about the evolution of the registrar marketplace.  You know, why there were a few registrars in the past but now there's a lot more.  I'm going to talk about -- and Karen touched on this a little bit, but I'm going to dive a little bit deeper into the registrar-registry and the reseller relationships.  You know, not just the contracts, but other relationships.  I'm going to talk a little bit about competition.
 There's still open subjects around, you know, gTLDs, new gTLDs, such as -- well, I'll get into that, but there's open subjects and I'll cover some of those.
 I'm going to talk about the future of the model.  You know, we have ICANN accredited registrars, we have registries.  Should they be -- should they be gone?  Should -- you know, what should the new model be?  Should it be the same?
 And my opinion is what -- I'm going to talk a little bit of what I think might happen in the future.
 So don't bash ICANN.  These are my opinions.
 So there were a few registrars.  Now there's many registrars.  And so here's some reasons to get accredited.
 If you -- you know, to address a specific market, you know, like you might have registrars being accredited in geographical areas -- Africa or, you know, where there's no registrars now, various places like that -- and you might have registrars that are addressing a specific vertical market, like they might be selling names to real estate agents, for example.
 Another reason to get accredited is, you know, you're providing some other service like hosting or e-mail and, you know, many of these services need a domain name to function, so you might become accredited so that you don't have to, you know, resell names from a registrar or get the names somewhere else.  But you might get accredited for that.
 Another reason is more recent, but there's a perceived -- there's a perception that if you get -- if you're a domainer, let's say, and you have a large portfolio of names, for more security you might put your names in your own ICANN accredited registrar, to keep them more secure.  Because maybe you don't trust, you know, one of the current ICANN accredited registrars.
 Another reason is there are resellers out there, which I'll get to, and maybe you're -- you were a small reseller, now you're a big reseller, so you've become accredited, so you don't have a middleman anymore.  Go direct to the registry and bypass your registrar that you're the reseller of.
 Another reason is access to data.  You know, I don't know why Google got accredited specifically, but they are accredited, and they don't offer -- they do offer domain name registrations but not through their own ICANN accreditation, so I'm guessing that, you know, maybe they got accredited to have access to data.
 Because using -- you know, the interface to the registry, you could get data on various names.
 And another big one, in my mind, why people get accredited, or companies get accredited, is to access domain names that might be becoming available, and we call that "the drop."  So names that are -- were registered in the past, but have expired and been deleted and are available again.  You might become accredited to access those names.
 Next slide.
 So here is typically the sales chain.
 So you could see how ICANN is not in the chain.  But at the top, we have the registries, and you can see from -- money flows from the bottom to the top, and names flow from the top to the bottom in this diagram.  So the registries sell names to registrars, and they can only sell names to ICANN-accredited registrars, and then registrars either sell names directly to the registrants or indirectly through a reseller.
 Some of this is pretty basic.
 But here's the difference between the sales chain -- and I want to -- you know, the reason I have these two slides is sometimes it gets confuse -- people are confused between the sales chain, how that's set up, and the contract chain.
 You could see in the contract chain that ICANN is in the chain, and the reseller is not.  So -- and Karen touched on this chain a little bit, and I don't want to repeat what she said, but basically the registrants have, you know, contracts with the registrar.  The registrar has a contract with ICANN.  The registry has a contract with ICANN.  And the registry also has a contract with the registrar.
 A slide on competition.  I'm here to tell you that competition amongst registrars is fierce.  It's brass-knuckle competition.
 And transfers are the basis for the competition.  If we didn't have transfers, then, you know, eNOM, my company, could lock in the registrants and they -- and, you know, there wouldn't be any competition because those registrants would be locked to us.  But with transfers, for example, one of the eNOM registrants could transfer to, say, Melbourne I.T. and if -- you know, if Melbourne I.T. offers them a better price or better service or whatever.  And so if we don't have transfers, we don't have competition.
 And transfers is a reason, in my opinion, for requiring registries to use ICANN-accredited registrars exclusively.  Because without is this requirement, the registrants would be locked in and we wouldn't have competition.
 I'm not sure I explained that right.  Does that make sense?  Oh, I'm sorry.  You might need to go back one slide.
 Yeah.  That was the slide I was talking to.
 Now, sorry, go to the next slide.
 So one of the open issues is registry-regard ownership.  Can a registrar own a registry?  How much can they own?  Can a registry own a registrar?
 So this is an open issue.
 One thing is, right now any registry could sell names without being a registrar because they could be a reseller of a registrar.  You know, let's say NeuStar, one of the registries, wanted to sell dot biz names.  They could, you know, contract to eNOM or, again, Melbourne I.T. or play us off against each other to get the best price, and of course because there's brass-knuckle competition, you know, they would get a very cheap price from one of us, and so they could sell names without being registered -- without being a registrar.  They could -- they don't need to be accredited.  They don't need to be owned by a registrar and a registrar -- you need to own them for them to sell names.
 So there is -- the economic incentive is for the registry to sell names.
 So there's really no reason for a registry to sell names and undercut themselves, because the other registrars would sell the same names at full price.
 So there's no reason for a registry to, you know -- like, for example, for VeriSign -- in my opinion, for VeriSign to sell names for $4 a name directly to consumers because they have us registrars paying 6 bucks a name.
 And one last point is there's an issue about being -- if a registry owned a registrar or was the same entity, it would be difficult for -- remember back to the contracts page.  There's a contract between the registry and the registrar.
 So if it was the same entity, it would be difficult for them to contract with each other because they are the same -- can't have a contract with yourself.
 So there's also a solution to that issue, which is two entities with the same owner.
 They asked me to do a slide on the future, and it's not easy to predict the future.
 But essentially what I am saying here is, whether the registry/registrar model stays the same or we have a different model, it's an open issue.  It's up to the community.
 My guess is regarding the registrar requirement, changing the registry/registrar model will probably not increase competition, because competition is already very high.
 Transfers work.  And the registry could be a reseller.  So the requirements for gTLD registries to use an ICANN registrar, in my opinion, will stay as it is.
 And regarding the registry/registrar ownership issue in the future, the economics and the incentives are the same either way.
 One second, Chuck.  Come on up to the microphone.
 So I don't think there will be a prohibition regarding common ownership.
 Go ahead.
 >>CHUCK GOMES:   Just an opinion question.  I never thought about the registry using a reseller.  Are there problems with that?  Is that a policy issue or is that okay?
 I don't have an opinion because I haven't really thought it through but I was just curious.
 >>PAUL STAHURA:   I don't have a problem with it.
 So I think this is my last slide.  What's expected to change?  It's another prediction.  I'm not sure, but there's going to be an increased number of registries.  I'm pretty sure on that.  Not positive.
 There's going to be more registrars, and there's going to be more registrants, because I think with the introduction of new gTLDs, the names will be distributed to more people in the world.
 I think there's going to be more competition at both the registry level and the registrar level, but also, I think between registries and registrars.  I think that competition will increase.
 I think the registry/registrar model, I think it's good and I don't think it will be changed.
 And for sure, it's going to be interesting.  I know that.
 Thank you very much.
 >>LORD BRAR:  You know, I may actually sound like a broken record --
 >>PAUL STAHURA:   You might say your name so they know who it is.
 >>LORD BRAR:  Lord Brar.  I have spoken this point like about three times in the last three days, but I really need to insist again and again because I see this coming up so much.
 You know, it's like there are a lot of registrants who, like me, make it next to impossible actually transfer the name easily.  As a registrant, I would probably have to send them my verification stuff.  You know, they would make me call in, they would make me send their documents, they would make me send their passport.  So something has to be done to make it easier, make it more uniform.
 >>PAUL STAHURA:   Correct.  I know there has been a lot of talk in the past couple of days about that.  It's tricky issue because, on the one hand, it's the basis for competition, and we don't want to mess that up.  We have to increase competition.  But on the other side, we have security.  So we don't want transfers to happen fraudulently.
 So it's a tricky balance between those two.
 >>LORD BRAR:  That's true, but let's just take the example of (saying name) because that's from eNOM.
 As a drop service, you probably have your regulated so many registrars, and all of a sudden when a name is gone, it may go some really exotic registrar that nobody has ever heard of and they make their money from something like 100 clients.
 So for them, having that domain being transferred out is something like a big deal.
 So really, I'm not sure what ICANN can do about it, but something has to be done to make it more uniform.
 I'm sure security is an issue, but that's an issued for Go Daddy also, that's an issue for probably eNOM also.  And you supply your EPP code just via Web interface.  And the other people, like Go Daddy, it is supplied by e-mail.
 >>PAUL STAHURA:   That's another benefit of competition, is there is a variety of models, there's choice.
 >>TONY HARRIS: .
 Yes, I would just like to make a point.
 I'm sorry, yes, my name is Tony Harris.
 I was just interested in some aspects of this presentation, insofar as I will soon hopefully be a new gTLD applicant for regional gTLD.
 And in looking over what lies ahead for us, at least, I seem to recall having seen statistics of domain name capture by the registrars, and the majority of the market, if memory severs me, is in the hands of maybe 10 or 12.
 >>PAUL STAHURA:   Are you talking about --
 >>TONY HARRIS:   I know you have better details, but correct me, if you would.
 >>PAUL STAHURA:   Oh, I get it, I get it.
 >>TONY HARRIS:   But I think the major -- the largest percent of the market is in the hands of maybe 10 or 12 registrars.
 >>PAUL STAHURA:   I think maybe -- this is another guess, but something like 80% of the names are held by 10 registrars.
 >>TONY HARRIS:   Fine.
 >>PAUL STAHURA:   Something like that.
 >>TONY HARRIS:   Thanks for refining that.  That was my point.
 The only thing that concerns me is, with new applicants coming up who will need the sales chain for the domain names, obviously, is there is no obligation for a registrar to take on any TLD.  You have the option to say "i am not interested.  I don't want to handle this."
 But the applicant does not have any option.  I mean, he can only go to you guys and say, "Will you sell my name?"
 I'm not complaining about this.  My only doubt is, doesn't this put you in a position of great power?
 >>PAUL STAHURA:   You mean the registrars?
 >>TONY HARRIS:   The registrars, yes.
 >>PAUL STAHURA:   Well, maybe the registry could own its own registrar, like I suggested.  Or one of my bullet points was registries and registrars ownership, maybe they have common ownership.  So there's two companies, both owned by the same other company, and the registry and the registrar, you have a registrar and a registry.
 >>TONY HARRIS:   You're right.  We can have a captive registrar, you are saying.  Somebody who would handle our TLD?
 >>PAUL STAHURA:   Right, as long as it's open to other registrars.
 >>TONY HARRIS:   Okay.
 But then --
 >>PAUL STAHURA:   Effectively, you could --
 >>TONY HARRIS:   I don't know if you answered my question with that.  Yes, we do have that option, but I think you might recognize that you are in a position of power.
 You have a lot of new customers coming up, and they will want your services.
 And even if one could start up a new registrar, you have a hell of an advantage.  You have got, like, 40, 50 million customers out there.
 >>PAUL STAHURA:   Right, that it took me ten years to build.
 >>TONY HARRIS:   Whatever.  It's just a comment, it's not a complaint; okay?
 >>KURT PRITZ:   Tony, so I think one of the issues for introducing new TLDs is a registrar model that fosters small registries as well as large ones, too, since registries will be obligated to use ICANN-accredited registrars.  There needs to be a mechanism where the small registries are somehow incubated so they can grow.
 We'll take Amadeu's question and then we will go on to Bruce's talk.
 >>AMADEU ABRIL i ABRIL:   Okay.  Regarding this question of ownership and the role of each one, let's remind why we have registrars.  We have registrars not because we need that.  We need the function.  But the function could be performed by the registry.
 We decided long ago, because of experience, that the worst form of integration is vertical integration.  That's more dangerous than even horizontal integration in a market.
 So, you know, even having VeriSign as the only registry, in tradition, the registrars really introduced competition in the market.  Here, the logic is, therefore, that each one performs a different role, and all of them perform a neutral role of making sure that they have a legally privileged or artificially privileged access to the source to benefit the users competing among themselves.
 The system has been, I would say, changed.  I would prefer saying corrupted, but just changed, in the way that those having approved access to the source are doing that for their own benefit, and not the benefit of the distribution channel.  That is, for running and warehousing to handle the names that do not belong to their customers anymore without leaving that to the pool, et cetera, et cetera, et cetera.
 It's a change.  And a change in the sense that they are using that privileged access.
 Now, what we are hearing here is that we couldn't get rid of the separation between registries and registrars.
 I would warn against that because, I repeat, experience in all those markets, not only domain names, show that vertical integration is the worst possible solution.  And when you are the customer of a given TLD, when you own a domain and you do that not for, let's say, speculative purposes but to use that as your address, the traditional use that still exists, you are quite lucky therein.
 And you need a competitive registrar market to work.
 Second question.  If you allow registries to be registrars and registrars to be registries, you will have parties that are having the complete control of one part of the source, the registry, are competing, in theory, with other parties at the next level.
 We all know that this competition won't work.  And all those others will walk away or be completely marginal or be at least at the expenses of the registry in that situation.
 That's very different of a registry reselling through the channel.  Because at least there, it can use its sales force, but it cannot use the specially, artificially privileged access to the source to compete against its own customers.
 I am against, also, about allowing registries to resell names through resellers, but it's very different from being the registrar itself.  If that's the model, let's get rid of the registrar accreditation, because it's a barrier more than a help.
 >>PAUL STAHURA:   I had an answer but I forgot what it was now.
 But like I said, these are open questions.  And, you know, hopefully the community will decide.
 >>KURT PRITZ:   Bruce.
 >>BRUCE TONKIN:   I guess the intent of this session was partly to help people that weren't as close to the ICANN model as others to get a bit of a feel.
 So if I can just get a feel from the audience, how many people in here is this their very first ICANN meeting?  Put your hand up if it is your first ICANN meeting.
 (hands raised).
 >>BRUCE TONKIN:   So three, four people, five, six.
 It's about six people in this room, their first ICANN meeting.
 How many people in this room have been at more than ten ICANN meetings?
 (hands raised).
 >>BRUCE TONKIN:   So, yeah, that's an interesting statistic.
 So those that have been here for more than ten ICANN meetings are looking for some competitive edge in this presentation (laughing) that they haven't been able to get in the other presentations.
 But I am going to direct my comments more to, I guess, the six that are in this room and provide a bit of background.
 The evolution of the new gTLD environment, the first point is that new gTLDs have been introduced since 2000.  So we have actually been continually introducing new gTLDs.  And in 2000, it was an experiment, and we were trying to say what the effect would be on the market by introducing new gTLDs.  And I think generally, it's considered that experiment was successful in that there are new gTLDs, there are new uses of domain names.
 And some people feel that new gTLDs must only be about people that are trying to run a business to make a profit.
 But in actual fact, a lot of those new gTLDs are nonprofit.  In that original round of 2000, we had new gTLDs around the museum community, dot museum, around cooperatives, dot coop, so that those are two that were clearly set up as nonprofit, particularly intended to support their community.
 After 2000, though, there was quite a few people that were unsuccessful in that particular round.  And in 2004, we had really an extension of that initial round to try and help some of the ones that came more from a sponsored community background to get a TLD as well.
 And so the most notable ones there that have come up have been dot travel, dot mobi, and currently dot Asia is in the process of launching and it's quite a long process.
 Again, I think even dot Asia is set up as a nonprofit.
 So that just sort of gives you a bit of a feel.  There's already quite a bit of diversity.  We have TLDs ranging from clearly for-profits, new ones like dot biz, similar to dot com, clearly aimed at -- run by for-profit companies.  We also have new gTLDs that are set up for particular communities, like the travel community or the museum community.
 And we also have new TLDs that are set up for geographic regions, like dot Asia, and for, I guess, language and cultural communities like dot cat for Catalan.
 So that has all happened since 2000.
 So what the GNSO did was to try and take the lessons learned from introducing these new gTLDs in the year 2000 and in the year 2004.  Some of those lessons were that the application process was unpredictable.  Some people were successful, some weren't.  And those that weren't successful weren't always clear as to why.
 But also, create a process that was protecting the user community from -- I guess what the GNSO or the ICANN community felt would be undesirable to add to the top level.  So we looked at things like making sure if we add a new TLD, it wouldn't be confusingly similar to an existing TLD, so as not to create confusion among the Internet user community.
 The other thing that's happened or the new development in terms of the domain name technical standards is we now have a standard for Internationalized Domain Names.  And that is partly being implemented at the second level, so you can get a domain name in a different script that can be represented on a computer.  That's available currently in several of the existing TLDs, things like dot com and others.
 But that's to the left of the dot.  And ICANN is also trying to say, well, can we introduce TLDs to the right of the dot, which would be a new gTLD, that would be able to support a different language script.
 So the new gTLD process was developed so that it would be neutral with respect to whether you wanted to introduce a TLD using the current ASCII-type labels or whether you wanted to introduce a TLD using the IDN-type labels.
 So if we just go to the next slide, and I have only got two.  So the second slide.
 So why are we doing this?  Well, really, it's part of an evolution that we started in 2000, as Karen said, to introduce more competition into the marketplace, add more consumer choice, so consumers could choose different TLDs depending on their needs.  Also create new organizations running these TLDs, so we have competition at the top level rather than one company operating all the TLDs.  We already have quite a few companies.  But we're certainly hoping to get more organizations, which don't have to be a for-profit business.  Can be nonprofit.  Can even be a country, or a government could choose to run a TLD if it wished.
 So that gives us service provider diversity, so some are for profit, some are not for profit, some could be governments, some could even be individuals.  It's possible an individual might choose to run their own top-level domain name.  And we heard Dennis Jennings this morning express an interest in his own top-level domain name.
 The process doesn't really stop any of those things.  So it is really aimed to create as much diversity as possible.
 So we are expecting to get new gTLD operators, but we will also get new registrars.  As Tony Harris was pointing out, there currently is about 900 registrars.  Now, in any market, you will find that a small number of those registrars account for a fair portion of the marketplace.
 But it's got what is called a long tail.  So there are a lot of quite specialized registrars that have much smaller volumes of domain names that are still very viable operations in their own right, and ICANN is continuing to get new applications all the time.  And one of the things that ICANN has been trying to do is encourage new registrars in different regions of the world and to help them in the process of becoming accredited.  And I think -- but we now have one from Africa.  Was that last year?  Yeah.
 So ICANN has really been trying to help people work through the process, the legal agreements, as Paul as pointed out, to help get them accredited.
 And as we roll out more gTLDs, we will get more registrars that will be in operation for particular areas.
 So really, the intent of this session was to say there's an existing environment.  If people want to get involved in the domain name area today, they can.  They can become accredited registrars.  They already have quite a few top-level domains they can choose from.  And no registrar is required to offer them all.  You can choose to offer just one or as many as you wish.
 But we're also creating opportunity for those that want to have their own top-level domain, and there's really no restrictions on the type of structure, whether it's organization, nonprofit, for profit.  And there's really no restriction on whether you choose to use the TLD for your language community, some geographic community, some hobby.  You know, you can have a dot chess, if you wanted to, if you were interested in playing chess.  Whatever.
 So really, that's the opportunity.
 So I'll leave it at that point and hand it over to Ram.
 >>KURT PRITZ:   Thank you, Bruce.
 >>RAM MOHAN: We'll just wait for a minute to get the slides up.
 Okay.  If you could just hit the space bar just once, or the next button just once.
 So I was asked to come and speak a little bit about new IDN TLDs, and some of the issues, with a particular focus on this region and some of the common elements that are here in this region.
 So I figured I'd begin -- next slide, please -- begin with just a very quick graphical look at some of the issues that folks in this region have.  If you look at just India, for example, keyboards which you've got up on top is an English keyboard, and if you go to some of the states in this country, they actually use a completely modified keyboard.  Now, many of you -- especially those of you who are multilingual -- are used to keyboards like that, but the -- if you actually look at the keyboard at the bottom, because the language has far more characters and alphabets than the normal QWERTY keyboard, there is overlap and there's really overload of some of the keys on the keyboard.
 It's not an unusual thing, but really that happens here also.
 On the next slide, what you'll see is one of the most-used applications in the region, instant messaging, and it's just starting to get accessible, not just in English but also in other local languages.  You've got, you know, Tamil and Hindi.  And Yahoo has actually got a very heavily used set of applications that are in Indic scripts and in Indian languages.
 So really, in India itself, in the next slide, what you will see is about 16 million Internet users, and that -- of that Internet population, pretty much all of them [inaudible] 98% or so, is just e-mail, you know.  And in 2005/'06 there was a saying about 25 million e-mail uses who had individually made accounts.  Free e-mail accounts are very popular.  And recent surveys showed about 50% of the entire populations of this Internet population, 30 million, instant message users in the region.  And across the board, about 18% prefer Hindi, for example, for reading.  And Hindi is a minority language.  There is -- I guess there is really no majority language in India.  Hindi is a minority language.  It has only about 5 million users.
 On the next slide, in the Asia region itself, there are approximately 350 million Internet users, rough estimate.
 It is the world's fastest growing Internet and mobile device marketplace.  In India itself, mobile devices are selling about 7 million devices a month.  7 million mobile phones and accounts get created a month, and if you look at rural India and you look at where -- how Internet is being accessed, it's not being accessed from a PC, from a -- you know, from a traditional device.  The Internet is being accessed directly on a mobile device.  That's where the Internet is going, and there is really a blurring between the, quote-unquote, mobile Internet and the Internet itself.  It's just the Internet, and that's accessible on a device in your hand.
 SMS is a major factor, especially in local languages communications.  A lot of it happens via SMS.  It's a big factor in all of Asia.  The last statistic I'd heard was over 2 billion SMS messages per day, just from within Asia.
 On the next slide, on the usage of gTLDs versus ccTLDs in the region, com is -- among the gTLDs, com is still pretty much the dominant force in the region.  If you go across the board to most of the nations in just this -- in the Asia region, in the south Asian region, com is the most used, most popular top-level domain.
 And now after com, there's kind of a pretty significant drop-off.  So if you look at net, org, info, mobi, et cetera Asia, coop, aero, a number of the other gTLDs, they barely register on the scale.  Net -- I think com is far and away, of the gTLD side, the most popular gTLD.  Now, that's not something new.  That's -- if you look at the total number, that's about similar to what happens elsewhere.
 Now, in terms of ccTLDs, however, one of the things that seems to be pretty clear here in the region is that the popularity in use and sales of the ccTLD seems to be directly linked to policy development, so the more -- as governments and ccTLD registries have liberalized their policies, there is a direct one-to-one mapping between liberalization and the growth of the ccTLDs themselves.
 In the Asian region, as a result of some of this liberalization, it has become the second largest ccTLD market worldwide, and it's poised -- if the current growth rates in the Asian marketplace of ccTLDs continue, it is poised to become the largest ccTLD marketplace in the entire world.
 The next slide, you know, one of the things that I was asked to cover was:  So, what's the experience in terms of Building IDN TLDs?  Because if you want to apply for an IDN TLD, especially that has relevance within this region, what do you have to do as a TLD operator or as a TLD applicant?  What are the kind of things that you have to do?
 So if you look at Indian IDNs itself, there are some special and complex issues.  Several of these have already been covered in earlier sessions so I'm not going to actually go through all of these things.
 But suffice it to say that if you -- if you provide an application for Indian -- Indic scripts, and if you actually pick -- you know, there are about 11 popular -- 11 basic scripts.  If you actually apply in even three or four of them, whatever you learn, you can actually apply across the world for any other IDN TLD application, because you have the, you know, left-to-right issues, you have bidirectional text, you have non-breaking joiners, lots of specific issues that are unique in IDNs application from -- within Indic scripts, actually, will end up being a reference case for IDN TLD applications most other places.
 On the next slide, that's just -- oh, and the laptop there doesn't actually display the second character.  But the second character -- so there's a block there on the Malayalam character.  That's actually intended and it's a pretty good expression of problems with IDNs, right?
 But the first one up there is a particular character and there is a character underneath that looks identical to the -- you know, to that Tamil character up there.  They look the same.  They're not the same, and in the DNS system, they're not exactly the same.
 So as a result, if you go to the next slide, variant tables will actually help.
 So what is a variant table?  All it is is a table that says here is collision.  Two different scripts -- or two different languages that implement a single script or multiple scripts.  And all a variant table does is it says if one looks the same as the other, if it looks similar -- right? -- here is a mapping and if a registrant comes and registers a domain name in the one block or reserve the other.  And this is important, you know, for many obvious reasons.  You know, you want to avoid confusion.  You want to avoid phishing, things like that.
 On the bottom there, on the horizontal strip there, you'll actually find a pair, right?  Something on the left and a pair, you know, right beside it.
 They all look more or less similar, but let me tell you, every single one of them has a different uni-code codepoint.  If you were to represent this in a -- you know, in a domain name or in a TLD label, they would be completely different, even though they look the same.  So one of the things, again, in terms of -- if you were to go and apply for an IDN TLD, you will need to accommodate and make sure that you have a vary -- you know, you consider what are the variants, and you either come up with a policy for what are you going to do about variants right at the top level, as well as all of the levels -- at least at the second level underneath it.
 Next slide are some of the issues that are common in the region.  It's pretty common here to consult with government for the geopolitical impacts of a top-level domain.  After all, if your local government is not going to be supporting you, then there is going to be a problem.  But that's pretty common in this region.
 A lot more tolerance, if you will, or acceptance of government involvement and, to some extent, some sort of a benevolent or expectation of some benevolence and involvement, which is somewhat different from other parts of the world.
 For pretty much many of the -- or all of the languages that are spoken in this region, there's an active local language community.  However, they're not necessarily active online and on the Internet, so if you -- in terms of actual outreach, it's a little hard to do, because you can't reach them through a traditional -- you know, just a discussion forum, et cetera.
 Having said that, yesterday there was a gentleman from Yahoo who was talking about a discussion -- a discussion board that Yahoo host here in India that just discusses poetry in a particular Indian language.  400 posts per day, right?
 So there's an active local language community.
 The ironic thing is that 400 posts per day are all about poetry in a particular Indian language and almost all of them are in English, the posts, because that's -- it's hard to type.
 Now, you know, there are concepts that inside of ICANN that are common -- commonly discussed.  You know, things that are confusingly similar.  And to the local language community, issues like that are confusingly similar.  They don't really understand what that means.
 There's also not a huge amount of understanding of differences between things, between representation, for example, in the DNS versus font rendering versus how it looks in an application.
 So often you will find a conversation where you'll have someone say, "Well, two words sound the same so they should be blocked.  They're confusingly similar."  Or, you know, "It looks the same because in a font it looks similar, one to the other; therefore, it should be blocked."  
 And from a DNS perspective, is it unique is what's more important, rather than, you know, is it a font that looks similar, one to the other.
 Next slide.
 There is actually quite a bit of interest in adherence to international standards, even if you go to economies that have implemented test beds here in this region.  You'll find -- in those economies, you will find folks from the government very clearly enunciating that they want to adhere to international standards.  They have a test bed implemented, for example, because they have a population that demands, you know, the IDN TLD.  And that's something you hear over and over from this region.
 And often, at least my observation is that often the government is a major factor in pushing technology development, linguistic development, forward.
 So in terms of launching and Building IDN TLDs in this region, often having the government not -- if you don't have the government involved or if you don't have quasi-government bodies that are focused on technology and language development, if you don't have them involved or endorsed, there's a pretty good chance that your TLD application is going to run into a problem.
 And there is a strong anathema to pornography, curse words, and it's this -- there's cultural pieces to it.  You know, even having normal, you know, domain names at the second level that have similar -- not even similarity.  That have suggestive words -- okay? -- you get into trouble here in this region far more than, you know, elsewhere in the world.
 So there is -- and I've seen cases where folks have called up and said, "This is indecent," and there is really no not necessarily a level-set of what is decent and indecent, but it seems like government -- often there are government folks who will end up saying, "This is indecent, this needs to be yanked, this needs to be taken offline right now."
 And the other observation that I had to make is that, you know, if you compare to, say, North America or other parts of Europe, there is a little bit more of an openness to being regulated, to having some level of input come through, and to actually listening far more to what -- you know, what the government or what some authority has to say.
 There is a little less of inclination, shall we say, to tilted windmills, as compared to other parts of the world.
 So last slide, what might change.
 And this is probably not just in this region, but I think the distinction between gTLDs and ccTLDs are blurring when it comes to the IDN area, and, you know, I've heard, for instance, some folks say that, you know, dot Chungwa -- China, if you will, in Chinese -- or Gongzu, which is -- many people say Gongzu is the equivalent of com in Chinese but I've spoken to folks in China, some of the folks who are actually running this -- what they call the test bed and they say it's not.  It's not com.  It's a different word.  It's a new TLD.  And when it comes time for application, you know, they wouldn't mind coming in and applying for it, and there's no problem with, you know, a gTLD or a ccTLD actually going and applying for something else.
 There also seems to be some level of mixed opinions regarding whether either an existing gTLD operator or an existing ccTLD operator should actually be the operator for an IDN TLD, and you'll notice that I didn't say "IDN ccTLD" because at least in this region, I'm seeing some level of mixture of opinions about, you know, whether a new IDN TLD is automatically an IDN ccTLD because there is not something like an international standard an ISO-3166 type of a list.
 So this last -- if you'd just go to the last slide, that's just questions and I thought this would be appropriate.  That's from a -- from a bangle shop in Hyderabad down in the south central of this country.  That's just an actual picture.  You've got, you know, a guy who is selling bangles.  It's a, you know, high-volume but relatively low-margin marketplace for him.  But you've got Urdu, Hindi, Arabic, and of course English right there, in his store.  That's pretty common here, and if you're looking to go and build IDN TLDs, then you'll have to -- you'll have to take into consideration, you know, true multilingual issues that are larger than a one-to-one mapping that, you know -- I've seen much more discussion of a one-to-one mapping.  There is much more than that, especially in this region.  Thanks.
 >>LORD BRAR: There's one point I would like to make which you said about like people objecting to obscene words or anything like that.  Well, let me make one thing very clear that even in gTLD, some of my domains get me complaints from people who are, you know, more conservative.  They would give me a call and then say, "Oh, why are you running this site?  Why do you have this domain?"  And I can actually show you those e-mails that happen.  And even in India, it sure happens.  So it's not -- you cannot say that it doesn't exist in the U.S., it doesn't exist out there.  It happens out there also.  And just like it's a free market out there, everybody's trying to push, in India also it happens like that.
 >>RAM MOHAN: You're exactly correct on that.  My comment was perhaps focused a little bit more on the pressures that come on registries or registrars rather than registrants, because you're right.  I mean, as a registrant you're going to get, you know, objections based on it, but at least my observation is that the level of sensitivity, you know, if it gets raised as a complaint into a registrar or a registry or to a government-oriented body, at least I sense a greater level of attention, if you will, to that than in, you know, registries elsewhere.
 >>ERIC BRUNNER-WILLIAMS: Hi, Ram.
 >>RAM MOHAN: Hi.
 >>ERIC BRUNNER-WILLIAMS: Eric Brunner-Williams from core.
 Ram, in the 2001/2002 time frame in the Chinese domain name consortium context, we were then grappling with not variations that looked alike but with variations that did not look like alike but which had identical meaning.  This is the simplified Chinese/traditional Chinese table debate issue or whatever.
 But the enduring thing that we have from there is the notion of equivalence classes across scripts on a per-character basis, and here we're not looking not so much per-character issues but string issues, we have the possibility of looking at that as a concatenation of equivalent characters or recognizing that if the -- even if the -- a set of characters are not character-by-character equivalent as they were in the SC/TC context, that the semantic -- the intended meaning of the string or the apparent meaning of the string, as in the four examples, Hindi, Urdu, Arabic and English, that these could define an equivalence class.
 With that concept in mind, knowing what we were trying to do in SC/TC -- that is, cause a registration for one label to be equivalent to the variants of that label so that the label effectively was a -- appeared in one namespace multiple times for each one of the variants, with all resolving to the same A record, and more interestingly, the two Chinese registries that were cooperating, or at least hypothetically cooperating, the TC -- the CN registry and the TW registry, doing cross-registration of the variants automatically, so that a registration of one variant in one registry automatically caused the A record to resolve in the other registry for either variant in the other registry.
 So we have the possibility of looking at equivalence classes, the experience that we have from the CDNC period, and looking at IDNs as a possible -- looking at equivalence classes as a way that we can say that these multiple strings actually result in a single zone file, or they result in multiple zone files.  Or the identical entries in a single unified zone file or identical entries in multiple discrete zone files.
 So this is a technique that we haven't really explored or talked about.  It's kind of been an assumption of some people who are somewhat business minded that each possible variant represents a new business opportunity for ICANN as a revenue collector, or for some business as a gTLD operator.
 And this isn't necessarily the case.  That's the point about equivalence classes, that we might be looking at proposals that involve folding much of this onto one zone or fewer than the maximum possible number of zones for the maximum possible number of scripts.
 Thank you.
 >>RAM MOHAN:   Thank you.
 >>KURT PRITZ:   Hey, Ram, I have a question for you and maybe Bruce, and I am looking for free advice, I think, since I have you here.
 >>RAM MOHAN:   What will you pay for it, then?
 >>KURT PRITZ:   So there's GNSO policy recommendations that say strings should not be violative of morality or public order.
 And you mentioned a collision.  There's a collision, essentially, between cultures where there is an anathema to pornography, perhaps, and an openness to regulation.  And then there is a more liberal culture that holds the opposite view.  So I wonder what your opinion might be of the least worst outcome in developing a set of standards by which we might judge TLDs by in this collision of cultures where we have to have essentially a worldwide set of standards.  Or can we possibly have regional standards for gTLDs?
 >>RAM MOHAN:   Do you want to take that, Bruce?
 [ Laughter ]
 >>RAM MOHAN:   Look, I think it's almost a fool's errand to try to resolve this clash of cultures.  I think ICANN would be well advised not to attempt to solve that problem.  I think you are better off asking for input from that, you know, regional community.
 So, for a for instance, if there was an IDN TLD application in Hindi, then I think it makes sense for ICANN to go to the regions that actually, you know, use that language and that have cultural sensitivity from it there, and open it up for comments and actually do some level of outreach.
 But my personal opinion, I think in this area, one size will not fit all.  And something that is even considered conservative for a given language one part of even a single country will be completely objectionable elsewhere.
 And I think it's a job that ICANN should try to hand off to somebody else.
 >>BRUCE TONKIN:   Yeah, it's the handing off to someone else that's the struggle.
 So I think, at least in terms of the way we envisage the process, and let's take English as the example, because English is spoken in a lot of different regions of the world, and those regions -- people in those regions probably have a different level of sensitivity just to the concepts that you mentioned around swear words and things like that.
 I think what the GNSO recommendations try to do is strike a balance.  And the first part of that was to say that the basic standard that would be used would be if it is acknowledged at an international level.
 And so there are a number of international treaties that have been signed by a selection of countries, presumably quite a few countries.  And some of those treaties cover things like racial discrimination and other things.
 And so the idea is that we would try and use these treaties to set the measuring point by which they are measured by.  But the concepts also need to be balanced against freedom of speech.  And that was also one of the key components.
 So I think as Ram says, you have to really consider it on a case-by-case basis.  And what we are really looking for is an appropriate dispute provider, essentially, which ultimately is a court, I guess, of some sort with people that have legal background that would be looking at both the international laws, taking into account the affected people.  So obviously if it was Hindi, that's the affected region so you would get input from that region.  And I don't know how widely spread Hindi is outside of India, but yeah, you would try to get input from that region, as you suggest, yeah.
 >>RAM MOHAN:   Yeah, I think -- you know, although my previous comment had a little bit of tongue in cheek, I think it's very important for ICANN to state clearly and unambiguously that you will take input and you will solicit input that is culturally and regionally sensitive; right?
 You know, you can't try to be politically correct, but I think it's important for people of that region to know that they can voice something and that it will be heard.
 You know, you may choose to not act on it, but at least it will be heard.
 Back to you.
 >>KURT PRITZ:   Thank you.  Did you have a question from away from here?
 >>KIEREN McCARTHY:   Talking about input, I have two questions from the chat room.  I wonder if this is a good time.
 I have one from (saying name).  I think they are looking at applying for a dot GAL, according to their Web site.  They have a big dot GAO on their logo.  We think it's important to maintain the projected time line implementation at the L.A. meeting and not delay the opening of the application process.  We are working on our application following this calendar, so therefore a delay might be a setback for us.  So question one, can ICANN provide any detail on any part of the future request or proposal that the applicants will need to submit?
 And question two, another important issue is the application fee.  Do you know how much this fee will be?  If not, could you provide a range for an approximate fee.
 And last, when will you publish the approximate date that the total amount will be?
 And I have another two questions from Vittorio Bertola who is in the chat room at the moment.  And he says, everyone wants to know --
 >>BRUCE TONKIN:   Why don't we stop with the first question first, Kieren.
 >>KIEREN McCARTHY:   I think they tie in.  It's basically questions about timing and when the process will be and when people will know what elements are there.  So I thought it would tie in.
 Vittorio says when will it be possible to submit applications and how much it will cost?  The more ICANN waits to have a public commitment on this, the more existing players will be favored over startups.
 And he suggests the board make a decision on this, on these two points, and publish it in the next month or so.
 And then he has a question about accredited registrars.  I will come back to that.
 >>KURT PRITZ:   So, well, we started with saying that this workshop is not necessarily about that.  But there have been presentations in other fora at this meeting that are posted that describe the time line for the conclusion of the GNSO policy recommendation implementation, and also identify issues on the critical path, the contingencies that require some degree of being solved before the implementation is launched.
 So to Vittorio and the other questioner, I would refer them to other meetings during this ICANN meeting that discuss that in detail.
 So that essentially it?
 >>KIEREN McCARTHY:   Well, I think the second part will probably fit into the same category, which is the accredited registrars.  And Vittorio has a suggestion, which is that the TLD should be exempted from having to use accredited registrars when they reach 100,000 registrations.  And he said they should be -- TLDs should be exempted until they reach 10,000.  So he is saying that the issues with accredited registrars come on with the number of that you get.
 >>KURT PRITZ:   Okay.  That's an ongoing proposal.
 I am going to ask Ram one more question and then we will wrap up.
 So I'm kind of ignorant.
 With regard to variant tables, I think Eric's question demonstrated that in certain regions they are very well developed.
 I am wondering if -- I'm assuming that the development of variant tables is a prerequisite to launching IDNs in languages where there are collisions, and how we develop authorities or how do we develop responsibility in some parties in order to have them develop?
 >>RAM MOHAN:   Yeah, I do believe that having the language tables followed by variant tables, that combination will be a gating factor.  And if you don't have one and the other -- not one or the other but one and the other -- then, you know, it's going to be very hard for ICANN to say -- or anybody who is evaluating to really say that this name isn't going to have collisions and there is not going to be some level of confusion in the marketplace.
 Now, to the second issue which has to do with how does ICANN know -- or who do you -- who can you get that can vouch for.  In the entire region, pretty much, as far as I know, at least -- I know of at least 30 or 40 countries in this region, every one of which has a language institute, has a language development body of some sort, and hassling WSIS who are quite skilled and talented in providing input into whether the variants and the language tables are appropriate.
 In the case of India, for example -- and I see Dr. Govind sitting there, quietly, in the back.  But he was directly responsible in the case of Tamil and Malayalam, for instance, engaging the right linguistic bodies to come together and say here are two tables.  Build me a collision table, a variant collision table.  But I think it is a getting factor.
 >>KURT PRITZ:   Eric, we are right up against the time but I welcome your comment so we will take it.
 >>ERIC BRUNNER-WILLIAMS:   Thank you.  Actually, it is a question for Ram.
 Ram, knowing that the experience of the CDNC was not entirely successful and the members of the Chinese language group, which was several -- it was many parties involved with the Chinese language from Beijing and -- from China, Taiwan, Hong Kong, Macao, and also because of the related Kanji script issues from Korea, Japan and Vietnam, but primarily the first two or three of those, they were not entirely successful in getting their proposal for a table mechanism or an intermediate table mechanism passed through the IETF process.
 So the question that Kurt gave you about who could construct tables, or basically solve the technical problem or define the technical problem, let alone solve it, that we face of language variants in the Indian subcontinent, to which of the two hypothetical sources of authority would you recommend ICANN turn to?  Would you recommend that ICANN turn to the Unicode technical consortium or would you recommend that ICANN turn to the institutions which you mentioned?
 Knowing that the UTC was the proximal cause of the collisions in --
 >>RAM MOHAN:   Yeah, --
 >>ERIC BRUNNER-WILLIAMS:   -- Chinese.
 >>RAM MOHAN:   -- I was just going to say that sometimes the UTC's encoding systems themselves, you know, they help cause -- at least in the Indian context, there is currently a significant debate that's going on between how some of the languages have been encoded versus how they should have been encoded.
 >>ERIC BRUNNER-WILLIAMS:   In North America that problem exists, too.
 >>RAM MOHAN:   Right.
 So I'm going to take your question and kind of pull at it a little bit.
 I think, actually, the time is ripe for the creation of -- and I have mentioned this a couple of years ago.  But I think that the time is ripe to have the creation of some sort of an RFC that will actually help build criteria that allow for ICANN and the evaluators to go and look at and say here are criteria, and, you know, you must adhere.  If you are an IDN TLD applicant, must adhere to these criteria.  And in there are guidelines, if you will, so those will not be "shoulds," those would be "Mays."  But there are guidelines that say in the case of evaluation of the validity of a string, you know, you must conform to the following RFCs and other principles.  And you should, you know, have some sort of -- I'm kind of building this up on the fly.
 But I think, actually, that what the community needs and what ICANN needs is some sort of best current practice or some sort of an RFC that it can refer to objectively and unambiguously in every single case.
 And I don't think this is an insurmountable problem.  I think you get the right parties together and I think we'll get a whop -- a BOF and then a working group going pretty rapidly.
 And then ICANN -- Kurt, for the evaluation issues, I think ICANN can then definitively refer to, does this application conform to the RFC.
 And the follow-on to that would be that in your contractual commitments, you could bind that party to say you shall conform to that RFC, and updates to it, like you do for EPP or other things.
 >>ERIC BRUNNER-WILLIAMS:   We have a working group of two, and the doors are open.
 >>RAM MOHAN:   Okay; great.
 >>KURT PRITZ:   Thank you very much, Ram.
 I would like to thank the presenters very much.  I hope you got out of this as much as I did.  I found it very instructive.
 And thanks for attending the workshop.
 [ Applause ]