ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

An expression of interest to operate a new gTLD registry

July 5, 2000

This document may be made public and may be used to assist the formulation of appropriate policies concerning the consideration of formal applications.

We are eNom, Inc. a subsidiary of Web Vision, Inc. and supporters. Our contact person is Paul Stahura and he can be reached at stahura@enom.com. It is very likely that we will be submitting a formal application.

We have listed some, of what we believe to be, significant points concerning our interest in operating a registry. These points may be helpful in determining policies for submitting prospective registry proposals. They are in no particular order and have been numbered so that people can more easily refer to them.

1. Registrar and registry. As an accredited registrar who may be selected to operate a registry, we will probably be proposing that we will a) either not, as a registrar, sponsor names in the TLD we operate or b) we will divest of our registrar business.

2. Allow contribution of registrar experience. We believe that accredited registrars have valuable technical, operational and business experience in this market that they can bring to bear to benefit the Internet community and should not be off-handedly excluded from operating a registry. The industry experience they bring outweighs the competition problem (a registry competing with its registrar customers via its own registrar) because this competition problem can be solved.

3. Are two "firsts" fair? But also, we believe that the "first mover" advantage is especially significant to an organization in this industry and that on balance, it would be anti-competitive for ICANN to grant a registry to one of the five initial, "test-bed" registrars, or to NSI, without an extraordinarily innovative and outstanding registry proposal, because those organizations already received an advantage of "a first" in this industry. Giving one (or more) of them another first would not be fair to the many other qualified candidates that will likely submit competitive proposals to operate a registry.

4. On the sponsored/open issue: We will not be proposing a "sponsored" TLD, but it will not be "open" either. There is no need for a sponsoring agency, group or entity because there is no specific group (such as banks, airlines, unions, bowlers, people named "smith", etc.) that our proposed TLD benefits because the operation of the TLD serves the global Internet community at large, much like com net and org do.

5. Registry with no IP problems: Our proposed registry will not be quite "open", because it will have restrictions on it that will reduce the amount of trademark/intellectual property problems and disputes to near zero, yet do so without any effort on the part of registrants, registrars or trademark holders to verify a registrant's credentials or to inspect the SLD string.

6. No confusion, yet competition: The TLD string we will be proposing will be differentiated from the current gTLDs (com net and org) and therefore it will likely not cause confusion with another gTLD string, but yet will provide significant competition to other gTLDs because we feel it will garner a significant number of daily registrations that would have otherwise gone to another TLD.

7. Don't roll out another .com first: If people could only buy food from just one guy, and that guy is required to sell beef (lets say he has a government concession on selling beef, so that he is the only one ably supply food, and it must be beef) then he would have a monopoly, which would be a bad thing, because people would starve if they did not buy beef from him. But then, if you want to introduce competition and other foods slowly, would it be wise to next introduce another competitor who can only sell ever-so-slightly different beef, or, one who could only sell potatoes? By letting the potato guy into the food market next, you not only provide competition to beef (people will not starve if they do not buy beef), but also introduce other benefits as well (a more nutritious and balanced diet for example). Only later, after say introducing apples, chicken, cheese, ice cream, grits, salad, sushi, lobster, gummy-bears, and beer, would it be wise to introduce more beef producers, to provide competition in the beef part of the food market. It would never be wise to introduce spinach, by the way.

8. Our TLD string. Why don't we disclose the string and more details of the registry's purpose and structure? We are torn, because on the one hand, we think we have a tremendously beneficial (to Internet users) registry idea, business model, and TLD string combination, and we have taken a risk in developing the concept in private over more than two years and therefore we should be entitled to a small part of its benefits, if any, and that if we disclose the TLD string and the rest, others will take our idea and suddenly propose the same thing. But on the other hand, if we do not now disclose the string and the details of the registry, ICANN may only receive our proposal when some entity out there may have a better plan or implementation or better funded business, and can use this TLD string and our ideas to deliver even more benefits to the Internet than we could have.

9. Registries should suggest their own TLD string. If ICANN decides that ICANN will specify the possible new gTLDs and then after which have prospective registries submit proposals to operate one of them, then ICANN should make a public request for suggestions of the gTLD strings beforehand, in order to know what they are. But if it did that, then, it should request other information besides the string such as the purpose of the TLD string, and the structure of the registry, and what, and why, etc, so that it could better evaluate the strings to include in its list. In effect, it would mean requesting the entire proposal. That is why ICANN should solicit proposals that contain the string: because to not do so, would necessitate it to do so anyway. Also, by letting the string be included in the proposal, ICANN may get a more diverse set of proposals than it would have otherwise, because it is likely not every submitter will be targeting their proposal for one of TLDs that would have been chosen before hand. Therefore, we favor that prospective registries include the TLD string, or maybe more than one, with their proposal. We do not believe that the prospective registries "own" the TLD, even if it does propose it.

10. Let prospective registries give alternatives as well. We could, if required, propose one alternative to our TLD string of choice.

11. No restrictions on TLD strings. Since we are not disclosing the string now, we obviously favor no restrictions on the types of TLD labels, and even 2-letter strings should be allowed. Some ccTLDs are being used as gTLDs anyway, so the confusion, if any, would not be any greater than it is now.

12. UDRP We subscribe to the UDRP

13. Shared registry model. We will be proposing a shared registry system model using the accredited registrars much like the model in use for .com, .net, and, .org., but with a few differences, notably we will likely be proposing a "fat" registry.

14. Use the RRP. We will probably be proposing the use of the NSI/IETF RRP because the accredited registrars are already familiar with it, it is in real production, and the accredited registrars have already built their interfaces using this protocol. A registry implementation will be more efficient if we do not re-invent the wheel.

15. Construction of RRP backend. We may shop-out that portion of the registry function (we contemplate a registry that will provide more services to registrars, registrants, and the public than the current gTLD registry provides, therefore the current gTLD registry functions will be only a component of our registry functionality) to the lowest bidder (NSI, CORE, ETSI, Melbourne IT, whoever), or we may build that part of the back-end ourselves.

16. Fat registry. Since our registry will have a "fat" registry model, the RRP will need to be enhanced (with backward compatibility to be maintained) to handle sending of whois information to the registry, suggesting IETF and possibly IAB input. We contemplate that other parts of our registry will benefit from IETF input over time.

17. We maintain no IP rights. We will be proposing that we will maintain no intellectual property rights to the whois information, or for that matter to the TLD string itself.

18. Orderly "day one" There is no question to us that there is pent-up demand for SLDs under new TLDs. Pent-up demand will be instantiated in either a mob on "day one" or in multiple queues. We prefer queues. Our registry structure, we believe, will severely limit domain name speculators and trademark hostage takers, but in any case, during the start-up phase, we envision using a round-robin fairness model, whereby during each "round", each accredited registrar gets an equal chance, no matter how slow their internet connection is, to register a name, much like a draft. Alternatively, although it probably would not be possible to keep the TLD a secret, ICANN may just not announce the TLD string until the system is ready to "go live" on day-one, in an attempt to limit "pre-registration" queues, but we do not favor this approach.

19. Trademark exclusion list. We do not have a problem with a global exclusion trademark list, though we suspect it may not be practical to develop such a list.

20. Possible rollback. The registry we will be proposing has an inherent property of additionally providing another orderly (besides round-robin, and a global exclusion list) and potentially reversible (at least initially with limited consequences) method of registering names in the initial phase of the TLD's introduction.

21. Registry support model. The registry model we will be proposing necessitates the registry providing additional services beyond what the only existing example of a gTLD registry provides. One business model we are contemplating would be similar to NSI-the-registry where the registrars will pay a fee for the services of the registry. The fee will be determined via negotiations with ICANN and the registrar constituency. We also have an alternate registry support model in mind.

22. Business qualifications. eNom, is a wholly owned subsidiary of WebVision Inc., an internet infrastructure company that has raised more than $62 million in the past 12 months ($45 million in the last 3 months) from Freeman Spogli & Co., The Goldman Sachs Group, TL Ventures, SCP Private Equity Partners and others. This capital will be used for aggressive Internet infrastructure build out purposes, including an enhanced shared registry and world-class DNS infrastructure components (if we are selected to operate a registry). The company currently has 200 employees and a proven track record of building, deploying and managing top-end systems. We proven our Internet business leadership and expertise with customers including Toshiba, Visa, Seagate, and many others. We of course, built our own registration system (unlike an number of other accredited registrars, who purchase theirs), including a reseller interface whereby eNom acts as a value-added pseudo-registry (like CORE, Tucows and others) for its resellers. The company has locations in five cities in the US.

23. Our data center and networking partners Most of our partnerships are with leading and proven players in the industry, such as Sun, EMC, Oracle, Microsoft, IBM, ADIC, Cisco, Lucent, Arrowpoint, Cacheflow, F5, UniSys, Peregrine, Compaq, Legato, BEA Systems, Desktalk and a few others. For example, with EMC as our partner for the storage devices, we are offering storage on demand and remote storage facilities for redundancy and business continuity needs. Our storage area network spans multiple data centers so our customer in any one location can backup and access data from any other geographically distant location. We've got a relationship with Cisco for their expertise in routers and switches for IP routing, ATM and MPLS (Multi-Protocol Label Switching) pieces of our infrastructure and platform. We work very closely with F5, Cacheflow and Arrowpoint for their caching and load balancing products. Another partnership we have is with a company called "InterNap". With this partnership we basically "compress" the Internet by shortening the number of hop's to the destination servers.

24. Our Internet infrastructure. Two 26,000 sq ft data centers (each with space for about 500 racks), one in Research Triangle Park North Carolina, the other in Los Angeles and three other geographically dispersed points-of-presence data centers (Chicago, Seattle, Phoenix), with 3 more 20-30,000 sq ft data centers in the works.

a) Both ATM and IP Network Infrastructure Our network and interconnected Internet Data Centers (IDC's) together are a multi-service next-generation intelligent network and hosting infrastructure using Internet protocol (TCP/IP), ATM (Asynchronous Transfer Mode) and Gigabit Ethernet technology.
b) Bandwidth The network can offer capacity as high as OC-48 (2.5 Gbps).
c) Power The Internet Data Centers' electrical system is fed from three separate and diverse power source grids.
d) Security The Internet Data Centers' facilities are security protected by the building security system and guards: internal card key access, security video surveillance and recording systems, and armed security guards.
e) Fire Protection The fire and smoke detection systems include 3 separate Halon systems, one for the main data center area, one for the UPS and one for the battery room. Smoke detection includes under floor, above floor and above ceiling smoke detectors. A Pre-Action sprinkler system backs up the Halon systems.
f) Seismic Stabilization The entire facilities are 24 inch raised floor with seismic stabilization throughout.

All names are trademarks or registered trademarks of their respective owners.