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.
