Divorce.PRO for sale

please contact domainprofs  AT domainprofs.com

Generic top-level domains and the new dotbrand frontier

Paper from Interbrand
http://www.interbrand.com/Libraries/Articles/Interbrand_dotbrand.sflb.ashx

What’s in a
Domain?
Generic top-level domains and
the new dotbrand frontierInterbrand | Pg. 2
What’s in a Domain?
Generic top-level domains and
the new dotbrand frontier
A generic top-level domain (gTLD)
refers to the suffix at the end of an IP
address, the .com, .net, .edu, .org and
other standard extensions at the heart
of the online experience.
However, on June 20, 2011, the board
of ICANN, the Internet Corporation
for Assigned Names and Numbers,
voted that any word in any language
may now be considered for use as
a gTLD.
ICANN’s ruling marks a fundamental change
in how the Internet is structured. On one
hand, it opens the door for companies,
individuals, governments, and causes to own
a piece of the internet landscape, a place
where their brand reigns supreme. On the
other, the user experience isn’t the same
as 15 years ago, and the domain extension
doesn’t play the starring role it once did.
Since the 1990s, a company’s online address
has been of critical importance, but for most
new brands, the dotcom is often already
owned. Now, for a fee of US $185,000, ICANN
is allowing anyone and everyone to apply for
their own dotanythingtheywant..
So the question is whether the dotbrand era
is upon us?
The answer is, no one knows yet.
One thing, however, is certain: a domain
alone does not create a brand. So, before
committing to owning a hefty chunk of
internet real estate, brand owners have to ask
themselves, What business am I in? How are
my products or services organized? How will
a dotbrand URL enhance my
online experience?
ICANN is promising the next great chapter
in the history of the internet, and while the
prospect of owning a unique domain is an
exciting one, the process, the benefits, and
the pitfalls demand serious consideration.
In the following paper, Interbrand explores
whether this new frontier is really everything
it has claimed to be, and then, most critically,
discusses what considerations a company
should take into account from a brand
perspective, a digital strategy perspective,
and a legal/trademark perspective.
In short, buying a gTLD is a tricky endeavor,
and for many brands, it could be a costly
mistake. Those who are likely to see ROI are
the focused brand builders whose entire
existence is online, brands with robust
digital strategies that have a clear, solid
reason to lay claim to their own piece of
the Internet.
Ultimately, to decide whether or not a
dotbrand is right thing to do, the answer is
all in the brand strategy.
Brand Types and gTLD
Strategies: An overview
In the following chart, we outline a few
general brand types and discuss which could
benefit from a gTLD strategy and those that
might not.
by Paola Norambuena, Jeff Mancini, and Jerome McDonnellWhat’s in a Domain? Generic Top-Level Domains and the New Dotbrand Frontier Interbrand | Pg. 3
Brands that purchase large numbers of URLs every year could
benefit by linking each back to the masterbrand.
Corporate brands with large portfolios of successful/iconic
product brands should think twice before investing in gTLDs.
Purchasing domain names for each product could become
prohibitively expensive, while using the masterbrand as a
domain could cause confusion.
Brands that might benefit from a gTLD strategy
Brands that might NOT benefit from a gTLD strategy
Brands with complex or reorganized structures could use a
gTLD strategy to align its offerings in the marketplace.
Brands with a modest online presence do not need to make
the significant investment that a gTLD demands.
For example, merging companies could rely on a gTLD to
project a single, cohesive brand.
For example, small agencies with a primary website and
possibly two or three secondary sites have little need for a
unique domain. A standard domain is even an advantage as
it makes the brand easy to locate and eliminates the need
to maintain infrastructure. With the costs of applying for,
establishing and maintaining a gTLD estimated in the millions
of dollars, a brand’s present Internet strategy should already
equal this investment.
For example, eBay with its large constituency of online sellers
could provide each with a personalized URL ending with a
.ebay suffix. This system would economize online addresses
while adding stature to the host brand.
Brands already leasing Internet “real estate” to individuals and
businesses can benefit greatly by investing in a gTLD strategy.
Organizations interested in owning whole categories can
also leverage the new domain system to their advantage.
For example, by purchasing a category domain registry, such as
.music, a brand can make pieces of this online territory available
to others with related offerings or interests, becoming a top-ofmind category destination in the process.
For example, Microsoft may wish to pursue xbox.microsoft
to draw attention to their innovative consumer products.
Companies with a fragmented master brand could purchase a
gTLD for its subbrands in order to drive equity back to parent.
For example, a film studio releasing multiple features could
provide unique URLs for each property while unifying them at
the same time through the domain name.
For example, a company like Proctor & Gamble could find it
difficult to purchase the gTLD for every product in its portfolio.
Additionally, as most consumers do not have a relationship
with P&G, a .pandg domain would add little to the product
experience. What’s in a Domain? Generic Top-Level Domains and the New Dotbrand Frontier Interbrand | Pg. 4
Dotbrand versus dotcom
The Internet Corporation for Assigned
Names and Numbers (ICANN) quietly
wields a remarkable power over how
brands do business. Why? Because they are
the governing body in charge of top-level
domains—the coms, nets, orgs, and other
suffixes after the dot at the end of every
URL. With only 22 of these generic top-level
domains (gTLDs) currently available, it is not
an overstatement to say that ICANN is the
gatekeeper to the internet.
The .com gTLD is of course the most coveted
for searchability and general prestige. But
for a business to get the URL it wants,
it sometimes means wrestling it from
the web’s poachers and prospectors, at
considerable financial and logistical expense
Until now.
“Internet address names will be able to end
with almost any word in any language,
offering organizations around the world
the opportunity to market their brand,
products, community, or cause in new and
innovative ways,” as ICANN’s official press
release puts it. The expansion of the gTLD
system “will usher in a new Internet age,”
according to ICANN’s former Board Chair,
Peter Dengate Thrush.
The ICANN ruling has the potential to
unleash upon the marketplace innumerable
“dotbrands,” a domain extension that
replaces the standard “com” in a URL address
with a brand or company name . . . or
anything else an applicant may pursue.
For example, a company like Coca-Cola
could drop its current URL, cocacola.com,
and create a new address that is completed
with its name—for example, drink.cocacola.
What this means is that companies or
associations can now secure a URL address
that embeds the brand name even more
deeply into its composition.
Yesterday versus today
Fifteen years ago, at the beginning of the
world wide web phenomenon, there was
simply no precedent for what was happening.
While many companies rushed to stake out
territory in the form of domain names, others
adopted a wait-and-see approach under the
suspicion that the internet may be a fad or
a niche. The early adopters were rewarded
with prime internet real estate, but many of
the more cautious brands found themselves
up against cyber-squatters or businesses,
people, causes, and places with similar
names who had registered their URLs first .
At first glance, the ICANN ruling may
appear as if history will repeat itself, but the
circumstances are different this time around.
Perhaps most significantly is that in the mid-
1990s, no one knew anything about online
consumer behavior. Today, we know how
people navigate online and what they’re likely
to pay attention to in a URL.
Another big difference is that brand owners
can rest slightly easier knowing that,
unlike 15 years before, there are a number
of protections in place. These include an
objections-based process allowing trademark
owners to demonstrate how a proposed
gTLD would infringe on their legal rights,
and applicants must describe the rightsprotection mechanism they have in place
for second-level registrations. Additionally,
a trademark clearinghouse will provide
a centralized resource for storage and
authentication of trademark information.
Despite everything, brand owners will need
to remain vigilant once the application
process begins in January 2012, as they are
still responsible for policing their own marks.
Searching for answers
Many believe that Google, Bing, and other
top search engines will naturally award a
brand’s unique gTLD with a higher ranking,
that they will recognize dotbrands as the
official source of company information, and
therefore, position them at the top of search
results pages.
What has led others to doubt this
preference, however, is that Google has been
moving away from this practice in response
to spammers using brand names in their
domains to lure unsuspecting users to
their sites.
There hasn’t been any formal statement
on how search algorithms will be adjusted
to compensate for the new gTLD model.
Whatever the search engines’ approach, it
will have massive implications—not just for
businesses, but potentially for anyone with
an online presence.
In either case, one of the most important
factors in search ranking is the hyperlink.
Basically, the number of links to a website
from other sites or applications helps to
determine its place on the all-important
results page. This raises another key
question about how the search engines’ will
treat the new gTLDs: Will brands be erasing
years of inter-linking with other sites when
changing their domain identity?
Earlier in the year, Interbrand spoke with
Alexa, the global site ranking organization,
about the implications of the ICANN ruling.
Their feeling is that “creating a new domain
is like starting over,” whereas continuing to
build on a seasoned URL would leverage a
brand’s equity and rank.
For companies willing to undergo the effort
and the expense to implement a customized
domain registry, it will be critical to stay
aware of the search engines’ response to
ensure they don’t lose any equity in the
process. Assuming that the new domain is
accepted in the first place, simply switching
over in total at one time could be too
disruptive to a brand’s online eco-system,
and may require a period of transition or
a co-existence strategy, depending on the
circumstances. Of course, maintaining both
your current domains and a new gTLD will
mean additional layers of complexity and
expense that many brand owners may wish
to avoid.
One way or the other, there are a number
of variables at play in terms of the search
engines’ response, all of which will need to
“Creating a new
domain is like
starting over.”What’s in a Domain? Generic Top-Level Domains and the New Dotbrand Frontier Interbrand | Pg. 5
be carefully considered and solved for before
shifting to a dotbrand.
Old habits are hard to break
Over 15 years, Internet users have become
quite comfortable with the dotcom
construct—whether it’s a pure dotcom or
a country-code variation, like google.com.
au in Australia or google.de in Germany.
Dotcom is inextricably linked to how most
identify web addresses and shorthand for
doing pretty much anything online. And in
terms of strategic impact, the willingness of
users to give it up is perhaps the trickiest
to predict.
If this behavior has been at least a decade
in the making, how quickly will we see it
change? If there’s not a global transition—if
most brands don’t shift in the first wave—it
may be another decade or more before the
new domain construct is ingrained as a
behavior or as the default, as dotcom is now.
The majority of people still use search fields
to find a company, even if they have been
on the site before. And if it is a frequently
visited site, there is bookmarking or even
the dropdown history from the URL field
to get you there faster. Which means, on
the whole, that people are not committing
domain names to memory, but they can still
be thrown off when a construct goes against
the grain.
In the technology sector, there is precedent
for taking liberties with the traditional
domain structure, as seen in sites such as
instant.fm and instagr.am. Early adopters
may quickly embrace variations like these,
but for the average consumer, they can
be confusing.
In a recent example, when Yahoo took over
a popular bookmarking site that called
itself “del.icio.us,” it saw “a zillion different
confusions and misspellings,” such as
de.licio.us, del.icio.us.com, and del.licio.
us. Ultimately, Yahoo moved to the wildly
simplified delicious.com to make it “easier
for people to find the site and share it with
their friends.” With a new dotbrand, it seems
likely that many users will experience similar
confusion, at least at the outset, until they
become accustomed to the new structure.
There is a related discussion about the impact
of new gTLDs on email platforms. In addition
to concerns around behavioral adoption,
there could also be technical implications,
as many platforms such as Outlook and
Entourage filter spam based on the presence
of obscure domain names. To prevent
any disruption of inbound and outbound
email—particularly with marketing email
systems—it is crucial that these platforms
take steps to account for the new domain
registries, while continuing their anti-spam
efforts at the same time. Considering the
domain possibilities, this will not be a trivial
undertaking, lest they risk disturbing a
fundamental communication system for
businesses, governments, and
consumers alike.
Shorten and shorten again
For some time now, domains have been
undergoing another transformation, one
that is completely independent of ICANN:
they are becoming shorter.
Social media platforms often impose limits
on the length of users’ posts. Perhaps most
well-known is Twitter and its 140-character
restriction. With links to other content so
frequently exchanged, it’s become a necessity
to shorten the IP address, which can easily
be dozens of characters long, to make room
for everything you want to say. Twitter
even provides this service on its platform
through Bitly, a utility that takes a long URL
string and turns it into a bite-sized link. With
Google+ and Facebook implementing similar
newsfeed-style content as Twitter, short is
the new black when it comes to
sharing content.
For example, this URL from a recent Gawker
post, http://gawker.com/5827284/internetexplorer-iq-story-was-a-hoax
Became, gaw.kr/ojXOR4 when shortened by
Bitly.
So what happens when Bitly abbreviates a
brand name? Here are a few examples.
Vanity Fair – vnty.fr
Tech Crunch – tcrn.ch
Media Bistro – mbist.ro
And if you don’t want an automated
abbreviation, Bitly will even let you
customize the link, all for the low cost
of free.
But Bitly’s services go beyond shortened or
customized links. It also provides tracking
metrics for those links, giving brands
crucial information on how often users
are clicking through. Considering the Bitly
Enterprise package costs just less than US
$1000 a month, this could be an attractive
alternative to managing the infrastructure
that a domain registry demands.
In an environment where shortcuts are
easier and easier to come by, will a longer,
more complicated URL really catch on with
users? A gTLD means giving consumers more
information to remember. Perhaps all they
really need to know is how to click.
More than an address extension,
a brand extension
Besides search engines, consumer habits,
and technical implications, there is an even
more fundamental consideration to make
when considering buying a domain registry:
How will it benefit your brand?
From the beginning of the Internet, a brand’s
domain name has been seen as one of its
most critical assets. Conventional wisdom
says the stickier a name the better. But the
reality is if a brand experience— the look and
feel, tone of voice, customer service, product
quality—isn’t equally memorable, then it
doesn’t much matter how good a name is.
This is as true for dotcoms as it will be
for dotbrands. Simply owning a clever or
authoritative or adhesive domain registry
won’t mean a thing unless the brand
experience lives up to the hype. What’s in a Domain? Generic Top-Level Domains and the New Dotbrand Frontier Interbrand | Pg. 6
Keep it clear
If the brand is Coca-Cola, what should the
customized domain be? Should it be .cocacola, .cocacola or .coke,? Remember that
the non-refundable application fee—for
a single domain—is  US $185,000. Plus,
with so many potential domain variations
for the public to consider, the chances for
confusion, and with it consumer revolt,
are significant.
People expect, and the most successful
brands provide, a seamless experience
from in store to online to the mailbox to
the smartphone. Suddenly changing to a
dotbrand, and all the URLs that come along
with it, could simply be too bothersome,
too perplexing to make it worth the effort,
increasing the chances that consumers
will either try to find you through a search
engine, which makes the domain name
a non-consideration, or move on to a
competitor who’s easier to find and access.
And of course, it’s important to remember
the relevance of social media. Many
customers will likely just look a brand up
on Facebook, bypassing the larger online
world altogether.
When you add up the easy access to
bookmarks, the near ubiquity of social
media, not to mention bookmarking,
anticipatory dropdown menus, and search
fields that require you to just type in the first
few letters of what you’re after, the entire
value of a domain comes into question.
Domain versus apps
With the rise of the smartphone and the
tablet, some are wondering if the icon has
the potential to eclipse the URL altogether,
as more and more people are using apps
instead of logging on every day
For most application developers, a URL
counterpart is still seen as a necessity, an
anchor of legitimacy, which has led many
to pay top dollar for the coveted generic yet
brandable domain name. The mobile photosharing service Color paid a reported US
$350,000 for color.com, but the site features
little more than links to buy the app and a
video demo.
Another smartphone innovation with the
potential to dilute the need for a URL even
further is the quick response (QR) code. These
cousins of the bar code only ask you take
their picture, and once you do, away you go
to get more information, make a purchase,
re-order a product and more. Marketers have
fallen in love with these simple devices, and
consumers are starting to feel the same.
Considering that consumer reliance on apps
and QR codes is only going to increase, the
question becomes whether the expense of
owning a gTLD is worth it. After all, when
the app store and an icon are the primary
touchpoints, why bother typing anything
into the URL field?
When dotbrand does make sense: URL
organization
Some brands, however, can clearly benefit
from owning their own domain. Take the
entertainment and consumer industries as
an example. Many often rely on unique URLs
to communicate a new campaign, property,
or movie. This gives them the status of a
stand-alone presence, but they almost
always tie back to the parent brand in
their content.
For example, Pepsi’s Refresh campaign uses
the URL refresheverything.com, which is
linked to and from pepsi.com. Although
there isn’t even a hint of Pepsi in the URL,
the parent brand maintains an unmistakable
presence on the campaign site and in the
context of the search description.
When companies have significant spend
on unique campaigns like this, using a
domain registry to bridge properties with
their source brands can be a real advantage.
The URL Refresheverything.pepsi is unique
and distinctive, but it shuttles equity to the
parent brand as the same time.
In another example, movie studios often use
unique URLs for new properties, sometimes
adding the word “movie” or including the
studio name to distinguish them. For
Harry Potter, Warner Bros. Studios opted
for harrypotter.warnerbros.com, which
defaults to movie-specific sites.  Summit
Entertainment launched the latest in
the Twilight Saga under the URL www.
breakingdawn-themovie.com.
If Warner Bros. and Summit were to invest
in their own domain registries, however,
they could both establish a simplified
nomenclature for their online properties.
With a .wbs or .summit suffix, for example,
each film could have its own URL—
harrypotterandthedeathlyhallows.wb or
breakingdawn.summit—while fitting within
a clear, logical structure that emphasizes the
parent brand in the domain position.
These strategies avoid managing an endless
number of unrelated URLs and allow all
properties to have consistent yet still
unique names.
But the reality is if a brand experience—the
look and feel, tone of voice, customer service,
product quality—isn’t equally memorable, then
it doesn’t much matter how good a name is.What’s in a Domain? Generic Top-Level Domains and the New Dotbrand Frontier Interbrand | Pg. 7
There are limits though
Again, before a company starts writing
a check to ICANN, it needs to ask how
consumers interact with the brand. It’s also
important to look at portfolio management
and brand architecture, especially if they
own well-known product brands.
If you’re a company like P&G, where
consumers have a primary relationship with
your product brands, would a gTLD like
.pg or .pandg help? Or would consumers
be more inclined to use the product
brand to find what they want, such as
colorbleach.tide? In this case, the need
to register multiple gTLDs could become
overwhelming.
So how your portfolio is created and how
it’s used to help customers navigate your
products are critical factors in deciding
how—and if—new domains should be
bought.
And, it’s important to remember that
consumers are striving for simplicity in the
face of the information barrage they receive
daily, making them lean more heavily on
social media. Here, their networks will
curate content for them, and they can
simply click through from the Bitly link sent
by their friends, rather than keeping track
of the URL for every product that a brand
launches.
Sensing this shift, some companies, like
Vitamin Water, are leveraging their Facebook
pages more than their websites. Not only
does Facebook make it easier to connect
with consumers, it’s also easier to interact
with them, such as by posting on a person’s
wall or helping them create a playlist from
the unique content posted on the site.
And then there’s the benefit of internet
real estate
We see clear benefits for brands whose
business models are based on leasing online
real estate, like eBay, etsy, and Rakuten.
In a symbiotic relationship, members
share space with the larger, higher-profile
brand, and all the positive associations
that come with it, while still enjoying the
individuality that makes them unique in the
eyes of consumers. In these circumstances,
petespatios.ebay simply makes sense.
Other brands that may benefit from their
own domain registries are master brands that
may not be instantly linked by consumers
with their own successful product brands.
For example, Microsoft often does not get
sufficient credit for brands like xBox. A URL,
like xbox.microsoft, might help create a
better link. However, the business and brand
model behind the gTLD would need to match
the intent. Otherwise, it’s simply another link
we pick up from our search results.
Owning a category
Companies are not limited to their own
trademarks when applying for a gTLD.
Ambitious brands may file for generic
extensions like .music, .bank, or .football,
and if awarded the rights, they can literally
own their category. One example might be
an online music distributor who obtains the
.music extension. They could then license
URLs to bands, orchestras, venues, and
trade magazines, making it easy for users to
remember beatles.music, carnegiehall.music
or spin.music. The resulting community
could be an example of aggregating broad
content under a single domain that, over
time, could become the de facto destination
for all things music.
In another example, Blogger is a popular
blogging platform, as well as an occupation
for digitally savvy writers. Blogger could
potentially leverage .blogger as a valueadded benefit that encourages writers to
choose their service, while also retaining
their already loyal customers. For example,
the domain .blogger could become a badge
affixed to one’s own name or web address,
such as Jane.Smith.Blogger. This would
establish a personal brand for Jane Smith,
while shifting equity to the Blogger brand
and even the category as a whole.
Pursuing a dotcategory
 Anyone can file for a category domain in
their application. The review process entails
a seven-month objection period where
interested parties can protest and/or file a
competing application.
Rights are determined by ICANN in
a decision based on 50 questions (23
general, 21 technical and operational,
and six financial), and the applicant’s
answers determine whether dispute
resolution is required. Disputes can
range widely and include concerns about
the similarities between applications,
trademark infringement, frivolous or abusive
intentions, or a pre-existing community.
If there is no way to determine rights, an
auction decides.
It is worth noting that dispute resolution
is part of the reason for the large
application fee.
Dotcharacter versus dotcom
Another impact of the ICANN ruling is that
English is no longer the default language
for gTLDs. In theory, any word from any
language, including Chinese characters
and Arabic script, may be used as a domain
suffix. One question this raises is whether a
brand will need to buy the equivalent of its
name when operating in foreign markets.
As far as China is concerned, there doesn’t
appear to be any need to rush. While the
vast majority of Chinese people know
very little English, if any at all, those who
use the Internet are quite accustomed to
the current gTLDs. As in so many other
regions, .com is generally considered the
indicator of a business’s official website,
while .org suggests a reliable and objective
organization.
For the most part, however, Chinese
internet users simply don’t pay as much
attention to a domain as their American or
European counterparts. Few experts are
predicting a large overall impact in China;
although some do believe that fraud will
inevitably rise as a result.
ICANN’s priorities
Yet another thing to keep in mind is that
ICANN is establishing a priority system that
gives preference to public entities filing for
community gTLDs, over consumer brands
filing for standard gTLDs when applying for
the same domain registry.What’s in a Domain? Generic Top-Level Domains and the New Dotbrand Frontier Interbrand | Pg. 8
For example, if the U.S. Apple Association
files for .apple, then Apple Inc. will have to
look elsewhere.
In another example, consider Apache.
According to the new regulations, if the
Apache tribe and the Apache software
company both file for .apache, the Apache
tribe would be awarded the registry first.
Because of these restrictions, it will be
essential to check carefully who else is filing,
lest you find your application derailed during
the seven-month-long objection phase and
incur a potentially significant loss in time
and money.
What about trademark protection?
As mentioned earlier, trademark owners
are protected by mechanisms built into the
application process. Applicants must show
how they have a rights protection protocol
in place for second-level registrations, and a
clearinghouse will provide a central storage
and authentication facility for trademark
information. Although brands must still
monitor their own marks, they can pursue
an objection-based process if they fear
infringement on their legal rights.
Additionally, recent provisions in the 350+
page gTLD Applicant Guidebook now afford
trademark owners even more protection
than previous editions allowed for. Now,
all new gTLD operators will be required to
offer brand owners two types of protection:
trademark claims and sunrise periods.
The trademark claims service is intended to
notify brand owners, whose marks are on
file with the clearinghouse, when a secondlevel domain name matching their mark is
applied for. The advantage here is that brand
owners may not need to defensively register
all their names across multiple new top-level
domains.
The sunrise period provides a priority
phase for trademark owners who want to
register during the launch of a new domain
extension, before open registration is
allowed. This means that brand owners can
secure their most important names, in case
a third party might attempt to do so.
What this adds up to for trademarks
Whether or not a company applies for a gTLD,
as a brand owner it will still need to monitor
applications for new extensions that match
its trademarks, plus applications that contain
generic or standard industry terms, as well
as competitors’ new gTLD applications.
Trademark owners will need to position
themselves so that they can, if necessary,
take action against the new gTLDs and
domain names that will likely be applied for
in the coming months (regardless of whether
they’re applying for new gTLDs or not). The
Legal Rights Objection process is in place
to assist owners when they believe a gTLD
infringes on their trademark.
While the final—or fine—details will likely not
be clear until the full process is underway,
trademark owners need to ask themselves if
owning and running a gTLD gives them the
desired level of brand control, or if the various
protection mechanisms ICANN has outlined
sufficiently meets their needs.
And of course, it’s important to factor in
the considerable costs involved, and the
possibility that consumers and online users
may not adopt, or adapt to, the new Internet
structure.
Opposition to gTLD expansion
Many brands and business organizations are
deeply opposed to the ICANN ruling. Their
concern is that the new domain system is
essentially forcing companies to apply—and
pay up—for something they already own,
their trademarks.
It’s unclear whether organized opposition
will force ICANN to reconsider, and the
issue is certainly worth keeping an eye on
the months leading up to the start of the
application process.
If you make the investment, make the
most of it
As we have seen, securing a gTLD is not an
inexpensive exercise. Initial application fees
run $185,000 with ongoing fees of $25,000 a
year for a minimum of 10 years. Additionally,
all applicants must prove to ICANN that they
have the infrastructure in place to manage
the domain registry and the financial
resources to fund it.
To simply get a domain up and running,
current estimates are ranging between
$1 and $2 million. Add to this the need to
maintain all currently held domains for
the extended period of time it will take for
consumers to become accustomed to the
new domain construct.
And it goes beyond monetary investment. It
also involves time and far-sighted decisions
on how to manage the domain, and how
it will benefit both brand and business
strategies.
So, it’s safe to say that if a brand doesn’t
already invest significantly in creating an
online destination experience, then securing
a gTLD simply will not be enough to capture
consumer attention and loyalty.
Without an already pronounced investment
in digital strategy, brands must be cautious
in their pursuit of a domain registry because
protection is simply not good enough of a
reason to warrant the time and effort, both
of which are potentially dramatic drains
on resources.
On the other hand, securing a new gTLD
could signal a significant change in how
brands approach their online experience as a
whole—so if a company does commit, they
should use it as an opportunity to maximize
their presence in this ever-more critical
communication channel.
Any questions?
More than a few, we imagine.
While the prospect of owning a domain is an
exciting one, the process, the benefits, and
the pitfalls demand serious consideration.
Understanding that you may have lingering
questions, we’ve attempted to anticipate a
few of them here.
1. What are gTLDs?
Generic Top-Level Domains are the suffixes
at the end of a URL. Currently, gTLDs are
limited to 22, including .com, .net, .org and
other familiar extensions. With the recent
ICANN ruling, it will be possible for anything What’s in a Domain? Generic Top-Level Domains and the New Dotbrand Frontier Interbrand | Pg. 9
to be used as a gTLD providing it is three
characters or longer. Two-letter TLDs are
reserved for country codes, such as .jp for
Japan or .uk for the United Kingdom.
2. How will ICANN choose to
allocate these?
ICANN has established a system that invites
companies and public entities to apply
for their own gTLD. Preference is given to
community filers over companies when both
apply for the same gTLD. A long, in-depth
application process has been developed, and
it will be the responsibility of the applicant
to meet all of ICANN’s requirements before it
will be awarded its own gTLD.
3. Is this imperative, or should I
wait and see?
It depends on a number of factors. Perhaps
most important is whether owning a unique
gTLD will clearly benefit your brand, your
business, and your online strategy. Simply
filing just to own a dotbrand, even if seen
as a protective measure, could be a waste
of valuable resources, especially since gTLD
owners must maintain the domain for at
least 10 years. ICANN expects all new gTLDs
to be operational; brand owners cannot
“reserve” or just secure the extension and
do nothing with it—at a minimum, a closed
registry will be required.
4. What does the application
process entail?
ICANN has put into a place a multi-phase
evaluation process that begins with a
200+ page application and includes an
administrative check, initial evaluation, and
a pre-delegation segment. The process can
take anywhere from nine to 20 months.
5. What are the estimated costs
associated with registering a gTLD?
The non-refundable application fee will
cost US $185,000, and ICANN will charge
a fee of US $25,000 a year over the course
of the 10-year license. With additional cost
considerations including establishing and
managing an infrastructure, maintaining
current domains over a transitional period
and associated legal fees, total cost
estimates range between US $1 and US $2
million just to get a gTLD operational.
6. When does the application process for
new gTLDs start and how long until the
public will see the new domains?
The application process will run from
January through April 2012. After April,
new applicants will have to wait until the
next window. By the end of 2012, the public
should see the first new domains in use.
7. If I don’t register a gTLD, how can I
ensure that someone else won’t take it?
This time it’s different. Trademark holders
are offered some protection by an objectionbased process, which allows them to
demonstrate that a proposed gTLD string
would infringe on their legal rights. However,
trademark owners are responsible for
monitoring new gTLD applications— ICANN
will not notify you of potential
trademark conflicts.
Further, applicants must show they have a
rights protection protocol in place for secondlevel registrations, and a clearinghouse will
provide a central storage and authentication
facility for trademark information.
Additionally, an objection-based process
will be in place to allow rights holders to
challenge possible infringements on their
legal rights.
8. Will owning a gTLD mean I can forget
about my current extensions (.com, .net,
.co.uk)?
No. It will be necessary to monitor all of your
presently used extensions for the foreseeable
future. And once your gTLD is in place, you
will likely need to continue to maintain
your current web presence until consumers
become accustomed to your new domain.
9. What happens after my application is
approved?
Once approved, you will be required to
conclude an agreement with ICANN and pass
technical pre-delegation tests.
10. I’m not convinced my brand needs to
rush to own a gTLD, so I’m going to wait
and see. Anything else I should
keep in mind?
You must be comfortable with the risk
of being locked out if another party
demonstrates its rights to an extension that
is the same or similar to yours. An oft-cited
example is .ups for United Parcel Service and
.ubs for the Swiss banking giant UBS. ■Creating and managing
brand value
TM
interbrand.com
Jerome McDonnell
Jerome is Group Trademark Director. He
manages Interbrand’s global portfolio of
trademarks and domain names, and leads the
New York office’s trademark practice, which
provides research and risk analysis on names,
taglines, and logos from creative groups
across our North American offices.
Paola Norambuena
Paola is the Executive Director of Verbal
Identity, North America, managing the
practice for naming, voice, messaging,
creative writing, and ideation.
Jeff Mancini
Jeff is Senior Director of Strategy, New York,
and, along with his team, drives the digital
practice at Interbrand. He heads the digital
task force in New York  as well as a global
digital task force for the wider
 Interbrand network.

gTLD Applicant Guidebook

19 September 2011
gTLD Applicant
Guidebook            
Version 2011-09-1919 September 2011
ICANN’s Board of Directors approved the New Generic Top-Level Domain Program
in June 2011, ushering in a vast change to the Internet’s domain name system. The
historic decision was featured in thousands of media outlets around the world. It
followed years of discussion, debate and deliberation with many different
communities, including business groups, cultural organizations and governments.
We expect the program to bring benefits to language and other communities,
provide opportunities for innovation, and introduce new protections for users and
rights holders.
Today, we are just months away from the scheduled opening of the application
window and in the execution stage of a global communications effort to raise
awareness of this dramatic change. In keeping with our established timeline, the
Applicant Guidebook has been updated based on the direction given within the
Board’s resolution at the 20 June meeting in Singapore.
The New gTLD Program is the result of thousands of hours of work by our
stakeholders, and is a testament to the value of the multi-stakeholder process,
ICANN’s unique bottom-up, consensus-driven approach. As we have developed this
program, we have laid the foundation for the future of the Internet.
ICANN will provide further refinements to the Guidebook as warranted. In addition,
information will be given on the process for providing assistance for potential
applicants from developing countries. Details are currently under development by
the Joint Applicant Support Working Group, staffed by independent stakeholders.
At the heart of ICANN’s mission is the security and stability of the domain name
system. In performing its core functions of overseeing the Internet's unique
identifier systems, ICANN also promotes competition and consumer choice. New
gTLDs are in line with those goals, and I thank you for your anticipated participation
and support.
Rod Beckstrom
President and CEO Preamble
New gTLD Program Background
New gTLDs have been in the forefront of ICANN’s agenda since its creation.  The new gTLD
program will open up the top level of the Internet’s namespace to foster diversity, encourage
competition, and enhance the utility of the DNS.
Currently the namespace consists of 22 gTLDs and over 250 ccTLDs operating on various models.
Each of the gTLDs has a designated “registry operator” and, in most cases, a Registry Agreement
between the operator (or sponsor) and ICANN.   The registry operator is responsible for the
technical operation of the TLD, including all of the names registered in that TLD.  The gTLDs are
served by over 900 registrars, who interact with registrants to perform domain name registration and
other related services.  The new gTLD program will create a means for prospective registry
operators to apply for new gTLDs, and create new options for consumers in the market.  When the
program launches its first application round, ICANN expects a diverse set of applications for new
gTLDs, including IDNs, creating significant potential for new uses and benefit to Internet users across
the globe.  
The program has its origins in carefully deliberated policy development work by the ICANN
community.  In October 2007, the Generic Names Supporting Organization (GNSO)—one of the
groups that coordinate global Internet policy at ICANN—formally completed its policy
development work on new gTLDs and approved a set of 19 policy recommendations.
Representatives from a wide variety of stakeholder groups—governments, individuals, civil society,
business and intellectual property constituencies, and the technology community—were engaged
in discussions for more than 18 months on such questions as the demand, benefits and risks of new
gTLDs, the selection criteria that should be applied, how gTLDs should be allocated, and the
contractual conditions that should be required for new gTLD registries going forward. The
culmination of this policy development process was a decision by the ICANN Board of Directors to
adopt the community-developed policy in June 2008. A thorough brief to the policy process and
outcomes can be found at http://gnso.icann.org/issues/new-gtlds.
ICANN’s work next focused on implementation:  creating an application and evaluation process
for new gTLDs that is aligned with the policy recommendations and provides a clear roadmap for
applicants to reach delegation, including Board approval.  This implementation work is reflected in
the drafts of the applicant guidebook that were released for public comment, and in the
explanatory papers giving insight into rationale behind some of the conclusions reached on
specific topics.  Meaningful community input has led to revisions of the draft applicant guidebook.
In parallel, ICANN has established the resources needed to successfully launch and operate the
program. This process concluded with the decision by the ICANN Board of Directors in June 2011 to
launch the New gTLD Program.
For current information, timelines and activities related to the New gTLD Program, please go to
http://www.icann.org/en/topics/new-gtld-program.htm.gTLD Applicant
Guidebook
(v. 2011-09-19)
Module 1
19 September 2011Applicant Guidebook | version 2011-09-19
1-1
Module 1
Introduction to the gTLD Application Process
This module gives applicants an overview of the process for
applying for a new generic top-level domain, and includes
instructions on how to complete and submit an
application, the supporting documentation an applicant
must submit with an application, the fees required, and
when and how to submit them.
This module also describes the conditions associated with
particular types of applications, and the stages of the
application life cycle.
Prospective applicants are encouraged to read and
become familiar with the contents of this entire module, as
well as the others, before starting the application process
to make sure they understand what is required of them
and what they can expect at each stage of the
application evaluation process.
For the complete set of the supporting documentation
and more about the origins, history and details of the
policy development background to the New gTLD
Program, please see http://gnso.icann.org/issues/newgtlds/.
This Applicant Guidebook is the implementation of Boardapproved consensus policy concerning the introduction of
new gTLDs, and has been revised extensively via public
comment and consultation over a two-year period.
1.1 Application Life Cycle and Timelines
This section provides a description of the stages that an
application passes through once it is submitted. Some
stages will occur for all applications submitted; others will
only occur in specific circumstances. Applicants should be
aware of the stages and steps involved in processing
applications received.
1.1.1  Application Submission Dates
The user registration and application submission periods
open at 00:01 UTC 12 January 2012.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-2
The user registration period closes at 23:59 UTC 29 March
2012. New users to TAS will not be accepted beyond this
time. Users already registered will be able to complete the
application submission process.
Applicants should be aware that, due to required
processing steps (i.e., online user registration, application
submission, fee submission, and fee reconciliation) and
security measures built into the online application system, it
might take substantial time to perform all of the necessary
steps to submit a complete application. Accordingly,
applicants are encouraged to submit their completed
applications and fees as soon as practicable after the
Application Submission Period opens. Waiting until the end
of this period to begin the process may not provide
sufficient time to submit a complete application before the
period closes. Accordingly, new user registrations will not
be accepted after the date indicated above.
The application submission period closes at 23:59 UTC 12
April 2012.
To receive consideration, all applications must be
submitted electronically through the online application
system by the close of the application submission period.
An application will not be considered, in the absence of
exceptional circumstances, if:
• It is received after the close of the application
submission period.
• The application form is incomplete (either the
questions have not been fully answered or required
supporting documents are missing). Applicants will
not ordinarily be permitted to supplement their
applications after submission.
• The evaluation fee has not been paid by the
deadline. Refer to Section 1.5 for fee information.
ICANN has gone to significant lengths to ensure that the
online application system will be available for the duration
of the application submission period. In the event that the
system is not available, ICANN will provide alternative
instructions for submitting applications on its website.
1.1.2 Application Processing Stages
This subsection provides an overview of the stages involved
in processing an application submitted to ICANN. Figure
1-1 provides a simplified depiction of the process. The Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-3
shortest and most straightforward path is marked with bold
lines, while certain stages that may or may not be
applicable in any given case are also shown. A brief
description of each stage follows.
Application
Submission
Period
Initial
Evaluation
Transition to
Delegation
Extended
Evaluation
Dispute
Resolution
String
Contention
Administrative
Completeness
Check
Objection
Filing
Time
Figure 1-1 – Once submitted to ICANN, applications will pass through multiple
stages of processing.
1.1.2.1 Application Submission Period
At the time the application submission period opens, those
wishing to submit new gTLD applications can become
registered users of the TLD Application System (TAS).
After completing the user registration, applicants will supply
a deposit for each requested application slot (see section
1.4), after which they will receive access to the full
application form. To complete the application, users will
answer a series of questions to provide general information,
demonstrate financial capability, and demonstrate
technical and operational capability. The supporting
documents listed in subsection 1.2.2 of this module must
also be submitted through the online application system as
instructed in the relevant questions.
Applicants must also submit their evaluation fees during this
period. Refer to Section 1.5 of this module for additional
information about fees and payments.
Each application slot is for one gTLD. An applicant may
submit as many applications as desired; however, there is
no means to apply for more than one gTLD in a single
application.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-4
Following the close of the application submission period,
ICANN will provide applicants with periodic status updates
on the progress of their applications.
1.1.2.2 Administrative Completeness Check
Immediately following the close of the application
submission period, ICANN will begin checking all
applications for completeness. This check ensures that:
• All mandatory questions are answered;
• Required supporting documents are provided in
the proper format(s); and
• The evaluation fees have been received.
ICANN will post the public portions of all applications
considered complete and ready for evaluation within two
weeks of the close of the application submission period.
Certain questions relate to internal processes or
information:  applicant responses to these questions will not
be posted. Each question is labeled in the application form
as to whether the information will be posted. See posting
designations for the full set of questions in the attachment
to Module 2.
The administrative completeness check is expected to be
completed for all applications in a period of approximately
8 weeks, subject to extension depending on volume. In the
event that all applications cannot be processed within this
period, ICANN will post updated process information and
an estimated timeline.
1.1.2.3 Comment Period
Public comment mechanisms are part of ICANN’s policy
development, implementation, and operational processes.
As a private-public partnership, ICANN is dedicated to:
preserving the operational security and stability of the
Internet, promoting competition, achieving broad
representation of global Internet communities, and
developing policy appropriate to its mission through
bottom-up, consensus-based processes. This necessarily
involves the participation of many stakeholder groups in a
public discussion.
ICANN will open a comment period (the Application
Comment period) at the time applications are publicly
posted on ICANN’s website (refer to subsection 1.1.2.2). This
period will allow time for the community to review and
submit comments on posted application materialsModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-5
(referred to as “application comments.”) The comment
forum will require commenters to associate comments with
specific applications and the relevant panel. Application
comments received within a 60-day period from the
posting of the application materials will be available to the
evaluation panels performing the Initial Evaluation reviews.
This period is subject to extension, should the volume of
applications or other circumstances require. To be
considered by evaluators, comments must be received in
the designated comment forum within the stated time
period.
Evaluators will perform due diligence on the application
comments (i.e., determine their relevance to the
evaluation, verify the accuracy of claims, analyze
meaningfulness of references cited) and take the
information provided in these comments into
consideration. In cases where consideration of the
comments has impacted the scoring of the application,
the evaluators will seek clarification from the applicant.
Statements concerning consideration of application
comments that have impacted the evaluation decision will
be reflected in the evaluators’ summary reports, which will
be published at the end of Extended Evaluation.  
Comments received after the 60-day period will be stored
and available (along with comments received during the
comment period) for other considerations, such as the
dispute resolution process, as described below.
In the new gTLD application process, all applicants should
be aware that comment fora are a mechanism for the
public to bring relevant information and issues to the
attention of those charged with handling new gTLD
applications. Anyone may submit a comment in a public
comment forum.
Comments and the Formal Objection Process:  A distinction
should be made between application comments, which
may be relevant to ICANN’s task of determining whether
applications meet the established criteria, and formal
objections that concern matters outside those evaluation
criteria. The formal objection process was created to allow
a full and fair consideration of objections based on certain
limited grounds outside ICANN’s evaluation of applications
on their merits (see subsection 3.2).
Public comments will not be considered as formal
objections. Comments on matters associated with formal
objections will not be considered by panels during Initial
Evaluation. These comments will be available to and may Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-6
be subsequently considered by an expert panel during a
dispute resolution proceeding (see subsection 1.1.2.9).
However, in general, application comments have a very
limited role in the dispute resolution process.
String Contention:  Comments designated for the
Community Priority Panel, as relevant to the criteria in
Module 4, may be taken into account during a Community
Priority Evaluation.
Government Notifications:  Governments may provide a
notification using the application comment forum to
communicate concerns relating to national laws. However,
a government’s notification of concern will not in itself be
deemed to be a formal objection. A notification by a
government does not constitute grounds for rejection of a
gTLD application. A government may elect to use this
comment mechanism to provide such a notification, in
addition to or as an alternative to the GAC Early Warning
procedure described in subsection 1.1.2.4 below.
Governments may also communicate directly to
applicants using the contact information posted in the
application, e.g., to send a notification that an applied-for
gTLD string might be contrary to a national law, and to try
to address any concerns with the applicant.
General Comments:  A general public comment forum will
remain open through all stages of the evaluation process,
to provide a means for the public to bring forward any
other relevant information or issues.
1.1.2.4 GAC Early Warning
Concurrent with the 60-day comment period, ICANN’s
Governmental Advisory Committee (GAC) may issue a
GAC Early Warning notice concerning an application. This
provides the applicant with an indication that the
application is seen as potentially sensitive or problematic
by one or more governments.
The GAC Early Warning is a notice only. It is not a formal
objection, nor does it directly lead to a process that can
result in rejection of the application. However, a GAC Early
Warning should be taken seriously as it raises the likelihood
that the application could be the subject of GAC Advice
on New gTLDs (see subsection 1.1.2.7) or of a formal
objection (see subsection 1.1.2.6) at a later stage in the
process. Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-7
A GAC Early Warning typically results from a notice to the
GAC by one or more governments that an application
might be problematic, e.g., potentially violate national law
or raise sensitivities. A GAC Early Warning may be issued for
any reason.1
The GAC may then send that notice to the
Board – constituting the GAC Early Warning. ICANN will
notify applicants of GAC Early Warnings as soon as
practicable after receipt from the GAC. The GAC Early
Warning notice may include a nominated point of contact
for further information.
GAC consensus is not required for a GAC Early Warning to
be issued. Minimally, the GAC Early Warning must be
provided in writing to the ICANN Board, and be clearly
labeled as a GAC Early Warning. This may take the form of
an email from the GAC Chair to the ICANN Board. For
GAC Early Warnings to be most effective, they should
include the reason for the warning and identify the
objecting countries.
Upon receipt of a GAC Early Warning, the applicant may
elect to withdraw the application for a partial refund (see
subsection 1.5.1), or may elect to continue with the
application (this may include meeting with representatives
from the relevant government(s) to try to address the
concern). To qualify for the refund described in subsection
1.5.1, the applicant must provide notification to ICANN of
its election to withdraw the application within 21 calendar
days of the GAC Early Warning delivery.
To reduce the possibility of a GAC Early Warning, all
applicants are encouraged to identify potential sensitivities
in advance of application submission, and to work with the
relevant parties (including governments) beforehand to
mitigate concerns related to the application.
1.1.2.5 Initial Evaluation
Initial Evaluation will begin immediately after the
administrative completeness check concludes. All
complete applications will be reviewed during Initial
Evaluation. At the beginning of this period, background
screening on the applying entity and the individuals
named in the application will be conducted. Applications
                                                   
1
While definitive guidance has not been issued, the GAC has indicated that strings that could raise sensitivities include those that
"purport to represent or that embody a particular group of people or interests based on historical, cultural, or social components of
identity, such as nationality, race or ethnicity, religion, belief, culture or particular social origin or group, political opinion, membership
of a national minority, disability, age, and/or a language or linguistic group (non-exhaustive)" and "those strings that refer to particular
sectors, such as those subject to national regulation (such as .bank, .pharmacy) or those that describe or are targeted to a
population or industry that is vulnerable to online fraud or abuse.”Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-8
must pass this step in conjunction with the Initial Evaluation
reviews.
There are two main elements of the Initial Evaluation:
1. String reviews (concerning the applied-for gTLD
string). String reviews include a determination that
the applied-for gTLD string is not likely to cause
security or stability problems in the DNS, including
problems caused by similarity to existing TLDs or
reserved names.
2. Applicant reviews (concerning the entity applying
for the gTLD and its proposed registry services).
Applicant reviews include a determination of
whether the applicant has the requisite technical,
operational, and financial capabilities to operate a
registry.
By the conclusion of the Initial Evaluation period, ICANN will
post notice of all Initial Evaluation results. Depending on
the volume of applications received, such notices may be
posted in batches over the course of the Initial Evaluation
period.
The Initial Evaluation is expected to be completed for all
applications in a period of approximately 5 months. If the
volume of applications received significantly exceeds 500,
applications will be processed in batches and the 5-month
timeline will not be met. The first batch will be limited to 500
applications and subsequent batches will be limited to 400
to account for capacity limitations due to managing
extended evaluation, string contention, and other
processes associated with each previous batch.
If batching is required, a process external to the
application submission process will be employed to
establish evaluation priority. This process will be based on
an online ticketing system or other objective criteria.
If batching is required, the String Similarity review will be
completed on all applications prior to the establishment of
evaluation priority batches. For applications identified as
part of a contention set, the entire contention set will be
kept together in the same batch.
If batches are established, ICANN will post updated
process information and an estimated timeline.
Note that the processing constraints will limit delegation
rates to a steady state even in the event of an extremely
high volume of applications. The annual delegation rate Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-9
will not exceed 1,000 per year in any case, no matter how
many applications are received.2
1.1.2.6 Objection Filing
Formal objections to applications can be filed on any of
four enumerated grounds, by parties with standing to
object. The objection filing period will open after ICANN
posts the list of complete applications as described in
subsection 1.1.2.2, and will last for approximately 7 months.
Objectors must file such formal objections directly with
dispute resolution service providers (DRSPs), not with
ICANN. The objection filing period will close following the
end of the Initial Evaluation period (refer to subsection
1.1.2.5), with a two-week window of time between the
posting of the Initial Evaluation results and the close of the
objection filing period. Objections that have been filed
during the objection filing period will be addressed in the
dispute resolution stage, which is outlined in subsection
1.1.2.9 and discussed in detail in Module 3.
All applicants should be aware that third parties have the
opportunity to file objections to any application during the
objection filing period. Applicants whose applications are
the subject of a formal objection will have an opportunity
to file a response according to the dispute resolution
service provider’s rules and procedures. An applicant
wishing to file a formal objection to another application
that has been submitted would do so within the objection
filing period, following the objection filing procedures in
Module 3.
Applicants are encouraged to identify possible regional,
cultural, property interests, or other sensitivities regarding
TLD strings and their uses before applying and, where
possible, consult with interested parties to mitigate any
concerns in advance.
1.1.2.7 Receipt of GAC Advice on New gTLDs
The GAC may provide public policy advice directly to the
ICANN Board on any application. The procedure for GAC
Advice on New gTLDs described in Module 3 indicates
that, to be considered by the Board during the evaluation
process, the GAC Advice on New gTLDs must be submitted
by the close of the objection filing period. A GAC Early
Warning is not a prerequisite to use of the GAC Advice
process.
                                                   
2
See "Delegation Rate Scenarios for New gTLDs" at http://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-
06oct10-en.pdf for additional discussion.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-10
GAC Advice on New gTLDs that includes a consensus
statement3
from the GAC that an application should not
proceed as submitted (or other terms created by the GAC
to express that intent), and that includes a thorough
explanation of the public policy basis for such advice, will
create a strong presumption for the Board that the
application should not be approved. If the Board does not
act in accordance with this type of advice, it must provide
rationale for doing so.
See Module 3 for additional detail on the procedures
concerning GAC Advice on New gTLDs.
1.1.2.8 Extended Evaluation
Extended Evaluation is available only to certain applicants
that do not pass Initial Evaluation.
Applicants failing certain elements of the Initial Evaluation
can request an Extended Evaluation. If the applicant does
not pass Initial Evaluation and does not expressly request
an Extended Evaluation, the application will proceed no
further. The Extended Evaluation period allows for an
additional exchange of information between the
applicant and evaluators to clarify information contained
in the application. The reviews performed in Extended
Evaluation do not introduce additional evaluation criteria.
An application may be required to enter an Extended
Evaluation if one or more proposed registry services raise
technical issues that might adversely affect the security or
stability of the DNS. The Extended Evaluation period
provides a time frame for these issues to be investigated.
Applicants will be informed if such a review is required by
the end of the Initial Evaluation period.
Evaluators and any applicable experts consulted will
communicate the conclusions resulting from the additional
review by the end of the Extended Evaluation period.
At the conclusion of the Extended Evaluation period,
ICANN will post summary reports, by panel, from the Initial
and Extended Evaluation periods.
If an application passes the Extended Evaluation, it can
then proceed to the next relevant stage. If the application
does not pass the Extended Evaluation, it will proceed no
further.
                                                   
3
The GAC will clarify the basis on which consensus advice is developed.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-11
The Extended Evaluation is expected to be completed for
all applications in a period of approximately 5 months,
though this timeframe could be increased based on
volume. In this event, ICANN will post updated process
information and an estimated timeline.
1.1.2.9 Dispute Resolution
Dispute resolution applies only to applicants whose
applications are the subject of a formal objection.
Where formal objections are filed and filing fees paid
during the objection filing period, independent dispute
resolution service providers (DRSPs) will initiate and
conclude proceedings based on the objections received.
The formal objection procedure exists to provide a path for
those who wish to object to an application that has been
submitted to ICANN. Dispute resolution service providers
serve as the fora to adjudicate the proceedings based on
the subject matter and the needed expertise.
Consolidation of objections filed will occur where
appropriate, at the discretion of the DRSP.
As a result of a dispute resolution proceeding, either the
applicant will prevail (in which case the application can
proceed to the next relevant stage), or the objector will
prevail (in which case either the application will proceed
no further or the application will be bound to a contention
resolution procedure). In the event of multiple objections,
an applicant must prevail in all dispute resolution
proceedings concerning the application to proceed to the
next relevant stage. Applicants will be notified by the
DRSP(s) of the results of dispute resolution proceedings.
Dispute resolution proceedings, where applicable, are
expected to be completed for all applications within
approximately a 5-month time frame. In the event that
volume is such that this timeframe cannot be
accommodated, ICANN will work with the dispute
resolution service providers to create processing
procedures and post updated timeline information.
1.1.2.10 String Contention
String contention applies only when there is more than one
qualified application for the same or similar gTLD strings.
String contention refers to the scenario in which there is
more than one qualified application for the identical gTLD
string or for similar gTLD strings. In this Applicant Guidebook,
“similar” means strings so similar that they create a Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-12
probability of user confusion if more than one of the strings
is delegated into the root zone.
Applicants are encouraged to resolve string contention
cases among themselves prior to the string contention
resolution stage. In the absence of resolution by the
contending applicants, string contention cases are
resolved either through a community priority evaluation (if
a community-based applicant elects it) or through an
auction.
In the event of contention between applied-for gTLD
strings that represent geographic names, the parties may
be required to follow a different process to resolve the
contention. See subsection 2.2.1.4 of Module 2 for more
information.
Groups of applied-for strings that are either identical or
similar are called contention sets. All applicants should be
aware that if an application is identified as being part of a
contention set, string contention resolution procedures will
not begin until all applications in the contention set have
completed all aspects of evaluation, including dispute
resolution, if applicable.
To illustrate, as shown in Figure 1-2, Applicants A, B, and C
all apply for .EXAMPLE and are identified as a contention
set. Applicants A and C pass Initial Evaluation, but
Applicant B does not. Applicant B requests Extended
Evaluation. A third party files an objection to Applicant C’s
application, and Applicant C enters the dispute resolution
process. Applicant A must wait to see whether Applicants
B and C successfully complete the Extended Evaluation
and dispute resolution phases, respectively, before it can
proceed to the string contention resolution stage. In this
example, Applicant B passes the Extended Evaluation, but
Applicant C does not prevail in the dispute resolution
proceeding. String contention resolution then proceeds
between Applicants A and B.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-13
Figure 1-2 – All applications in a contention set must complete all previous
evaluation and dispute resolution stages before string contention
resolution can begin.
Applicants prevailing in a string contention resolution
procedure will proceed toward delegation of the appliedfor gTLDs.
String contention resolution for a contention set is
estimated to take from 2.5 to 6 months to complete. The
time required will vary per case because some contention
cases may be resolved in either a community priority
evaluation or an auction, while others may require both
processes.
1.1.2.11 Transition to Delegation
Applicants successfully completing all the relevant stages
outlined in this subsection 1.1.2 are required to carry out a
series of concluding steps before delegation of the
applied-for gTLD into the root zone. These steps include
execution of a registry agreement with ICANN and
completion of a pre-delegation technical test to validate
information provided in the application.
Following execution of a registry agreement, the
prospective registry operator must complete technical setup and show satisfactory performance on a set of
technical tests before delegation of the gTLD into the root
zone may be initiated. If the pre-delegation testing
requirements are not satisfied so that the gTLD can be
delegated into the root zone within the time frame
specified in the registry agreement, ICANN may in its sole
and absolute discretion elect to terminate the registry
agreement.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-14
Once all of these steps have been successfully completed,
the applicant is eligible for delegation of its applied-for
gTLD into the DNS root zone.
It is expected that the transition to delegation steps can be
completed in approximately 2 months, though this could
take more time depending on the applicant’s level of
preparedness for the pre-delegation testing and the
volume of applications undergoing these steps
concurrently.
1.1.3   Lifecycle Timelines
Based on the estimates for each stage described in this
section, the lifecycle for a straightforward application
could be approximately 9 months, as follows:
Initial Evaluation
Transition to Delegation
5 Months
2 Months
Administrative Check
2 Months
Figure 1-3 – A straightforward application could have an approximate 9-month
lifecycle.
The lifecycle for a highly complex application could be
much longer, such as 20 months in the example below:Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-15
2 Months
Extended Evaluation
String Contention [May consist of Community Priority, Auction, or both]
Transition to Delegation
5 Months
5 Months
2.5 - 6 Months
2 Months
Dispute Resolution
Initial Evaluation
Objection
Filing
Admin Completeness Check
Figure 1-4 – A complex application could have an approximate 20-month lifecycle.
1.1.4 Posting Periods
The results of application reviews will be made available to
the public at various stages in the process, as shown
below.
Period Posting Content
During Administrative
Completeness Check
Public portions of all applications (posted
within 2 weeks of the start of the
Administrative Completeness Check).
End of Administrative
Completeness Check
Results of Administrative Completeness
Check.
GAC Early Warning Period GAC Early Warnings received.
During Initial Evaluation
Status updates for applications withdrawn or
ineligible for further review.
Contention sets resulting from String
Similarity review.  
End of Initial Evaluation
Application status updates with all Initial
Evaluation results.
GAC Advice on New gTLDs GAC Advice received.
End of Extended Evaluation
Application status updates with all Extended
Evaluation results.
Evaluation summary reports from the Initial
and Extended Evaluation periods.
During Objection  Information on filed objections and status Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-16
Period Posting Content
Filing/Dispute Resolution updates available via Dispute Resolution
Service Provider websites.
Notice of all objections posted by ICANN
after close of objection filing period.
During Contention Resolution
(Community Priority
Evaluation)
Results of each Community Priority
Evaluation posted as completed.
During Contention Resolution
(Auction)
Results from each auction posted as
completed.
Transition to Delegation
Registry Agreements posted when
executed.
Pre-delegation testing status updated.
1.1.5 Sample Application Scenarios
The following scenarios briefly show a variety of ways in
which an application may proceed through the
evaluation process. The table that follows exemplifies
various processes and outcomes. This is not intended to be
an exhaustive list of possibilities. There are other possible
combinations of paths an application could follow.
Estimated time frames for each scenario are also included,
based on current knowledge. Actual time frames may vary
depending on several factors, including the total number
of applications received by ICANN during the application
submission period. It should be emphasized that most
applications are expected to pass through the process in
the shortest period of time, i.e., they will not go through
extended evaluation, dispute resolution, or string
contention resolution processes. Although most of the
scenarios below are for processes extending beyond nine
months, it is expected that most applications will complete
the process within the nine-month timeframe.
Scenario
Number
Initial
Evaluation
Extended
Evaluation
Objection(s)
Filed
String
Contention
Approved
for Delegation
Steps
Estimated
Elapsed
Time
1 Pass N/A None No Yes 9 months
2 Fail Pass None No Yes
14
months
3 Pass N/A None Yes Yes
11.5 – 15
months
4 Pass N/A
Applicant
prevails
No Yes
14
months
5 Pass N/A
Objector
prevails
N/A No
12
months
6 Fail Quit N/A N/A No 7 monthsModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-17
Scenario
Number
Initial
Evaluation
Extended
Evaluation
Objection(s)
Filed
String
Contention
Approved
for Delegation
Steps
Estimated
Elapsed
Time
7 Fail Fail N/A N/A No
12
months
8 Fail Pass
Applicant
prevails
Yes Yes
16.5 – 20
months
9 Fail Pass
Applicant
prevails
Yes No
14.5 – 18
months
Scenario 1 – Pass Initial Evaluation, No Objection, No
Contention – In the most straightforward case, the
application passes Initial Evaluation and there is no need
for an Extended Evaluation. No objections are filed during
the objection period, so there is no dispute to resolve. As
there is no contention for the applied-for gTLD string, the
applicant can enter into a registry agreement and the
application can proceed toward delegation of the
applied-for gTLD. Most applications are expected to
complete the process within this timeframe.
Scenario 2 – Extended Evaluation, No Objection, No
Contention – In this case, the application fails one or more
aspects of the Initial Evaluation. The applicant is eligible for
and requests an Extended Evaluation for the appropriate
elements. Here, the application passes the Extended
Evaluation. As with Scenario 1, no objections are filed
during the objection period, so there is no dispute to
resolve. As there is no contention for the gTLD string, the
applicant can enter into a registry agreement and the
application can proceed toward delegation of the
applied-for gTLD.
Scenario 3 – Pass Initial Evaluation, No Objection,
Contention – In this case, the application passes the Initial
Evaluation so there is no need for Extended Evaluation. No
objections are filed during the objection period, so there is
no dispute to resolve. However, there are other
applications for the same or a similar gTLD string, so there is
contention. In this case, the application prevails in the
contention resolution, so the applicant can enter into a
registry agreement and the application can proceed
toward delegation of the applied-for gTLD.
Scenario 4 – Pass Initial Evaluation, Win Objection, No
Contention – In this case, the application passes the Initial
Evaluation so there is no need for Extended Evaluation.
During the objection filing period, an objection is filed on
one of the four enumerated grounds by an objector with Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-18
standing (refer to Module 3, Objection Procedures). The
objection is heard by a dispute resolution service provider
panel that finds in favor of the applicant. The applicant
can enter into a registry agreement and the application
can proceed toward delegation of the applied-for gTLD.
Scenario 5 – Pass Initial Evaluation, Lose Objection – In this
case, the application passes the Initial Evaluation so there
is no need for Extended Evaluation. During the objection
period, multiple objections are filed by one or more
objectors with standing for one or more of the four
enumerated objection grounds. Each objection is heard
by a dispute resolution service provider panel. In this case,
the panels find in favor of the applicant for most of the
objections, but one finds in favor of the objector. As one of
the objections has been upheld, the application does not
proceed.
Scenario 6 – Fail Initial Evaluation, Applicant Withdraws – In
this case, the application fails one or more aspects of the
Initial Evaluation. The applicant decides to withdraw the
application rather than continuing with Extended
Evaluation. The application does not proceed.
Scenario 7 – Fail Initial Evaluation, Fail Extended Evaluation
-- In this case, the application fails one or more aspects of
the Initial Evaluation. The applicant requests Extended
Evaluation for the appropriate elements. However, the
application fails Extended Evaluation also. The application
does not proceed.
Scenario 8 – Extended Evaluation, Win Objection, Pass
Contention – In this case, the application fails one or more
aspects of the Initial Evaluation. The applicant is eligible for
and requests an Extended Evaluation for the appropriate
elements. Here, the application passes the Extended
Evaluation. During the objection filing period, an objection
is filed on one of the four enumerated grounds by an
objector with standing. The objection is heard by a dispute
resolution service provider panel that finds in favor of the
applicant. However, there are other applications for the
same or a similar gTLD string, so there is contention. In this
case, the applicant prevails over other applications in the
contention resolution procedure, the applicant can enter
into a registry agreement, and the application can
proceed toward delegation of the applied-for gTLD.
Scenario 9 – Extended Evaluation, Objection, Fail
Contention – In this case, the application fails one or more
aspects of the Initial Evaluation. The applicant is eligible for
and requests an Extended Evaluation for the appropriate Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-19
elements. Here, the application passes the Extended
Evaluation. During the objection filing period, an objection
is filed on one of the four enumerated grounds by an
objector with standing. The objection is heard by a dispute
resolution service provider that finds in favor of the
applicant. However, there are other applications for the
same or a similar gTLD string, so there is contention. In this
case, another applicant prevails in the contention
resolution procedure, and the application does not
proceed.
Transition to Delegation – After an application has
successfully completed Initial Evaluation, and other stages
as applicable, the applicant is required to complete a set
of steps leading to delegation of the gTLD, including
execution of a registry agreement with ICANN, and
completion of pre-delegation testing. Refer to Module 5 for
a description of the steps required in this stage.
1.1.6 Subsequent Application Rounds
ICANN’s goal is to launch subsequent gTLD application
rounds as quickly as possible. The exact timing will be
based on experiences gained and changes required after
this round is completed. The goal is for the next application
round to begin within one year of the close of the
application submission period for the initial round.
ICANN has committed to reviewing the effects of the New
gTLD Program on the operations of the root zone system
after the first application round, and will defer the
delegations in a second application round until it is
determined that the delegations resulting from the first
round did not jeopardize root zone system security or
stability.
1.2 Information for All Applicants
1.2.1 Eligibility
Established corporations, organizations, or institutions in
good standing may apply for a new gTLD. Applications
from individuals or sole proprietorships will not be
considered. Applications from or on behalf of yet-to-beformed legal entities, or applications presupposing the
future formation of a legal entity (for example, a pending
Joint Venture) will not be considered.  Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-20
ICANN has designed the New gTLD Program with multiple
stakeholder protection mechanisms. Background
screening, features of the gTLD Registry Agreement, data
and financial escrow mechanisms are all intended to
provide registrant and user protections.
The application form requires applicants to provide
information on the legal establishment of the applying
entity, as well as the identification of directors, officers,
partners, and major shareholders of that entity. The names
and positions of individuals included in the application will
be published as part of the application; other information
collected about the individuals will not be published.
Background screening at both the entity level and the
individual level will be conducted for all applications to
confirm eligibility. This inquiry is conducted on the basis of
the information provided in questions 1-11 of the
application form. ICANN may take into account
information received from any source if it is relevant to the
criteria in this section.  
ICANN will perform background screening in only two
areas: (1) General business diligence and criminal history;
and (2) History of cybersquatting behavior. The criteria
used for criminal history are aligned with the “crimes of
trust” standard sometimes used in the banking and finance
industry.  
In the absence of exceptional circumstances, applications
from any entity with or including any individual with
convictions or decisions of the types listed in (a) – (m)
below will be automatically disqualified from the program.
a. within the past ten years, has been
convicted of any crime related to financial
or corporate governance activities, or has
been judged by a court to have committed
fraud or breach of fiduciary duty, or has
been the subject of a judicial determination
that ICANN deems as the substantive
equivalent of any of these;
b. within the past ten years, has been
disciplined by any government or industry
regulatory body for conduct involving
dishonesty or misuse of the funds of others; Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-21
c. within the past ten years has been
convicted of any willful tax-related fraud or
willful evasion of tax liabilities;
d. within the past ten years has been
convicted of perjury, forswearing, failing to
cooperate with a law enforcement
investigation, or making false statements to
a law enforcement agency or
representative;
e. has ever been convicted of any crime
involving the use of computers, telephony
systems, telecommunications or the Internet
to facilitate the commission of crimes;
f. has ever been convicted of any crime
involving the use of a weapon, force, or the
threat of force;
g. has ever been convicted of any violent or
sexual offense victimizing children, the
elderly, or individuals with disabilities;
h. has ever been convicted of the illegal sale,
manufacture, or distribution of
pharmaceutical drugs, or been convicted
or successfully extradited for any offense
described in Article 3 of the United Nations
Convention Against Illicit Traffic in Narcotic
Drugs and Psychotropic Substances of
19884
;
i. has ever been convicted or successfully
extradited for any offense described in the
United Nations Convention against
Transnational Organized Crime (all
Protocols)5,6
;
j. has been convicted, within the respective
timeframes, of aiding, abetting, facilitating,
enabling, conspiring to commit, or failing to
report any of the listed crimes above (i.e.,
within the past 10 years for crimes listed in
                                                   
4
http://www.unodc.org/unodc/en/treaties/illicit-trafficking.html
5
http://www.unodc.org/unodc/en/treaties/CTOC/index.html
6
It is recognized that not all countries have signed on to the UN conventions referenced above. These conventions are being used
solely for identification of a list of crimes for which background screening will be performed. It is not necessarily required that an
applicant would have been convicted pursuant to the UN convention but merely convicted of a crime listed under these conventions,
to trigger these criteria.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-22
(a) - (d) above, or ever for the crimes listed
in (e) – (i) above);
k. has entered a guilty plea as part of a plea
agreement or has a court case in any
jurisdiction with a disposition of Adjudicated
Guilty or Adjudication Withheld (or regional
equivalents), within the respective
timeframes listed above for any of the listed
crimes (i.e., within the past 10 years for
crimes listed in (a) – (d) above, or ever for
the crimes listed in (e) – (i) above);
l. is the subject of a disqualification imposed
by ICANN and in effect at the time the
application is considered;
m. has been involved in a pattern of adverse,
final decisions indicating that the applicant
or individual named in the application was
engaged in cybersquatting as defined in
the Uniform Domain Name Dispute
Resolution Policy (UDRP), the AntiCybersquatting Consumer Protection Act
(ACPA), or other equivalent legislation, or
was engaged in reverse domain name
hijacking under the UDRP or bad faith or
reckless disregard under the ACPA or other
equivalent legislation. Three or more such
decisions with one occurring in the last four
years will generally be considered to
constitute a pattern.
n. fails to provide ICANN with the identifying
information necessary to confirm identity at
the time of application or to resolve
questions of identity during the background
screening process;
o. fails to provide a good faith effort to
disclose all relevant information relating to
items (a) – (m).
Background screening is in place to protect the public
interest in the allocation of critical Internet resources, and
ICANN reserves the right to deny an otherwise qualified
application based on any information identified during the
background screening process. For example, a final and
legally binding decision obtained by a national law
enforcement or consumer protection authority finding that
the applicant was engaged in fraudulent and deceptive Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-23
commercial practices as defined in the Organization for
Economic Co-operation and Development (OECD)
Guidelines for Protecting Consumers from Fraudulent and
Deceptive Commercial Practices Across Borders7 may
cause an application to be rejected. ICANN may also
contact the applicant with additional questions based on
information obtained in the background screening
process.
All applicants are required to provide complete and
detailed explanations regarding any of the above events
as part of the application. Background screening
information will not be made publicly available by ICANN.
Registrar Cross-Ownership -- ICANN-accredited registrars
are eligible to apply for a gTLD. However, all gTLD registries
are required to abide by a Code of Conduct addressing,
inter alia, non-discriminatory access for all authorized
registrars. ICANN reserves the right to refer any application
to the appropriate competition authority relative to any
cross-ownership issues.
Legal Compliance -- ICANN must comply with all U.S. laws,
rules, and regulations. One such set of regulations is the
economic and trade sanctions program administered by
the Office of Foreign Assets Control (OFAC) of the U.S.
Department of the Treasury. These sanctions have been
imposed on certain countries, as well as individuals and
entities that appear on OFAC's List of Specially Designated
Nationals and Blocked Persons (the SDN List). ICANN is
prohibited from providing most goods or services to
residents of sanctioned countries or their governmental
entities or to SDNs without an applicable U.S. government
authorization or exemption. ICANN generally will not seek a
license to provide goods or services to an individual or
entity on the SDN List. In the past, when ICANN has been
requested to provide services to individuals or entities that
are not SDNs, but are residents of sanctioned countries,
ICANN has sought and been granted licenses as required.
In any given case, however, OFAC could decide not to
issue a requested license.
1.2.2 Required Documents
All applicants should be prepared to submit the following
documents, which are required to accompany each
application:
                                                   
7
http://www.oecd.org/document/56/0,3746,en_2649_34267_2515000_1_1_1_1,00.htmlModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-24
1. Proof of legal establishment – Documentation of the
applicant’s establishment as a specific type of entity in
accordance with the applicable laws of its jurisdiction.
2. Financial statements. Applicants must provide audited
or independently certified financial statements for the
most recently completed fiscal year for the applicant.
In some cases, unaudited financial statements may be
provided.
Supporting documentation should be submitted in the
original language. English translations are not required.
All documents must be valid at the time of submission.
Refer to the Evaluation Criteria, attached to Module 2, for
additional details on the requirements for these
documents.
Some types of supporting documentation are required only
in certain cases:
1. Community endorsement – If an applicant has
designated its application as community-based (see
section 1.2.3), it will be asked to submit a written
endorsement of its application by one or more
established institutions representing the community it
has named. An applicant may submit written
endorsements from multiple institutions. If applicable,
this will be submitted in the section of the application
concerning the community-based designation.
At least one such endorsement is required for a
complete application. The form and content of the
endorsement are at the discretion of the party
providing the endorsement; however, the letter must
identify the applied-for gTLD string and the applying
entity, include an express statement of support for the
application, and supply the contact information of the
entity providing the endorsement.
Written endorsements from individuals need not be
submitted with the application, but may be submitted
in the application comment forum.
2. Government support or non-objection – If an applicant
has applied for a gTLD string that is a geographic name
(as defined in this Guidebook), the applicant is required
to submit documentation of support for or nonobjection to its application from the relevant
governments or public authorities. Refer to subsection
2.2.1.4 for more information on the requirements for
geographic names. If applicable, this will be submitted
in the geographic names section of the application.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-25
3. Documentation of third-party funding commitments – If
an applicant lists funding from third parties in its
application, it must provide evidence of commitment
by the party committing the funds. If applicable, this
will be submitted in the financial section of the
application.
1.2.3 Community-Based Designation
All applicants are required to designate whether their
application is community-based.
1.2.3.1 Definitions
For purposes of this Applicant Guidebook, a communitybased gTLD is a gTLD that is operated for the benefit of a
clearly delineated community. Designation or nondesignation of an application as community-based is
entirely at the discretion of the applicant. Any applicant
may designate its application as community-based;
however, each applicant making this designation is asked
to substantiate its status as representative of the
community it names in the application by submission of
written endorsements in support of the application.
Additional information may be requested in the event of a
community priority evaluation (refer to section 4.2 of
Module 4). An applicant for a community-based gTLD is
expected to:
1. Demonstrate an ongoing relationship with a clearly
delineated community.
2. Have applied for a gTLD string strongly and specifically
related to the community named in the application.
3. Have proposed dedicated registration and use policies
for registrants in its proposed gTLD, including
appropriate security verification procedures,
commensurate with the community-based purpose it
has named.
4. Have its application endorsed in writing by one or more
established institutions representing the community it
has named.
For purposes of differentiation, an application that has not
been designated as community-based will be referred to
hereinafter in this document as a standard application. A
standard gTLD can be used for any purpose consistent with
the requirements of the application and evaluation
criteria, and with the registry agreement. A standard
applicant may or may not have a formal relationship with
an exclusive registrant or user population. It may or may Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-26
not employ eligibility or use restrictions. Standard simply
means here that the applicant has not designated the
application as community-based.
1.2.3.2   Implications of Application Designation
Applicants should understand how their designation as
community-based or standard will affect application
processing at particular stages, and, if the application is
successful, execution of the registry agreement and
subsequent obligations as a gTLD registry operator, as
described in the following paragraphs.
Objection / Dispute Resolution – All applicants should
understand that a formal objection may be filed against
any application on community grounds, even if the
applicant has not designated itself as community-based or
declared the gTLD to be aimed at a particular community.
Refer to Module 3, Objection Procedures.
String Contention – Resolution of string contention may
include one or more components, depending on the
composition of the contention set and the elections made
by community-based applicants.
• A settlement between the parties can occur at any
time after contention is identified. The parties will be
encouraged to meet with an objective to settle the
contention. Applicants in contention always have
the opportunity to resolve the contention
voluntarily, resulting in the withdrawal of one or
more applications, before reaching the contention
resolution stage.
• A community priority evaluation will take place only
if a community-based applicant in a contention set
elects this option. All community-based applicants
in a contention set will be offered this option in the
event that there is contention remaining after the
applications have successfully completed all
previous evaluation stages.
• An auction will result for cases of contention not
resolved by community priority evaluation or
agreement between the parties. Auction occurs as
a contention resolution means of last resort. If a
community priority evaluation occurs but does not
produce a clear winner, an auction will take place
to resolve the contention.
Refer to Module 4, String Contention Procedures, for
detailed discussions of contention resolution procedures.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-27
Contract Execution and Post-Delegation – A communitybased applicant will be subject to certain post-delegation
contractual obligations to operate the gTLD in a manner
consistent with the restrictions associated with its
community-based designation. Material changes to the
contract, including changes to the community-based
nature of the gTLD and any associated provisions, may only
be made with ICANN’s approval. The determination of
whether to approve changes requested by the applicant
will be at ICANN’s discretion. Proposed criteria for
approving such changes are the subject of policy
discussions.
Community-based applications are intended to be a
narrow category, for applications where there are
unambiguous associations among the applicant, the
community served, and the applied-for gTLD string.
Evaluation of an applicant’s designation as communitybased will occur only in the event of a contention situation
that results in a community priority evaluation. However,
any applicant designating its application as communitybased will, if the application is approved, be bound by the
registry agreement to implement the community-based
restrictions it has specified in the application. This is true
even if there are no contending applicants.  
1.2.3.3 Changes to Application Designation
An applicant may not change its designation as standard
or community-based once it has submitted a gTLD
application for processing.
1.2.4 Notice concerning Technical Acceptance Issues
with New gTLDs
All applicants should be aware that approval of an
application and entry into a registry agreement with
ICANN do not guarantee that a new gTLD will immediately
function throughout the Internet. Past experience indicates
that network operators may not immediately fully support
new top-level domains, even when these domains have
been delegated in the DNS root zone, since third-party
software modification may be required and may not
happen immediately.
Similarly, software applications sometimes attempt to
validate domain names and may not recognize new or
unknown top-level domains. ICANN has no authority or
ability to require that software accept new top-level
domains, although it does prominently publicize which toplevel domains are valid and has developed a basic tool to Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-28
assist application providers in the use of current root-zone
data.
ICANN encourages applicants to familiarize themselves
with these issues and account for them in their startup and
launch plans. Successful applicants may find themselves
expending considerable efforts working with providers to
achieve acceptance of their new top-level domains.
Applicants should review
http://www.icann.org/en/topics/TLD-acceptance/ for
background. IDN applicants should also review the
material concerning experiences with IDN test strings in the
root zone (see http://idn.icann.org/).
1.2.5   Notice concerning TLD Delegations
ICANN is only able to create TLDs as delegations in the DNS
root zone, expressed using NS records with any
corresponding DS records and glue records. There is no
policy enabling ICANN to place TLDs as other DNS record
types (such as A, MX, or DNAME records) in the root zone.
1.2.6 Terms and Conditions
All applicants must agree to a standard set of Terms and
Conditions for the application process. The Terms and
Conditions are available in Module 6 of this guidebook.
1.2.7   Notice of Changes to Information
If at any time during the evaluation process information
previously submitted by an applicant becomes untrue or
inaccurate, the applicant must promptly notify ICANN via
submission of the appropriate forms. This includes
applicant-specific information such as changes in financial
position and changes in ownership or control of the
applicant.
ICANN reserves the right to require a re-evaluation of the
application in the event of a material change. This could
involve additional fees or evaluation in a subsequent
application round.
Failure to notify ICANN of any change in circumstances
that would render any information provided in the
application false or misleading may result in denial of the
application.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-29
1.2.8   Voluntary Designation for High Security
Zones
An ICANN stakeholder group has considered development
of a possible special designation for "High Security Zone
Top Level Domains” (“HSTLDs”). The group’s Final Report
can be found at http://www.icann.org/en/topics/newgtlds/hstld-final-report-11mar11-en.pdf.
The Final Report may be used to inform further work. ICANN
will support independent efforts toward developing
voluntary high-security TLD designations, which may be
available to gTLD applicants wishing to pursue such
designations.
1.2.9 Security and Stability
Root Zone Stability:  There has been significant study,
analysis, and consultation in preparation for launch of the
New gTLD Program, indicating that the addition of gTLDs to
the root zone will not negatively impact the security or
stability of the DNS.
It is estimated that 200-300 TLDs will be delegated annually,
and determined that in no case will more than 1000 new
gTLDs be added to the root zone in a year. The delegation
rate analysis, consultations with the technical community,
and anticipated normal operational upgrade cycles all
lead to the conclusion that the new gTLD delegations will
have no significant impact on the stability of the root
system. Modeling and reporting will continue during, and
after, the first application round so that root-scaling
discussions can continue and the delegation rates can be
managed as the program goes forward.
All applicants should be aware that delegation of any new
gTLDs is conditional on the continued absence of
significant negative impact on the security or stability of
the DNS and the root zone system (including the process
for delegating TLDs in the root zone). In the event that
there is a reported impact in this regard and processing of
applications is delayed, the applicants will be notified in an
orderly and timely manner.
1.2.10 Resources for Applicant Assistance
A variety of support resources are available to gTLD
applicants. For example, ICANN is establishing a means for
providing financial assistance to eligible applicants,
through a process independent of this Guidebook.  In
addition, ICANN will maintain a webpage as an Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-30
informational resource for applicants seeking assistance,
and organizations offering support. More information will
be available on ICANN’s website at
http://www.icann.org/en/topics/new-gtld-program.htm.8
1.2.11 Updates to the Applicant Guidebook
As approved by the ICANN Board of Directors, this
Guidebook forms the basis of the New gTLD Program.
ICANN reserves the right to make reasonable updates and
changes to the Applicant Guidebook at any time,
including as the possible result of new technical standards,
reference documents, or policies that might be adopted
during the course of the application process. Any such
updates or revisions will be posted on ICANN’s website.
1.3 Information for Internationalized
Domain Name Applicants
Some applied-for gTLD strings are expected to be
Internationalized Domain Names (IDNs). IDNs are domain
names including characters used in the local
representation of languages not written with the basic
Latin alphabet (a - z), European-Arabic digits (0 - 9), and
the hyphen (-). As described below, IDNs require the
insertion of A-labels into the DNS root zone.
1.3.1   IDN-Specific Requirements
An applicant for an IDN string must provide information
indicating compliance with the IDNA protocol and other
technical requirements. The IDNA protocol and its
documentation can be found at
http://icann.org/en/topics/idn/rfcs.htm.
Applicants must provide applied-for gTLD strings in the form
of both a U-label (the IDN TLD in local characters) and an
A-label.
An A-label is the ASCII form of an IDN label. Every IDN Alabel begins with the IDNA ACE prefix, “xn--”, followed by a
string that is a valid output of the Punycode algorithm,
making a maximum of 63 total ASCII characters in length.
The prefix and string together must conform to all
requirements for a label that can be stored in the DNS
including conformance to the LDH (host name) rule
described in RFC 1034, RFC 1123, and elsewhere.
                                                   
8
The Joint SO/AC New gTLD Applicant Support Working Group is currently developing recommendations for support resources that
may be available to gTLD applicants. Information on these resources will be published on the ICANN website once identified.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-31
A U-label is the Unicode form of an IDN label, which a user
expects to see displayed in applications.
For example, using the current IDN test string in Cyrillic
script, the U-label is <испытание> and the A-label is <xn--
80akhbyknj4f>. An A-label must be capable of being
produced by conversion from a U-label and a U-label must
be capable of being produced by conversion from an Alabel.
Applicants for IDN gTLDs will also be required to provide the
following at the time of the application:
1. Meaning or restatement of string in English. The
applicant will provide a short description of what the
string would mean or represent in English.
2. Language of label (ISO 639-1). The applicant will
specify the language of the applied-for gTLD string,
both according to the ISO codes for the representation
of names of languages, and in English.
3. Script of label (ISO 15924). The applicant will specify the
script of the applied-for gTLD string, both according to
the ISO codes for the representation of names of
scripts, and in English.
4. Unicode code points. The applicant will list all the code
points contained in the U-label according to its
Unicode form.
5. Applicants must further demonstrate that they have
made reasonable efforts to ensure that the encoded
IDN string does not cause any rendering or operational
problems. For example, problems have been identified
in strings with characters of mixed right-to-left and leftto-right directionality when numerals are adjacent to
the path separator (i.e., the dot).9
If an applicant is applying for a string with known issues,
it should document steps that will be taken to mitigate
these issues in applications. While it is not possible to
ensure that all rendering problems are avoided, it is
important that as many as possible are identified early
and that the potential registry operator is aware of
these issues. Applicants can become familiar with
these issues by understanding the IDNA protocol (see
http://www.icann.org/en/topics/idn/rfcs.htm), and by
active participation in the IDN wiki (see
http://idn.icann.org/) where some rendering problems
are demonstrated.
                                                   
9
See examples at http://stupid.domain.name/node/683Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-32
6. [Optional] - Representation of label in phonetic
alphabet. The applicant may choose to provide its
applied-for gTLD string notated according to the
International Phonetic Alphabet
(http://www.langsci.ucl.ac.uk/ipa/). Note that this
information will not be evaluated or scored.  The
information, if provided, will be used as a guide to
ICANN in responding to inquiries or speaking of the
application in public presentations.
1.3.2 IDN Tables
An IDN table provides the list of characters eligible for
registration in domain names according to the registry’s
policy. It identifies any multiple characters that are
considered equivalent for domain name registration
purposes (“variant characters”). Variant characters occur
where two or more characters can be used
interchangeably.
Examples of IDN tables can be found in the Internet
Assigned Numbers Authority (IANA) IDN Repository at
http://www.iana.org/procedures/idn-repository.html.
In the case of an application for an IDN gTLD, IDN tables
must be submitted for the language or script for the
applied-for gTLD string (the “top level tables”). IDN tables
must also be submitted for each language or script in
which the applicant intends to offer IDN registrations at the
second or lower levels.
Each applicant is responsible for developing its IDN Tables,
including specification of any variant characters. Tables
must comply with ICANN’s IDN Guidelines10
and any
updates thereto, including:
• Complying with IDN technical standards.
• Employing an inclusion-based approach (i.e., code
points not explicitly permitted by the registry are
prohibited).
• Defining variant characters.
• Excluding code points not permissible under the
guidelines, e.g., line-drawing symbols, pictographic
dingbats, structural punctuation marks.
• Developing tables and registration policies in
collaboration with relevant stakeholders to address
common issues.
                                                   
10
See http://www.icann.org/en/topics/idn/idn-guidelines-26apr07.pdfModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-33
• Depositing IDN tables with the IANA Repository for
IDN Practices (once the TLD is delegated).
An applicant’s IDN tables should help guard against user
confusion in the deployment of IDN gTLDs. Applicants are
strongly urged to consider specific linguistic and writing
system issues that may cause problems when characters
are used in domain names, as part of their work of defining
variant characters.
To avoid user confusion due to differing practices across
TLD registries, it is recommended that applicants
cooperate with TLD operators that offer domain name
registration with the same or visually similar characters.
As an example, languages or scripts are often shared
across geographic boundaries. In some cases, this can
cause confusion among the users of the corresponding
language or script communities. Visual confusion can also
exist in some instances between different scripts (for
example, Greek, Cyrillic and Latin).
Applicants will be asked to describe the process used in
developing the IDN tables submitted. ICANN may
compare an applicant’s IDN table with IDN tables for the
same languages or scripts that already exist in the IANA
repository or have been otherwise submitted to ICANN. If
there are inconsistencies that have not been explained in
the application, ICANN may ask the applicant to detail the
rationale for differences. For applicants that wish to
conduct and review such comparisons prior to submitting
a table to ICANN, a table comparison tool will be
available.
ICANN will accept the applicant’s IDN tables based on the
factors above.
Once the applied-for string has been delegated as a TLD in
the root zone, the applicant is required to submit IDN
tables for lodging in the IANA Repository of IDN Practices.
For additional information, see existing tables at
http://iana.org/domains/idn-tables/, and submission
guidelines at http://iana.org/procedures/idnrepository.html.  
1.3.3 IDN Variant TLDs
A variant TLD string results from the substitution of one or
more characters in the applied-for gTLD string with variant
characters based on the applicant’s top level tables.
Each application contains one applied-for gTLD string. The
applicant may also declare any variant strings for the TLDModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-34
in its application. However, no variant gTLD strings will be
delegated through the New gTLD Program until variant
management solutions are developed and
implemented.11
Declaring variant strings is informative only
and will not imply any right or claim to the declared variant
strings.
When a variant delegation process is established,
applicants may be required to submit additional
information such as implementation details for the variant
TLD management mechanism, and may need to
participate in a subsequent evaluation process, which
could contain additional fees and review steps.
The following scenarios are possible during the gTLD
evaluation process:
a. Applicant declares variant strings to the applied-for
gTLD string in its application. If the application is
successful, the applied-for gTLD string will be
delegated to the applicant. The declared variant
strings are noted for future reference. These
declared variant strings will not be delegated to
the applicant along with the applied-for gTLD string,
nor will the applicant have any right or claim to the
declared variant strings.
Variant strings listed in successful gTLD applications
will be tagged to the specific application and
added to a “Declared Variants List” that will be
available on ICANN’s website. A list of pending (i.e.,
declared) variant strings from the IDN ccTLD Fast
Track is available at
http://icann.org/en/topics/idn/fast-track/stringevaluation-completion-en.htm.
ICANN may perform independent analysis on the
declared variant strings, and will not necessarily
include all strings listed by the applicant on the
Declared Variants List.
b. Multiple applicants apply for strings that are
identified by ICANN as variants of one another.
These applications will be placed in a contention
set and will follow the contention resolution
procedures in Module 4.
                                                   
11
The ICANN Board directed that work be pursued on variant management in its resolution on 25 Sep 2010,
http://www.icann.org/en/minutes/resolutions-25sep10-en.htm#2.5.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-35
c. Applicant submits an application for a gTLD string
and does not indicate variants to the applied-for
gTLD string. ICANN will not identify variant strings
unless scenario (b) above occurs.
Each variant string declared in the application must also
conform to the string requirements in section 2.2.1.3.2.
Variant strings declared in the application will be reviewed
for consistency with the top-level tables submitted in the
application. Should any declared variant strings not be
based on use of variant characters according to the
submitted top-level tables, the applicant will be notified
and the declared string will no longer be considered part
of the application.
Declaration of variant strings in an application does not
provide the applicant any right or reservation to a
particular string. Variant strings on the Declared Variants
List may be subject to subsequent additional review per a
process and criteria to be defined.
It should be noted that while variants for second and
lower-level registrations are defined freely by the local
communities without any ICANN validation, there may be
specific rules and validation criteria specified for variant
strings to be allowed at the top level. It is expected that
the variant information provided by applicants in the first
application round will contribute to a better understanding
of the issues and assist in determining appropriate review
steps and fee levels going forward.
1.4 Submitting an Application
Applicants may complete the application form and submit
supporting documents using ICANN’s TLD Application
System (TAS). To access the system, each applicant must
first register as a TAS user.
As TAS users, applicants will be able to provide responses in
open text boxes and submit required supporting
documents as attachments. Restrictions on the size of
attachments as well as the file formats are included in the
instructions on the TAS site.
ICANN will not accept application forms or supporting
materials submitted through other means than TAS (that is,
hard copy, fax, email), unless such submission is in Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-36
accordance with specific instructions from ICANN to
applicants.
1.4.1 Accessing the TLD Application System
The TAS site will be accessible from the New gTLD
webpage (http://www.icann.org/en/topics/new-gtldprogram.htm), and will be highlighted in communications
regarding the opening of the application submission
period. Users of TAS will be expected to agree to a
standard set of terms of use including user rights,
obligations, and restrictions in relation to the use of the
system.  
1.4.1.1  User Registration
TAS user registration (creating a TAS user profile) requires
submission of preliminary information, which will be used to
validate the identity of the parties involved in the
application. An overview of the information collected in
the user registration process is below:
No. Questions
1 Full legal name of Applicant
2 Principal business address
3 Phone number of Applicant
4 Fax number of Applicant
5 Website or URL, if applicable
6
Primary Contact:  Name, Title, Address, Phone, Fax,
Email
7
Secondary Contact:  Name, Title, Address, Phone,
Fax, Email
8 Proof of legal establishment
9 Trading, subsidiary, or joint venture information
10
Business ID, Tax ID, VAT registration number, or
equivalent of Applicant
11
Applicant background:  previous convictions,
cybersquatting activities
12 Deposit payment confirmation and payer informationModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-37
A subset of identifying information will be collected from
the entity performing the user registration, in addition to the
applicant information listed above. The registered user
could be, for example, an agent, representative, or
employee who would be completing the application on
behalf of the applicant.
The registration process will require the user to request the
desired number of application slots. For example, a user
intending to submit five gTLD applications would complete
five application slot requests, and the system would assign
the user a unique ID number for each of the five
applications.
Users will also be required to submit a deposit of USD 5,000
per application slot. This deposit amount will be credited
against the evaluation fee for each application. The
deposit requirement is in place to help reduce the risk of
frivolous access to the online application system.
After completing the registration, TAS users will receive
access enabling them to enter the rest of the application
information into the system. Application slots will be
populated with the registration information provided by
the applicant, which may not ordinarily be changed once
slots have been assigned.
No new user registrations will be accepted after 23:59 UTC
29 March 2012.
ICANN will take commercially reasonable steps to protect
all applicant data submitted from unauthorized access,
but cannot warrant against the malicious acts of third
parties who may, through system corruption or other
means, gain unauthorized access to such data.
1.4.1.2 Application Form
Having obtained the requested application slots, the
applicant will complete the remaining application
questions.  An overview of the areas and questions
contained in the form is shown here:
No. Application and String Information
12
Payment confirmation for remaining evaluation fee
amount
13 Applied-for gTLD string
14 IDN string information, if applicableModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-38
15 IDN tables, if applicable
16
Mitigation of IDN operational or rendering problems,
if applicable
17
Representation of string in International Phonetic
Alphabet (Optional)
18 Mission/purpose of the TLD
19 Is the application for a community-based TLD?
20
If community based, describe elements of community
and proposed policies
21
Is the application for a geographic name?  If
geographic, documents of support required
22
Measures for protection of geographic names at
second level
23
Registry Services:  name and full description of all
registry services to be provided
Technical and Operational Questions (External)
24 Shared registration system (SRS) performance
25 EPP
26 Whois
27 Registration life cycle
28 Abuse prevention & mitigation
29 Rights protection mechanisms
30(a) Security
Technical and Operational Questions (Internal)
30(b) Security
31 Technical overview of proposed registry
32 Architecture
33 Database capabilities
34 Geographic diversityModule 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-39
35 DNS service compliance
36 IPv6 reachability
37 Data backup policies and procedures
38 Escrow
39 Registry continuity
40 Registry transition
41 Failover testing
42 Monitoring and fault escalation processes
43 DNSSEC
44 IDNs (Optional)
Financial Questions
45 Financial statements
46 Projections template:  costs and funding
47 Costs:  setup and operating
48 Funding and revenue
49 Contingency planning:  barriers, funds, volumes
50 Continuity:  continued operations instrument
1.4.2   Customer Service during the Application
Process
Assistance will be available to applicants throughout the
application process via the Applicant Service Center
(ASC). The ASC will be staffed with customer service agents
to answer questions relating to the New gTLD Program, the
application process, and TAS.
1.4.3 Backup Application Process
If the online application system is not available, ICANN will
provide alternative instructions for submitting applications.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-40
1.5 Fees and Payments
This section describes the fees to be paid by the applicant.
Payment instructions are also included here.
1.5.1 gTLD Evaluation Fee
The gTLD evaluation fee is required from all applicants. This
fee is in the amount of USD 185,000. The evaluation fee is
payable in the form of a 5,000 deposit submitted at the
time the user requests an application slot within TAS, and a
payment of the remaining 180,000 submitted with the full
application. ICANN will not begin its evaluation of an
application unless it has received the full gTLD evaluation
fee by 23:59 UTC 12 April 2012.
The gTLD evaluation fee is set to recover costs associated
with the new gTLD program. The fee is set to ensure that
the program is fully funded and revenue neutral and is not
subsidized by existing contributions from ICANN funding
sources, including generic TLD registries and registrars,
ccTLD contributions and RIR contributions.
The gTLD evaluation fee covers all required reviews in Initial
Evaluation and, in most cases, any required reviews in
Extended Evaluation. If an extended Registry Services
review takes place, an additional fee will be incurred for
this review (see section 1.5.2). There is no additional fee to
the applicant for Extended Evaluation for geographic
names, technical and operational, or financial reviews. The
evaluation fee also covers community priority evaluation
fees in cases where the applicant achieves a passing
score.
Refunds -- In certain cases, refunds of a portion of the
evaluation fee may be available for applications that are
withdrawn before the evaluation process is complete. An
applicant may request a refund at any time until it has
executed a registry agreement with ICANN. The amount of
the refund will depend on the point in the process at which
the withdrawal is requested, as follows:
Refund Available to
Applicant
Percentage of
Evaluation Fee
Amount of Refund
Within 21 calendar
days of a GAC Early
Warning
80% USD 148,000
After posting of
applications until
posting of Initial
Evaluation results
70% USD 130,000
After posting Initial  35% USD 65,000Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-41
Refund Available to
Applicant
Percentage of
Evaluation Fee
Amount of Refund
Evaluation results
After the applicant
has completed
Dispute Resolution,
Extended
Evaluation, or String
Contention
Resolution(s)
20% USD 37,000
After the applicant
has entered into a
registry agreement
with ICANN
None
Thus, any applicant that has not been successful is eligible
for at least a 20% refund of the evaluation fee if it
withdraws its application.
An applicant that wishes to withdraw an application must
initiate the process through TAS and submit the required
form to request a refund, including agreement to the terms
and conditions for withdrawal. Refunds will only be issued
to the organization that submitted the original payment. All
refunds are paid by wire transfer. Any bank transfer or
transaction fees incurred by ICANN will be deducted from
the amount paid.
Note on 2000 proof-of-concept round applicants --
Participants in ICANN’s proof-of-concept application
process in 2000 may be eligible for a credit toward the
evaluation fee. The credit is in the amount of USD 86,000
and is subject to:
• submission of documentary proof by the
applicant that it is the same entity, a
successor in interest to the same entity, or
an affiliate of the same entity that applied
previously;
• a confirmation that the applicant was not
awarded any TLD string pursuant to the 2000
proof–of-concept application round and
that the applicant has no legal claims
arising from the 2000 proof-of-concept
process; and
• submission of an application, which may be
modified from the application originally
submitted in 2000, for the same TLD string Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-42
that such entity applied for in the 2000
proof-of-concept application round.
Each participant in the 2000 proof-of-concept application
process is eligible for at most one credit. A maximum of
one credit may be claimed for any new gTLD application
submitted according to the process in this guidebook.
Eligibility for this credit is determined by ICANN.
1.5.2 Fees Required in Some Cases
Applicants may be required to pay additional fees in
certain cases where specialized process steps are
applicable. Those possible additional fees12
include:
• Registry Services Review Fee – If applicable, this fee
is payable for additional costs incurred in referring
an application to the Registry Services Technical
Evaluation Panel (RSTEP) for an extended review.
Applicants will be notified if such a fee is due. The
fee for a three-member RSTEP review team is
anticipated to be USD 50,000. In some cases, fivemember panels might be required, or there might
be increased scrutiny at a greater cost. The amount
of the fee will cover the cost of the RSTEP review. In
the event that reviews of proposed registry services
can be consolidated across multiple applications
or applicants, ICANN will apportion the fees in an
equitable manner. In every case, the applicant will
be advised of the cost before initiation of the
review. Refer to subsection 2.2.3 of Module 2 on
Registry Services review.
• Dispute Resolution Filing Fee – This amount must
accompany any filing of a formal objection and
any response that an applicant files to an
objection. This fee is payable directly to the
applicable dispute resolution service provider in
accordance with the provider’s payment
instructions. ICANN estimates that filing fees could
range from approximately USD 1,000 to USD 5,000
(or more) per party per proceeding. Refer to the
appropriate provider for the relevant amount. Refer
to Module 3 for dispute resolution procedures.
• Advance Payment of Costs – In the event of a
formal objection, this amount is payable directly to
the applicable dispute resolution service provider in
                                                   
12
The estimated fee amounts provided in this section 1.5.2 will be updated upon engagement of panel service providers and
establishment of fees.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-43
accordance with that provider’s procedures and
schedule of costs. Ordinarily, both parties in the
dispute resolution proceeding will be required to
submit an advance payment of costs in an
estimated amount to cover the entire cost of the
proceeding. This may be either an hourly fee based
on the estimated number of hours the panelists will
spend on the case (including review of submissions,
facilitation of a hearing, if allowed, and preparation
of a decision), or a fixed amount. In cases where
disputes are consolidated and there are more than
two parties involved, the advance payment will
occur according to the dispute resolution service
provider’s rules.
The prevailing party in a dispute resolution
proceeding will have its advance payment
refunded, while the non-prevailing party will not
receive a refund and thus will bear the cost of the
proceeding. In cases where disputes are
consolidated and there are more than two parties
involved, the refund of fees will occur according to
the dispute resolution service provider’s rules.
ICANN estimates that adjudication fees for a
proceeding involving a fixed amount could range
from USD 2,000 to USD 8,000 (or more) per
proceeding. ICANN further estimates that an hourly
rate based proceeding with a one-member panel
could range from USD 32,000 to USD 56,000 (or
more) and with a three-member panel it could
range from USD 70,000 to USD 122,000 (or more).
These estimates may be lower if the panel does not
call for written submissions beyond the objection
and response, and does not allow a hearing.
Please refer to the appropriate provider for the
relevant amounts or fee structures.
• Community Priority Evaluation Fee – In the event
that the applicant participates in a community
priority evaluation, this fee is payable as a deposit
in an amount to cover the cost of the panel’s
review of that application (currently estimated at
USD 10,000). The deposit is payable to the provider
appointed to handle community priority
evaluations. Applicants will be notified if such a fee
is due. Refer to Section 4.2 of Module 4 for
circumstances in which a community priority
evaluation may take place. An applicant who Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-44
scores at or above the threshold for the community
priority evaluation will have its deposit refunded.
ICANN will notify the applicants of due dates for payment
in respect of additional fees (if applicable). This list does not
include fees (annual registry fees) that will be payable to
ICANN following execution of a registry agreement.
1.5.3 Payment Methods
Payments to ICANN should be submitted by wire transfer.
Instructions for making a payment by wire transfer will be
available in TAS.13
Payments to Dispute Resolution Service Providers should be
submitted in accordance with the provider’s instructions.
1.5.4 Requesting a Remittance Form
The TAS interface allows applicants to request issuance of
a remittance form for any of the fees payable to ICANN.
This service is for the convenience of applicants that
require an invoice to process payments.
1.6 Questions about this Applicant
Guidebook
For assistance and questions an applicant may have in the
process of completing the application form, applicants
should use the customer support resources available via
the ASC. Applicants who are unsure of the information
being sought in a question or the parameters for
acceptable documentation are encouraged to
communicate these questions through the appropriate
support channels before the application is submitted. This
helps avoid the need for exchanges with evaluators to
clarify information, which extends the timeframe
associated with processing the application.
Currently, questions may be submitted via
<newgtld@icann.org>. To provide all applicants equitable
access to information, ICANN will make all questions and
answers publicly available.
All requests to ICANN for information about the process or
issues surrounding preparation of an application must be
submitted to the ASC. ICANN will not grant requests from
applicants for personal or telephone consultations
                                                   
13
Wire transfer is the preferred method of payment as it offers a globally accessible and dependable means for international
transfer of funds. This enables ICANN to receive the fee and begin processing applications as quickly as possible.Module 1
Introduction to the gTLD Application Process
Applicant Guidebook | version 2011-09-19
1-45
regarding the preparation of an application. Applicants
that contact ICANN for clarification about aspects of the
application will be referred to the ASC.
Answers to inquiries will only provide clarification about the
application forms and procedures. ICANN will not provide
consulting, financial, or legal advice.Applicants
submit
applications and
evaluation fees
DRAFT - New gTLD Program - Evaluation Process
DNS Stability
String
Similarity
Geographic
Names
Financial
Capability
Technical &
Operational
Capability
Registry
Services
Application ‐ Module 1
Initial Evaluation ‐ Module 2
Extended Evauation ‐ Module 2
Dispute Resolution Proceedings ‐
Module 3
String Contention ‐ Module 4
Transition to Delegation ‐ Module 5
Thicker
Line
Indicates quickest path to delegation
Key
Application period
opens
Applicants
register in TAS
and pay deposit
Application period closes
IE results posted
A
ICANN posts
applications
- Objection filing period closes
- Receipt of GAC Advice expected
Background
Screening
Is applicant
subject to GAC
Advice?
Board
Consideration
No
Yes
- Application Comment & Early Warning
Periods Open - 60 days
- Objection Period Opens - 7 months
Applicant
receives Early
Warning?
Applicant
decision?
Ineligible for further
review
Yes Withdraw
Continue
Applicants have 21 days from close of
Early Warning Period to decide.
No
Application Comment & Early
Warning Periods Close
ICANN starts
Administrative
Completeness
Check
ICANN ends
Administrative
Completeness
CheckIneligible for further
review
Are there any
objections?
Applicant passes
all elements of Extended
Evaluation?
Is there string
contention?
One or more communitybased applicant(s) elected
Community Priority?
Successful
applicant secures
string
Is there a clear
winner?
No
No
Delegation
Does applicant clear all
objections?
Yes
No
No Yes
Applicant elects to
proceed to Extended
Evaluation (EE)
No
No
Yes
No
The application can be
objected to based upon any
combination of the four
objection grounds at the
same time. Additionally, the
application may face multiple
objections on the same
objection ground.
Are applicants with
contending strings able to
self-resolve contention?
Yes
No Yes
Yes
Applicant passes all elements
of Initial Evaluation?
Yes
String
Confusion
proceedings
Legal Rights
proceedings
Community
Objection
proceedings
Limited Public
Interest
proceedings
Applicant enters EE for any
combination of the four
elements below:
Technical & Operational
Financial
Geographic Names
Registry Services
Community
Priority
Evaluation
Auction
proceedings
Contract
execution
Predelegation
check
Extended Evaluation and
Dispute Resolution will run
concurrently
A
DRAFT - New gTLD Program - Evaluation
Process, Page 2
No
YesgTLD Applicant
Guidebook
(v. 2011-09-19)
Module 2
19 September 2011Applicant Guidebook | version 2011-09-19
                                                 
2-1
Module 2
Evaluation Procedures
This module describes the evaluation procedures and
criteria used to determine whether applied-for gTLDs are
approved for delegation. All applicants will undergo an
Initial Evaluation and those that do not pass all elements
may request Extended Evaluation.
The first, required evaluation is the Initial Evaluation, during
which ICANN assesses an applied-for gTLD string, an
applicant’s qualifications, and its proposed registry
services.
The following assessments are performed in the Initial
Evaluation:
• String Reviews
 String similarity
 Reserved names
 DNS stability
 Geographic names
• Applicant Reviews
 Demonstration of technical and operational
capability
 Demonstration of financial capability
 Registry services reviews for DNS stability issues
An application must pass all these reviews to pass the Initial
Evaluation. Failure to pass any one of these reviews will
result in a failure to pass the Initial Evaluation.
Extended Evaluation may be applicable in cases in which
an applicant does not pass the Initial Evaluation.  See
Section 2.3 below.
2.1  Background Screening
Background screening will be conducted in two areas:
(a) General business diligence and criminal history; and
(b) History of cybersquatting behavior.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-2
The application must pass both background screening
areas to be eligible to proceed. Background screening
results are evaluated according to the criteria described in
section 1.2.1. Due to the potential sensitive nature of the
material, applicant background screening reports will not
be published.
The following sections describe the process ICANN will use
to perform background screening.
2.1.1 General business diligence and criminal
history
Applying entities that are publicly traded corporations
listed and in good standing on any of the world’s largest 25
stock exchanges (as listed by the World Federation of
Exchanges) will be deemed to have passed the general
business diligence and criminal history screening. The
largest 25 will be based on the domestic market
capitalization reported at the end of the most recent
calendar year prior to launching each round.
1
 
Before an entity is listed on an exchange, it must undergo
significant due diligence including an investigation by the
exchange, regulators, and investment banks. As a publicly
listed corporation, an entity is subject to ongoing scrutiny
from shareholders, analysts, regulators, and exchanges. All
exchanges require monitoring and disclosure of material
information about directors, officers, and other key
personnel, including criminal behavior. In totality, these
requirements meet or exceed the screening ICANN will
perform.
For applicants not listed on one of these exchanges,
ICANN will submit identifying information for the entity,
officers, directors, and major shareholders to an
international background screening service. The service
provider(s) will use the criteria listed in section 1.2.1 and
return results that match these criteria. Only publicly
available information will be used in this inquiry.
ICANN is in discussions with INTERPOL to identify ways in
which both organizations can collaborate in background
screenings of individuals, entities and their identity
documents consistent with both organizations’ rules and
regulations. Note that the applicant is expected to disclose
potential problems in meeting the criteria in the
application, and provide any clarification or explanation at
the time of application submission. Results returned from
                                                         
1
See http://www.world-exchanges.org/statistics/annual/2010/equity-markets/domestic-market-capitalizationModule 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-3
the background screening process will be matched with
the disclosures provided by the applicant and those cases
will be followed up to resolve issues of discrepancies or
potential false positives.
If no hits are returned, the application will generally pass
this portion of the background screening.
2.1.2 History of cybersquatting
ICANN will screen applicants against UDRP cases and legal
databases as financially feasible for data that may
indicate a pattern of cybersquatting behavior pursuant to
the criteria listed in section 1.2.1.  
The applicant is required to make specific declarations
regarding these activities in the application. Results
returned during the screening process will be matched with
the disclosures provided by the applicant and those
instances will be followed up to resolve issues of
discrepancies or potential false positives.
If no hits are returned, the application will generally pass
this portion of the background screening.
2.2 Initial Evaluation
The Initial Evaluation consists of two types of review. Each
type is composed of several elements.
String review:  The first review focuses on the applied-for
gTLD string to test:
• Whether the applied-for gTLD string is so similar to
other strings that it would create a probability of
user confusion;
• Whether the applied-for gTLD string might adversely
affect DNS security or stability; and
• Whether evidence of requisite government
approval is provided in the case of certain
geographic names.
Applicant review:  The second review focuses on the
applicant to test:
• Whether the applicant has the requisite technical,
operational, and financial capability to operate a
registry; and
• Whether the registry services offered by the
applicant might adversely affect DNS security or
stability.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-4
2.2.1 String Reviews
In the Initial Evaluation, ICANN reviews every applied-for
gTLD string. Those reviews are described in greater detail in
the following subsections.
2.2.1.1 String Similarity Review
This review involves a preliminary comparison of each
applied-for gTLD string against existing TLDs, Reserved
Names (see subsection 2.2.1.2), and other applied-for
strings. The objective of this review is to prevent user
confusion and loss of confidence in the DNS resulting from
delegation of many similar strings.
Note:  In this Applicant Guidebook, “similar” means strings
so similar that they create a probability of user confusion if
more than one of the strings is delegated into the root
zone.
The visual similarity check that occurs during Initial
Evaluation is intended to augment the objection and
dispute resolution process (see Module 3, Dispute
Resolution Procedures) that addresses all types of similarity.
This similarity review will be conducted by an independent
String Similarity Panel.
2.2.1.1.1 Reviews Performed
The String Similarity Panel’s task is to identify visual string
similarities that would create a probability of user
confusion.
The panel performs this task of assessing similarities that
would lead to user confusion in four sets of circumstances,
when comparing:
• Applied-for gTLD strings against existing TLDs and
reserved names;
• Applied-for gTLD strings against other applied-for
gTLD strings;
• Applied-for gTLD strings against strings requested as
IDN ccTLDs; and
• Applied-for 2-character IDN gTLD strings against:
o Every other single character.
o Any other 2-character ASCII string (to
protect possible future ccTLD delegations).Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-5
Similarity to Existing TLDs or Reserved Names – This review
involves cross-checking between each applied-for string
and the lists of existing TLD strings and Reserved Names to
determine whether two strings are so similar to one another
that they create a probability of user confusion.
In the simple case in which an applied-for gTLD string is
identical to an existing TLD or reserved name, the online
application system will not allow the application to be
submitted.
Testing for identical strings also takes into consideration the
code point variants listed in any relevant IDN table. For
example, protocols treat equivalent labels as alternative
forms of the same label, just as “foo” and “Foo” are
treated as alternative forms of the same label (RFC 3490).
All TLDs currently in the root zone can be found at
http://iana.org/domains/root/db/.
IDN tables that have been submitted to ICANN are
available at http://www.iana.org/domains/idn-tables/.
Similarity to Other Applied-for gTLD Strings (String
Contention Sets) – All applied-for gTLD strings will be
reviewed against one another to identify any similar strings.
In performing this review, the String Similarity Panel will
create contention sets that may be used in later stages of
evaluation.
A contention set contains at least two applied-for strings
identical or similar to one another. Refer to Module 4, String
Contention Procedures, for more information on contention
sets and contention resolution.
ICANN will notify applicants who are part of a contention
set as soon as the String Similarity review is completed. (This
provides a longer period for contending applicants to
reach their own resolution before reaching the contention
resolution stage.) These contention sets will also be
published on ICANN’s website.
Similarity to TLD strings requested as IDN ccTLDs -- Appliedfor gTLD strings will also be reviewed for similarity to TLD
strings requested in the IDN ccTLD Fast Track process (see
http://www.icann.org/en/topics/idn/fast-track/). Should a
conflict with a prospective fast-track IDN ccTLD be
identified, ICANN will take the following approach to
resolving the conflict.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-6
If one of the applications has completed its respective
process before the other is lodged, that TLD will be
delegated. A gTLD application that has successfully
completed all relevant evaluation stages, including dispute
resolution and string contention, if applicable, and is
eligible for entry into a registry agreement will be
considered complete, and therefore would not be
disqualified by a newly-filed IDN ccTLD request. Similarly, an
IDN ccTLD request that has completed evaluation (i.e., is
validated) will be considered complete and therefore
would not be disqualified by a newly-filed gTLD
application.
In the case where neither application has completed its
respective process, where the gTLD application does not
have the required approval from the relevant government
or public authority, a validated request for an IDN ccTLD
will prevail and the gTLD application will not be approved.
The term “validated” is defined in the IDN ccTLD Fast Track
Process Implementation, which can be found at
http://www.icann.org/en/topics/idn.
In the case where a gTLD applicant has obtained the
support or non-objection of the relevant government or
public authority, but is eliminated due to contention with a
string requested in the IDN ccTLD Fast Track process, a full
refund of the evaluation fee is available to the applicant if
the gTLD application was submitted prior to the publication
of the ccTLD request.
Review of 2-character IDN strings — In addition to the
above reviews, an applied-for gTLD string that is a 2-
character IDN string is reviewed by the String Similarity
Panel for visual similarity to:
a) Any one-character label (in any script), and
b) Any possible two-character ASCII combination.
An applied-for gTLD string that is found to be too similar to
a) or b) above will not pass this review.
2.2.1.1.2   Review Methodology
The String Similarity Panel is informed in part by an
algorithmic score for the visual similarity between each
applied-for string and each of other existing and appliedfor TLDs and reserved names. The score will provide one
objective measure for consideration by the panel, as part
of the process of identifying strings likely to result in user
confusion. In general, applicants should expect that a
higher visual similarity score suggests a higher probability Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-7
that the application will not pass the String Similarity review.
However, it should be noted that the score is only
indicative and that the final determination of similarity is
entirely up to the Panel’s judgment.
The algorithm, user guidelines, and additional background
information are available to applicants for testing and
informational purposes.
2
Applicants will have the ability to
test their strings and obtain algorithmic results through the
application system prior to submission of an application.
The algorithm supports the common characters in Arabic,
Chinese, Cyrillic, Devanagari, Greek, Japanese, Korean,
and Latin scripts. It can also compare strings in different
scripts to each other.
The panel will also take into account variant characters, as
defined in any relevant language table, in its
determinations. For example, strings that are not visually
similar but are determined to be variant TLD strings based
on an IDN table would be placed in a contention set.
Variant TLD strings that are listed as part of the application
will also be subject to the string similarity analysis.
3
The panel will examine all the algorithm data and perform
its own review of similarities between strings and whether
they rise to the level of string confusion. In cases of strings in
scripts not yet supported by the algorithm, the panel’s
assessment process is entirely manual.
The panel will use a common standard to test for whether
string confusion exists, as follows:
Standard for String Confusion – String confusion exists where
a string so nearly resembles another visually that it is likely to
deceive or cause confusion. For the likelihood of confusion
to exist, it must be probable, not merely possible that
confusion will arise in the mind of the average, reasonable
Internet user. Mere association, in the sense that the string
brings another string to mind, is insufficient to find a
likelihood of confusion.
2.2.1.1.3  Outcomes of the String Similarity Review
An application that fails the String Similarity review due to
similarity to an existing TLD will not pass the Initial Evaluation,
                                                         
2
See http://icann.sword-group.com/algorithm/
3
In the case where an applicant has listed Declared Variants in its application (see subsection 1.3.3), the panel will perform an
analysis of the listed strings to confirm that the strings are variants according to the applicant’s IDN table. This analysis may
include comparison of applicant IDN tables with other existing tables for the same language or script, and forwarding any questions
to the applicant.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-8
and no further reviews will be available. Where an
application does not pass the String Similarity review, the
applicant will be notified as soon as the review is
completed.
An application for a string that is found too similar to
another applied-for gTLD string will be placed in a
contention set.
An application that passes the String Similarity review is still
subject to objection by an existing TLD operator or by
another gTLD applicant in the current application round.
That process requires that a string confusion objection be
filed by an objector having the standing to make such an
objection. Such category of objection is not limited to
visual similarity. Rather, confusion based on any type of
similarity (including visual, aural, or similarity of meaning)
may be claimed by an objector. Refer to Module 3,
Dispute Resolution Procedures, for more information about
the objection process.
An applicant may file a formal objection against another
gTLD application on string confusion grounds. Such an
objection may, if successful, change the configuration of
the preliminary contention sets in that the two applied-for
gTLD strings will be considered in direct contention with one
another (see Module 4, String Contention Procedures). The
objection process will not result in removal of an
application from a contention set.
2.2.1.2 Reserved Names and Other Unavailable
Strings
Certain names are not available as gTLD strings, as
detailed in this section.
2.2.1.2.1 Reserved Names
All applied-for gTLD strings are compared with the list of
top-level Reserved Names to ensure that the applied-for
gTLD string does not appear on that list.
Top-Level Reserved Names List
AFRINIC IANA-SERVERS NRO
ALAC ICANN RFC-EDITOR
APNIC IESG RIPE
ARIN IETF ROOT-SERVERS
ASO INTERNIC RSSAC
CCNSO INVALID SSAC
EXAMPLE* IRTF TEST*
GAC ISTF TLDModule 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-9
GNSO LACNIC WHOIS
GTLD-SERVERS LOCAL WWW
IAB LOCALHOST
IANA NIC
*Note that in addition to the above strings, ICANN will reserve translations of the terms
“test” and “example” in multiple languages.  The remainder of the strings are reserved
only in the form included above.
If an applicant enters a Reserved Name as its applied-for
gTLD string, the application system will recognize the
Reserved Name and will not allow the application to be
submitted.
In addition, applied-for gTLD strings are reviewed during
the String Similarity review to determine whether they are
similar to a Reserved Name. An application for a gTLD
string that is identified as too similar to a Reserved Name
will not pass this review.
2.2.1.2.2 Declared Variants
Names appearing on the Declared Variants List (see
section 1.3.3) will be posted on ICANN’s website and will be
treated essentially the same as Reserved Names, until such
time as variant management solutions are developed and
variant TLDs are delegated. That is, an application for a
gTLD string that is identical or similar to a string on the
Declared Variants List will not pass this review.
2.2.1.2.3 Strings Ineligible for Delegation
The following names are prohibited from delegation as
gTLDs in the initial application round.  Future application
rounds may differ according to consideration of further
policy advice.
These names are not being placed on the Top-Level
Reserved Names List, and thus are not part of the string
similarity review conducted for names on that list. Refer to
subsection 2.2.1.1:  where applied-for gTLD strings are
reviewed for similarity to existing TLDs and reserved names,
the strings listed in this section are not reserved names and
accordingly are not incorporated into this review.
Applications for names appearing on the list included in
this section will not be approved.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-10
International Olympic Committee
OLYMPIC OLYMPIAD OLYMPIQUE
OLYMPIADE OLYMPISCH OLÍMPICO
أوﻟﻴﻤﺒﻴﺎد أوﻟﻴﻤﺒﻲ OLIMPÍADA
奥林匹克 奥林匹亚 奧林匹克
奧林匹亞 Ολυμπιακοί Ολυμπιάδα
올림픽 올림피아드 Олимпийский
Олимпиада
International Red Cross and Red Crescent Movement 1B
REDCROSS REDCRESCENT REDCRYSTAL
REDLIONANDSUN MAGENDDAVIDADOM REDSTAROFDAVID
CROIXROUGE CROIX-ROUGE CROISSANTROUGE
CROISSANT-ROUGE CRISTALROUGE CRISTAL-ROUGE
CRUZROJA MEDIALUNAROJA מגן דוד אדום
CRISTALROJO Красный Крест Красный Полумесяц
لالهلا رمحألا رمحألا بيلصلا Красный Кристалл
紅十字 اﻟﻛرﻳﺳﺗﺎﻟﺔ اﻟﺣﻣراء ءارمحلا ةرولبلا
红十字 紅新月 红新月
紅水晶 红水晶
2.2.1.3 DNS Stability Review
This review determines whether an applied-for gTLD string
might cause instability to the DNS. In all cases, this will
involve a review for conformance with technical and other
requirements for gTLD strings (labels). In some exceptional
cases, an extended review may be necessary to
investigate possible technical stability problems with the
applied-for gTLD string.
Note:  All applicants should recognize issues surrounding
invalid TLD queries at the root level of the DNS.  Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-11
Any new TLD registry operator may experience
unanticipated queries, and some TLDs may experience a
non-trivial load of unanticipated queries. For more
information, see the Security and Stability Advisory
Committee (SSAC)’s report on this topic at
http://www.icann.org/en/committees/security/sac045.pdf.
Some publicly available statistics are also available at
http://stats.l.root-servers.org/.
ICANN will take steps to alert applicants of the issues raised
in SAC045, and encourage the applicant to prepare to
minimize the possibility of operational difficulties that would
pose a stability or availability problem for its registrants and
users. However, this notice is merely an advisory to
applicants and is not part of the evaluation, unless the
string raises significant security or stability issues as
described in the following section.
2.2.1.3.1 DNS Stability: String Review Procedure
New gTLD labels must not adversely affect the security or
stability of the DNS. During the Initial Evaluation period,
ICANN will conduct a preliminary review on the set of
applied-for gTLD strings to:
• ensure that applied-for gTLD strings comply with the
requirements provided in section 2.2.1.3.2, and
• determine whether any strings raise significant
security or stability issues that may require further
review.
There is a very low probability that extended analysis will be
necessary for a string that fully complies with the string
requirements in subsection 2.2.1.3.2 of this module.
However, the string review process provides an additional
safeguard if unanticipated security or stability issues arise
concerning an applied-for gTLD string.
In such a case, the DNS Stability Panel will perform an
extended review of the applied-for gTLD string during the
Initial Evaluation period. The panel will determine whether
the string fails to comply with relevant standards or creates
a condition that adversely affects the throughput, response
time, consistency, or coherence of responses to Internet
servers or end systems, and will report on its findings.
If the panel determines that the string complies with
relevant standards and does not create the conditions
described above, the application will pass the DNS Stability
review.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-12
If the panel determines that the string does not comply
with relevant technical standards, or that it creates a
condition that adversely affects the throughput, response
time, consistency, or coherence of responses to Internet
servers or end systems, the application will not pass the
Initial Evaluation, and no further reviews are available. In
the case where a string is determined likely to cause
security or stability problems in the DNS, the applicant will
be notified as soon as the DNS Stability review is
completed.
2.2.1.3.2 String Requirements
ICANN will review each applied-for gTLD string to ensure
that it complies with the requirements outlined in the
following paragraphs.
If an applied-for gTLD string is found to violate any of these
rules, the application will not pass the DNS Stability review.
No further reviews are available.
Part I -- Technical Requirements for all Labels (Strings) – The
technical requirements for top-level domain labels follow.
1.1   The ASCII label (i.e., the label as transmitted on the
wire) must be valid as specified in technical
standards Domain Names: Implementation and
Specification (RFC 1035), and Clarifications to the
DNS Specification (RFC 2181) and any updates
thereto. This includes the following:
1.1.1 The label must have no more than 63
characters.
1.1.2 Upper and lower case characters are
treated as identical.
1.2 The ASCII label must be a valid host name, as
specified in the technical standards DOD Internet
Host Table Specification (RFC 952), Requirements for
Internet Hosts — Application and Support (RFC
1123), and Application Techniques for Checking
and Transformation of Names (RFC 3696),
Internationalized Domain Names in Applications
(IDNA)(RFCs 5890-5894), and any updates thereto.
This includes the following:
1.2.1 The ASCII label must consist entirely of letters
(alphabetic characters a-z), or
1.2.2 The label must be a valid IDNA A-label
(further restricted as described in Part II
below).Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-13
Part II -- Requirements for Internationalized Domain Names
– These requirements apply only to prospective top-level
domains that contain non-ASCII characters. Applicants for
these internationalized top-level domain labels are
expected to be familiar with the Internet Engineering Task
Force (IETF) IDNA standards, Unicode standards, and the
terminology associated with Internationalized Domain
Names.
2.1 The label must be an A-label as defined in IDNA,
converted from (and convertible to) a U-label that
is consistent with the definition in IDNA, and further
restricted by the following, non-exhaustive, list of
limitations:
2.1.1 Must be a valid A-label according to IDNA.
2.1.2 The derived property value of all codepoints
used in the U-label, as defined by IDNA,
must be PVALID or CONTEXT (accompanied
by unambiguous contextual rules).
4
2.1.3 The general category of all codepoints, as
defined by IDNA, must be one of (Ll, Lo, Lm,
Mn).
2.1.4 The U-label must be fully compliant with
Normalization Form C, as described in
Unicode Standard Annex #15: Unicode
Normalization Forms.  See also examples in
http://unicode.org/faq/normalization.html.
2.1.5 The U-label must consist entirely of
characters with the same directional
property, or fulfill the requirements of the Bidi
rule per RFC 5893.
2.2 The label must meet the relevant criteria of the
ICANN Guidelines for the Implementation of
Internationalised Domain Names. See
http://www.icann.org/en/topics/idn/implementatio
n-guidelines.htm. This includes the following, nonexhaustive, list of limitations:
                                                         
4
It is expected that conversion tools for IDNA will be available before the Application Submission period begins, and that labels will
be checked for validity under IDNA. In this case, labels valid under the previous version of the protocol (IDNA2003) but not under
IDNA will not meet this element of the requirements. Labels that are valid under both versions of the protocol will meet this element
of the requirements. Labels valid under IDNA but not under IDNA2003 may meet the requirements; however, applicants are
strongly advised to note that the duration of the transition period between the two protocols cannot presently be estimated nor
guaranteed in any specific timeframe. The development of support for IDNA in the broader software applications environment will
occur gradually. During that time, TLD labels that are valid under IDNA, but not under IDNA2003, will have limited functionality. Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-14
2.2.1 All code points in a single label must be
taken from the same script as determined
by the Unicode Standard Annex #24:
Unicode Script Property.
2.2.2 Exceptions to 2.2.1 are permissible for
languages with established orthographies
and conventions that require the
commingled use of multiple scripts.
However, even with this exception, visually
confusable characters from different scripts
will not be allowed to co-exist in a single set
of permissible code points unless a
corresponding policy and character table
are clearly defined.
Part III - Policy Requirements for Generic Top-Level
Domains – These requirements apply to all prospective toplevel domain strings applied for as gTLDs.
3.1  Applied-for gTLD strings in ASCII must be composed
of three or more visually distinct characters. Twocharacter ASCII strings are not permitted, to avoid
conflicting with current and future country codes
based on the ISO 3166-1 standard.
3.2  Applied-for gTLD strings in IDN scripts must be
composed of two or more visually distinct
characters in the script, as appropriate.
5
Note,
however, that a two-character IDN string will not be
approved if:
3.2.1 It is visually similar to any one-character
label (in any script); or
3.2.2 It is visually similar to any possible twocharacter ASCII combination.
See the String Similarity review in subsection 2.2.1.1
for additional information on this requirement.
2.2.1.4 Geographic Names Review
Applications for gTLD strings must ensure that appropriate
consideration is given to the interests of governments or
public authorities in geographic names. The requirements
                                                         
5
Note that the Joint ccNSO-GNSO IDN Working Group (JIG) has made recommendations that this section be revised to allow for
single-character IDN gTLD labels. See the JIG Final Report at http://gnso.icann.org/drafts/jig-final-report-30mar11-en.pdf.
Implementation models for these recommendations are being developed for community discussion.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-15
and procedure ICANN will follow in the evaluation process
are described in the following paragraphs. Applicants
should review these requirements even if they do not
believe their intended gTLD string is a geographic name. All
applied-for gTLD strings will be reviewed according to the
requirements in this section, regardless of whether the
application indicates it is for a geographic name.
2.2.1.4.1 Treatment of Country or Territory Names
6
Applications for strings that are country or territory names
will not be approved, as they are not available under the
New gTLD Program in this application round. A string shall
be considered to be a country or territory name if:
i. it is an alpha-3 code listed in the ISO 3166-1
standard.
ii. it is a long-form name listed in the ISO 3166-1
standard, or a translation of the long-form
name in any language.
iii. it is a short-form name listed in the ISO 3166-1
standard, or a translation of the short-form
name in any language.
iv. it is the short- or long-form name association
with a code that has been designated as
“exceptionally reserved” by the ISO 3166
Maintenance Agency.
v. it is a separable component of a country
name designated on the “Separable
Country Names List,” or is a translation of a
name appearing on the list, in any
language. See the Annex at the end of this
module.
vi. it is a permutation or transposition of any of
the names included in items (i) through (v).
Permutations include removal of spaces,
insertion of punctuation, and addition or
removal of grammatical articles like “the.” A
transposition is considered a change in the
sequence of the long or short–form name,
for example, “RepublicCzech” or
“IslandsCayman.”
                                                         
6
Country and territory names are excluded from the process based on advice from the Governmental Advisory Committee in recent
communiqués providing interpretation of Principle 2.2 of the GAC Principles regarding New gTLDs to indicate that strings which
are a meaningful representation or abbreviation of a country or territory name should be handled through the forthcoming ccPDP,
and other geographic strings could be allowed in the gTLD space if in agreement with the relevant government or public authority.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-16
vii. it is a name by which a country is commonly
known, as demonstrated by evidence that
the country is recognized by that name by
an intergovernmental or treaty organization.
2.2.1.4.2 Geographic Names Requiring Government
Support
The following types of applied-for strings are considered
geographic names and must be accompanied by
documentation of support or non-objection from the
relevant governments or public authorities:
1. An application for any string that is a
representation, in any language, of the capital city
name of any country or territory listed in the ISO
3166-1 standard.
2. An application for a city name, where the
applicant declares that it intends to use the gTLD
for purposes associated with the city name.
City names present challenges because city names
may also be generic terms or brand names, and in
many cases city names are not unique. Unlike other
types of geographic names, there are no
established lists that can be used as objective
references in the evaluation process. Thus, city
names are not universally protected. However, the
process does provide a means for cities and
applicants to work together where desired.
An application for a city name will be subject to the
geographic names requirements (i.e., will require
documentation of support or non-objection from
the relevant governments or public authorities) if:
(a) It is clear from applicant statements within the
application that the applicant will use the TLD
primarily for purposes associated with the city
name; and
(b) The applied-for string is a city name as listed on
official city documents.
7
                                                         
7
  City governments with concerns about strings that are duplicates, nicknames or close renderings of a city name should not rely
on the evaluation process as the primary means of protecting their interests in a string. Rather, a government may elect to file a
formal objection to an application that is opposed by the relevant community, or may submit its own application for the string.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-17
3. An application for any string that is an exact match
of a sub-national place name, such as a county,
province, or state, listed in the ISO 3166-2 standard.
4. An application for a string listed as a UNESCO
region
8
or appearing on the “Composition of
macro geographical (continental) regions,
geographical sub-regions, and selected economic
and other groupings” list.
9
In the case of an application for a string appearing
on either of the lists above, documentation of
support will be required from at least 60% of the
respective national governments in the region, and
there may be no more than one written statement
of objection to the application from relevant
governments in the region and/or public authorities
associated with the continent or the region.
Where the 60% rule is applied, and there are
common regions on both lists, the regional
composition contained in the “Composition of
macro geographical (continental) regions,
geographical sub-regions, and selected economic
and other groupings” takes precedence.
An applied-for gTLD string that falls into any of 1 through 4
listed above is considered to represent a geographic
name. In the event of any doubt, it is in the applicant’s
interest to consult with relevant governments and public
authorities and enlist their support or non-objection prior to
submission of the application, in order to preclude possible
objections and pre-address any ambiguities concerning
the string and applicable requirements.
Strings that include but do not match a geographic name
(as defined in this section) will not be considered
geographic names as defined by section 2.2.1.4.2, and
therefore will not require documentation of government
support in the evaluation process.
For each application, the Geographic Names Panel will
determine which governments are relevant based on the
inputs of the applicant, governments, and its own research
and analysis. In the event that there is more than one
relevant government or public authority for the applied-for
gTLD string, the applicant must provide documentation of
support or non-objection from all the relevant governments
                                                         
8
See http://www.unesco.org/new/en/unesco/worldwide/.
9
See http://unstats.un.org/unsd/methods/m49/m49regin.htm.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-18
or public authorities. It is anticipated that this may apply to
the case of a sub-national place name.
It is the applicant’s responsibility to:
• identify whether its applied-for gTLD string falls into
any of the above categories; and
• identify and consult with the relevant governments
or public authorities; and
• identify which level of government support is
required.
Note: the level of government and which administrative
agency is responsible for the filing of letters of support or
non-objection is a matter for each national administration
to determine. Applicants should consult within the relevant
jurisdiction to determine the appropriate level of support.
The requirement to include documentation of support for
certain applications does not preclude or exempt
applications from being the subject of objections on
community grounds (refer to subsection 3.1.1 of Module 3),
under which applications may be rejected based on
objections showing substantial opposition from the
targeted community.
2.2.1.4.3   Documentation Requirements
The documentation of support or non-objection should
include a signed letter from the relevant government or
public authority. Understanding that this will differ across
the respective jurisdictions, the letter could be signed by
the minister with the portfolio responsible for domain name
administration, ICT, foreign affairs, or the Office of the Prime
Minister or President of the relevant jurisdiction; or a senior
representative of the agency or department responsible
for domain name administration, ICT, foreign affairs, or the
Office of the Prime Minister. To assist the applicant in
determining who the relevant government or public
authority may be for a potential geographic name, the
applicant may wish to consult with the relevant
Governmental Advisory Committee (GAC)
representative.
10
The letter must clearly express the government’s or public
authority’s support for or non-objection to the applicant’s
application and demonstrate the government’s or public
                                                         
10
See https://gacweb.icann.org/display/gacweb/GAC+MembersModule 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-19
authority’s understanding of the string being requested
and its intended use.
The letter should also demonstrate the government’s or
public authority’s understanding that the string is being
sought through the gTLD application process and that the
applicant is willing to accept the conditions under which
the string will be available, i.e., entry into a registry
agreement with ICANN requiring compliance with
consensus policies and payment of fees. (See Module 5 for
a discussion of the obligations of a gTLD registry operator.)
A sample letter of support is available as an attachment to
this module.
Applicants and governments may conduct discussions
concerning government support for an application at any
time. Applicants are encouraged to begin such discussions
at the earliest possible stage, and enable governments to
follow the processes that may be necessary to consider,
approve, and generate a letter of support or nonobjection.
It is important to note that a government or public authority
is under no obligation to provide documentation of support
or non-objection in response to a request by an applicant.
It is also possible that a government may withdraw its
support for an application at a later time, including after
the new gTLD has been delegated, if the registry operator
has deviated from the conditions of original support or nonobjection. Applicants should be aware that ICANN has
committed to governments that, in the event of a dispute
between a government (or public authority) and a registry
operator that submitted documentation of support from
that government or public authority, ICANN will comply
with a legally binding order from a court in the jurisdiction
of the government or public authority that has given
support to an application.
2.2.1.4.4 Review Procedure for Geographic Names
A Geographic Names Panel (GNP) will determine whether
each applied-for gTLD string represents a geographic
name, and verify the relevance and authenticity of the
supporting documentation where necessary.
The GNP will review all applications received, not only
those where the applicant has noted its applied-for gTLD
string as a geographic name. For any application where
the GNP determines that the applied-for gTLD string is a
country or territory name (as defined in this module), the Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-20
application will not pass the Geographic Names review
and will be denied. No additional reviews will be available.
For any application where the GNP determines that the
applied-for gTLD string is not a geographic name requiring
government support (as described in this module), the
application will pass the Geographic Names review with no
additional steps required.
For any application where the GNP determines that the
applied-for gTLD string is a geographic name requiring
government support, the GNP will confirm that the
applicant has provided the required documentation from
the relevant governments or public authorities, and that
the communication from the government or public
authority is legitimate and contains the required content.
ICANN may confirm the authenticity of the communication
by consulting with the relevant diplomatic authorities or
members of ICANN’s Governmental Advisory Committee
for the government or public authority concerned on the
competent authority and appropriate point of contact
within their administration for communications.
The GNP may communicate with the signing entity of the
letter to confirm their intent and their understanding of the
terms on which the support for an application is given.
In cases where an applicant has not provided the required
documentation, the applicant will be contacted and
notified of the requirement, and given a limited time frame
to provide the documentation. If the applicant is able to
provide the documentation before the close of the Initial
Evaluation period, and the documentation is found to
meet the requirements, the applicant will pass the
Geographic Names review. If not, the applicant will have
additional time to obtain the required documentation;
however, if the applicant has not produced the required
documentation by the required date (at least 90 days from
the date of notice), the application will be considered
incomplete and will be ineligible for further review. The
applicant may reapply in subsequent application rounds, if
desired, subject to the fees and requirements of the
specific application rounds.
If there is more than one application for a string
representing a certain geographic name as described in
this section, and the applications have requisite
government approvals, the applications will be suspended
pending resolution by the applicants. If the applicants
have not reached a resolution by either the date of the
end of the application round (as announced by ICANN), or Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-21
the date on which ICANN opens a subsequent application
round, whichever comes first, the applications will be
rejected and applicable refunds will be available to
applicants according to the conditions described in
section 1.5.
However, in the event that a contention set is composed of
multiple applications with documentation of support from
the same government or public authority, the applications
will proceed through the contention resolution procedures
described in Module 4 when requested by the government
or public authority providing the documentation.
If an application for a string representing a geographic
name is in a contention set with applications for similar
strings that have not been identified as geographical
names, the string contention will be resolved using the
string contention procedures described in Module 4.
2.2.2 Applicant Reviews
Concurrent with the applied-for gTLD string reviews
described in subsection 2.2.1, ICANN will review the
applicant’s technical and operational capability, its
financial capability, and its proposed registry services.
Those reviews are described in greater detail in the
following subsections.
2.2.2.1 Technical/Operational Review
In its application, the applicant will respond to a set of
questions (see questions 24 – 44 in the Application Form)
intended to gather information about the applicant’s
technical capabilities and its plans for operation of the
proposed gTLD.
Applicants are not required to have deployed an actual
gTLD registry to pass the Technical/Operational review. It
will be necessary, however, for an applicant to
demonstrate a clear understanding and accomplishment
of some groundwork toward the key technical and
operational aspects of a gTLD registry operation.
Subsequently, each applicant that passes the technical
evaluation and all other steps will be required to complete
a pre-delegation technical test prior to delegation of the
new gTLD. Refer to Module 5, Transition to Delegation, for
additional information.
2.2.2.2  Financial Review
In its application, the applicant will respond to a set of
questions (see questions 45-50 in the Application Form)Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-22
intended to gather information about the applicant’s
financial capabilities for operation of a gTLD registry and its
financial planning in preparation for long-term stability of
the new gTLD.
Because different registry types and purposes may justify
different responses to individual questions, evaluators will
pay particular attention to the consistency of an
application across all criteria. For example, an applicant’s
scaling plans identifying system hardware to ensure its
capacity to operate at a particular volume level should be
consistent with its financial plans to secure the necessary
equipment. That is, the evaluation criteria scale with the
applicant plans to provide flexibility.
2.2.2.3 Evaluation Methodology
Dedicated technical and financial evaluation panels will
conduct the technical/operational and financial reviews,
according to the established criteria and scoring
mechanism included as an attachment to this module.
These reviews are conducted on the basis of the
information each applicant makes available to ICANN in its
response to the questions in the Application Form.
The evaluators may request clarification or additional
information during the Initial Evaluation period. For each
application, clarifying questions will be consolidated and
sent to the applicant from each of the panels. The
applicant will thus have an opportunity to clarify or
supplement the application in those areas where a request
is made by the evaluators. These communications will
occur via TAS. Unless otherwise noted, such
communications will include a 2-week deadline for the
applicant to respond. Any supplemental information
provided by the applicant will become part of the
application.
It is the applicant’s responsibility to ensure that the
questions have been fully answered and the required
documentation is attached. Evaluators are entitled, but
not obliged, to request further information or evidence
from an applicant, and are not obliged to take into
account any information or evidence that is not made
available in the application and submitted by the due
date, unless explicitly requested by the evaluators.
2.2.3 Registry Services Review
Concurrent with the other reviews that occur during the
Initial Evaluation period, ICANN will review the applicant’s
proposed registry services for any possible adverse impact Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-23
on security or stability. The applicant will be required to
provide a list of proposed registry services in its application.
2.2.3.1   Definitions
Registry services are defined as:
1. operations of the registry critical to the following
tasks: the receipt of data from registrars concerning
registrations of domain names and name servers;
provision to registrars of status information relating
to the zone servers for the TLD; dissemination of TLD
zone files; operation of the registry zone servers; and
dissemination of contact and other information
concerning domain name server registrations in the
TLD as required by the registry agreement;
2. other products or services that the registry operator
is required to provide because of the establishment
of a consensus policy; and
3. any other products or services that only a registry
operator is capable of providing, by reason of its
designation as the registry operator.
Proposed registry services will be examined to determine if
they might raise significant stability or security issues.
Examples of services proposed by existing registries can be
found at http://www.icann.org/en/registries/rsep/. In most
cases, these proposed services successfully pass this inquiry.
Registry services currently provided by gTLD registries can
be found in registry agreement appendices. See
http://www.icann.org/en/registries/agreements.htm.
A full definition of registry services can be found at
http://www.icann.org/en/registries/rsep/rsep.html.
For purposes of this review, security and stability are
defined as follows:
Security – an effect on security by the proposed registry
service means (1) the unauthorized disclosure, alteration,
insertion or destruction of registry data, or (2) the
unauthorized access to or disclosure of information or
resources on the Internet by systems operating in
accordance with all applicable standards.
Stability – an effect on stability means that the proposed
registry service (1) does not comply with applicable
relevant standards that are authoritative and published by
a well-established, recognized, and authoritative standards
body, such as relevant standards-track or best current Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-24
practice RFCs sponsored by the IETF, or (2) creates a
condition that adversely affects the throughput, response
time, consistency, or coherence of responses to Internet
servers or end systems, operating in accordance with
applicable relevant standards that are authoritative and
published by a well-established, recognized and
authoritative standards body, such as relevant standardstrack or best current practice RFCs and relying on registry
operator’s delegation information or provisioning services.
2.2.3.2   Customary Services
The following registry services are customary services
offered by a registry operator:
• Receipt of data from registrars concerning
registration of domain names and name servers
• Dissemination of TLD zone files
• Dissemination of contact or other information
concerning domain name registrations
• DNS Security Extensions
The applicant must describe whether any of these registry
services are intended to be offered in a manner unique to
the TLD.
Any additional registry services that are unique to the
proposed gTLD registry should be described in detail.
Directions for describing the registry services are provided
at http://www.icann.org/en/registries/rsep/rrs_sample.html.
2.2.3.3   TLD Zone Contents
ICANN receives a number of inquiries about use of various
record types in a registry zone, as entities contemplate
different business and technical models. Permissible zone
contents for a TLD zone are:
• Apex SOA record.
• Apex NS records and in-bailiwick glue for the TLD’s
DNS servers.
• NS records and in-bailiwick glue for DNS servers of
registered names in the TLD.
• DS records for registered names in the TLD.
• Records associated with signing the TLD zone (i.e.,
RRSIG, DNSKEY, NSEC, and NSEC3).Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-25
An applicant wishing to place any other record types into
its TLD zone should describe in detail its proposal in the
registry services section of the application. This will be
evaluated and could result in an extended evaluation to
determine whether the service would create a risk of a
meaningful adverse impact on security or stability of the
DNS. Applicants should be aware that a service based on
use of less-common DNS resource records in the TLD zone,
even if approved in the registry services review, might not
work as intended for all users due to lack of application
support.
2.2.3.4  Methodology
Review of the applicant’s proposed registry services will
include a preliminary determination of whether any of the
proposed registry services could raise significant security or
stability issues and require additional consideration.
If the preliminary determination reveals that there may be
significant security or stability issues (as defined in
subsection 2.2.3.1) surrounding a proposed service, the
application will be flagged for an extended review by the
Registry Services Technical Evaluation Panel (RSTEP), see
http://www.icann.org/en/registries/rsep/rstep.html). This
review, if applicable, will occur during the Extended
Evaluation period (refer to Section 2.3).
In the event that an application is flagged for extended
review of one or more registry services, an additional fee to
cover the cost of the extended review will be due from the
applicant. Applicants will be advised of any additional fees
due, which must be received before the additional review
begins.
2.2.4 Applicant’s Withdrawal of an Application
An applicant who does not pass the Initial Evaluation may
withdraw its application at this stage and request a partial
refund (refer to subsection 1.5 of Module 1).
2.3 Extended Evaluation
An applicant may request an Extended Evaluation if the
application has failed to pass the Initial Evaluation
elements concerning:
• Geographic names (refer to subsection 2.2.1.4).
There is no additional fee for an extended
evaluation in this instance.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-26
• Demonstration of technical and operational
capability (refer to subsection 2.2.2.1). There is no
additional fee for an extended evaluation in this
instance.
• Demonstration of financial capability (refer to
subsection 2.2.2.2). There is no additional fee for an
extended evaluation in this instance.
• Registry services (refer to subsection 2.2.3). Note
that this investigation incurs an additional fee (the
Registry Services Review Fee) if the applicant wishes
to proceed. See Section 1.5 of Module 1 for fee and
payment information.
An Extended Evaluation does not imply any change of the
evaluation criteria. The same criteria used in the Initial
Evaluation will be used to review the application in light of
clarifications provided by the applicant.
From the time an applicant receives notice of failure to
pass the Initial Evaluation, eligible applicants will have 15
calendar days to submit to ICANN the Notice of Request
for Extended Evaluation. If the applicant does not explicitly
request the Extended Evaluation (and pay an additional
fee in the case of a Registry Services inquiry) the
application will not proceed.
2.3.1 Geographic Names Extended Evaluation
In the case of an application that has been identified as a
geographic name requiring government support, but
where the applicant has not provided sufficient evidence
of support or non-objection from all relevant governments
or public authorities by the end of the Initial Evaluation
period, the applicant has additional time in the Extended
Evaluation period to obtain and submit this
documentation.
If the applicant submits the documentation to the
Geographic Names Panel by the required date, the GNP
will perform its review of the documentation as detailed in
section 2.2.1.4. If the applicant has not provided the
documentation by the required date (at least 90 days from
the date of the notice), the application will not pass the
Extended Evaluation, and no further reviews are available.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-27
2.3.2 Technical/Operational or Financial Extended
Evaluation
The following applies to an Extended Evaluation of an
applicant’s technical and operational capability or
financial capability, as described in subsection 2.2.2.
An applicant who has requested Extended Evaluation will
again access the online application system (TAS) and
clarify its answers to those questions or sections on which it
received a non-passing score (or, in the case of an
application where individual questions were passed but
the total score was insufficient to pass Initial Evaluation,
those questions or sections on which additional points are
possible). The answers should be responsive to the
evaluator report that indicates the reasons for failure, or
provide any amplification that is not a material change to
the application. Applicants may not use the Extended
Evaluation period to substitute portions of new information
for the information submitted in their original applications,
i.e., to materially change the application.
An applicant participating in an Extended Evaluation on
the Technical / Operational or Financial reviews will have
the option to have its application reviewed by the same
evaluation panelists who performed the review during the
Initial Evaluation period, or to have a different set of
panelists perform the review during Extended Evaluation.
The Extended Evaluation allows an additional exchange of
information between the evaluators and the applicant to
further clarify information contained in the application. This
supplemental information will become part of the
application record. Such communications will include a
deadline for the applicant to respond.
ICANN will notify applicants at the end of the Extended
Evaluation period as to whether they have passed. If an
application passes Extended Evaluation, it continues to the
next stage in the process. If an application does not pass
Extended Evaluation, it will proceed no further. No further
reviews are available.
2.3.3 Registry Services Extended Evaluation
This section applies to Extended Evaluation of registry
services, as described in subsection 2.2.3.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-28
If a proposed registry service has been referred to the
Registry Services Technical Evaluation Panel (RSTEP) for an
extended review, the RSTEP will form a review team of
members with the appropriate qualifications.
The review team will generally consist of three members,
depending on the complexity of the registry service
proposed. In a 3-member panel, the review could be
conducted within 30 to 45 days. In cases where a 5-
member panel is needed, this will be identified before the
extended evaluation starts. In a 5-member panel, the
review could be conducted in 45 days or fewer.
The cost of an RSTEP review will be covered by the
applicant through payment of the Registry Services Review
Fee. Refer to payment procedures in section 1.5 of Module
1. The RSTEP review will not commence until payment has
been received.
If the RSTEP finds that one or more of the applicant’s
proposed registry services may be introduced without risk
of a meaningful adverse effect on security or stability,
these services will be included in the applicant’s registry
agreement with ICANN. If the RSTEP finds that the proposed
service would create a risk of a meaningful adverse effect
on security or stability, the applicant may elect to proceed
with its application without the proposed service, or
withdraw its application for the gTLD. In this instance, an
applicant has 15 calendar days to notify ICANN of its intent
to proceed with the application. If an applicant does not
explicitly provide such notice within this time frame, the
application will proceed no further.
2.4 Parties Involved in Evaluation
A number of independent experts and groups play a part
in performing the various reviews in the evaluation process.
A brief description of the various panels, their evaluation
roles, and the circumstances under which they work is
included in this section.
2.4.1   Panels and Roles
The String Similarity Panel will assess whether a proposed
gTLD string creates a probability of user confusion due to
similarity with any reserved name, any existing TLD, any
requested IDN ccTLD, or any new gTLD string applied for in
the current application round. This occurs during the String
Similarity review in Initial Evaluation. The panel may also
review IDN tables submitted by applicants as part of its
work.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-29
The DNS Stability Panel will determine whether a proposed
string might adversely affect the security or stability of the
DNS. This occurs during the DNS Stability String review in
Initial Evaluation.
The Geographic Names Panel will review each application
to determine whether the applied-for gTLD represents a
geographic name, as defined in this guidebook. In the
event that the string is a geographic name requiring
government support, the panel will ensure that the
required documentation is provided with the application
and verify that the documentation is from the relevant
governments or public authorities and is authentic.
The Technical Evaluation Panel will review the technical
components of each application against the criteria in the
Applicant Guidebook, along with proposed registry
operations, in order to determine whether the applicant is
technically and operationally capable of operating a gTLD
registry as proposed in the application. This occurs during
the Technical/Operational reviews in Initial Evaluation, and
may also occur in Extended Evaluation if elected by the
applicant.
The Financial Evaluation Panel will review each application
against the relevant business, financial and organizational
criteria contained in the Applicant Guidebook, to
determine whether the applicant is financially capable of
maintaining a gTLD registry as proposed in the application.
This occurs during the Financial review in Initial Evaluation,
and may also occur in Extended Evaluation if elected by
the applicant.
The Registry Services Technical Evaluation Panel (RSTEP) will
review proposed registry services in the application to
determine if they pose a risk of a meaningful adverse
impact on security or stability. This occurs, if applicable,
during the Extended Evaluation period.
Members of all panels are required to abide by the
established Code of Conduct and Conflict of Interest
guidelines included in this module.
2.4.2   Panel Selection Process
ICANN is in the process of selecting qualified third-party
providers to perform the various reviews.
11
In addition to
the specific subject matter expertise required for each
panel, specified qualifications are required, including:
                                                         
11
See http://icann.org/en/topics/new-gtlds/open-tenders-eoi-en.htm.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-30
• The provider must be able to convene – or have
the capacity to convene - globally diverse panels
and be able to evaluate applications from all
regions of the world, including applications for IDN
gTLDs.
• The provider should be familiar with the IETF IDNA
standards, Unicode standards, relevant RFCs and
the terminology associated with IDNs.
• The provider must be able to scale quickly to meet
the demands of the evaluation of an unknown
number of applications. At present it is not known
how many applications will be received, how
complex they will be, and whether they will be
predominantly for ASCII or non-ASCII gTLDs.
• The provider must be able to evaluate the
applications within the required timeframes of Initial
and Extended Evaluation.
The providers will be formally engaged and announced on
ICANN’s website prior to the opening of the Application
Submission period.
2.4.3   Code of Conduct Guidelines for Panelists
The purpose of the New gTLD Program (“Program”) Code
of Conduct (“Code”) is to prevent real and apparent
conflicts of interest and unethical behavior by any
Evaluation Panelist (“Panelist”).
Panelists shall conduct themselves as thoughtful,
competent, well prepared, and impartial professionals
throughout the application process. Panelists are expected
to comply with equity and high ethical standards while
assuring the Internet community, its constituents, and the
public of objectivity, integrity, confidentiality, and
credibility. Unethical actions, or even the appearance of
compromise, are not acceptable. Panelists are expected
to be guided by the following principles in carrying out their
respective responsibilities. This Code is intended to
summarize the principles and nothing in this Code should
be considered as limiting duties, obligations or legal
requirements with which Panelists must comply.
Bias -- Panelists shall:Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-31
• not advance personal agendas or non-ICANN
approved agendas in the evaluation of
applications;
• examine facts as they exist and not be influenced
by past reputation, media accounts, or unverified
statements about the applications being
evaluated;
• exclude themselves from participating in the
evaluation of an application if, to their knowledge,
there is some predisposing factor that could
prejudice them with respect to such evaluation;
and
• exclude themselves from evaluation activities if they
are philosophically opposed to or are on record as
having made generic criticism about a specific
type of applicant or application.
Compensation/Gifts -- Panelists shall not request or accept
any compensation whatsoever or any gifts of substance
from the Applicant being reviewed or anyone affiliated
with the Applicant. (Gifts of substance would include any
gift greater than USD 25 in value).
If the giving of small tokens is important to the Applicant’s
culture, Panelists may accept these tokens; however, the
total of such tokens must not exceed USD 25 in value. If in
doubt, the Panelist should err on the side of caution by
declining gifts of any kind.
Conflicts of Interest -- Panelists shall act in accordance with
the “New gTLD Program Conflicts of Interest Guidelines”
(see subsection 2.4.3.1).
Confidentiality -- Confidentiality is an integral part of the
evaluation process. Panelists must have access to sensitive
information in order to conduct evaluations. Panelists must
maintain confidentiality of information entrusted to them
by ICANN and the Applicant and any other confidential
information provided to them from whatever source,
except when disclosure is legally mandated or has been
authorized by ICANN. “Confidential information” includes
all elements of the Program and information gathered as
part of the process – which includes but is not limited to:
documents, interviews, discussions, interpretations, and
analyses – related to the review of any new gTLD
application.Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-32
Affirmation -- All Panelists shall read this Code prior to
commencing evaluation services and shall certify in writing
that they have done so and understand the Code.
2.4.3.1  Conflict of Interest Guidelines for Panelists
It is recognized that third-party providers may have a large
number of employees in several countries serving
numerous clients. In fact, it is possible that a number of
Panelists may be very well known within the registry /
registrar community and have provided professional
services to a number of potential applicants.
To safeguard against the potential for inappropriate
influence and ensure applications are evaluated in an
objective and independent manner, ICANN has
established detailed Conflict of Interest guidelines and
procedures that will be followed by the Evaluation
Panelists. To help ensure that the guidelines are
appropriately followed ICANN will:
• Require each Evaluation Panelist (provider
and individual) to acknowledge and
document understanding of the Conflict of
Interest guidelines.
• Require each Evaluation Panelist to disclose
all business relationships engaged in at any
time during the past six months.
• Where possible, identify and secure primary
and backup providers for evaluation panels.
• In conjunction with the Evaluation Panelists,
develop and implement a process to
identify conflicts and re-assign applications
as appropriate to secondary or contingent
third party providers to perform the reviews.
Compliance Period -- All Evaluation Panelists must comply
with the Conflict of Interest guidelines beginning with the
opening date of the Application Submission period and
ending with the public announcement by ICANN of the
final outcomes of all the applications from the Applicant in
question. Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-33
Guidelines -- The following guidelines are the minimum
standards with which all Evaluation Panelists must comply.
It is recognized that it is impossible to foresee and cover all
circumstances in which a potential conflict of interest
might arise. In these cases the Evaluation Panelist should
evaluate whether the existing facts and circumstances
would lead a reasonable person to conclude that there is
an actual conflict of interest.
Evaluation Panelists and Immediate Family Members:
• Must not be under contract, have or be
included in a current proposal to provide
Professional Services for or on behalf of the
Applicant during the Compliance Period.
• Must not currently hold or be committed to
acquire any interest in a privately-held
Applicant.
• Must not currently hold or be committed to
acquire more than 1% of any publicly listed
Applicant’s outstanding equity securities or
other ownership interests.
• Must not be involved or have an interest in a
joint venture, partnership or other business
arrangement with the Applicant.
• Must not have been named in a lawsuit with
or against the Applicant.
• Must not be a:
o Director, officer, or employee, or in
any capacity equivalent to that of a
member of management of the
Applicant;
o Promoter, underwriter, or voting
trustee of the Applicant; or
o Trustee for any pension or profitsharing trust of the Applicant.
Definitions--
Evaluation Panelist: An Evaluation Panelist is any individual
associated with the review of an application. This includes
any primary, secondary, and contingent third party
Panelists engaged by ICANN to review new gTLD
applications.   Module 2
Evaluation Procedures
Applicant Guidebook | version 2011-09-19
2-34
Immediate Family Member: Immediate Family Member is a
spouse, spousal equivalent, or dependent (whether or not
related) of an Evaluation Panelist.
Professional Services: include, but are not limited to legal
services, financial audit, financial planning / investment,
outsourced services, consulting services such as business /
management / internal audit, tax, information technology,
registry / registrar services.
2.4.3.2 Code of Conduct Violations
Evaluation panelist breaches of the Code of Conduct,
whether intentional or not, shall be reviewed by ICANN,
which may make recommendations for corrective action,
if deemed necessary. Serious breaches of the Code may
be cause for dismissal of the person, persons or provider
committing the infraction.
In a case where ICANN determines that a Panelist has
failed to comply with the Code of Conduct, the results of
that Panelist’s review for all assigned applications will be
discarded and the affected applications will undergo a
review by new panelists.
Complaints about violations of the Code of Conduct by a
Panelist may be brought to the attention of ICANN via the
public comment and applicant support mechanisms,
throughout the evaluation period. Concerns of applicants
regarding panels should be communicated via the
defined support channels (see subsection 1.4.2). Concerns
of the general public (i.e., non-applicants) can be raised
via the public comment forum, as described in Module 1.
2.4.4   Communication Channels
Defined channels for technical support or exchanges of
information with ICANN and with evaluation panels are
available to applicants during the Initial Evaluation and
Extended Evaluation periods. Contacting individual ICANN
staff members, Board members, or individuals engaged by
ICANN to perform an evaluation role in order to lobby for a
particular outcome or to obtain confidential information
about applications under review is not appropriate. In the
interests of fairness and equivalent treatment for all
applicants, any such individual contacts will be referred to
the appropriate communication channels.  DRAFT - New gTLD Program – Initial Evaluation and Extended Evaluation
Initial Evaluation – String Review
Yes
Does applicant pass all elements
of Extended Evaluation?
Yes
Ineligible for
further review
No
Initial Evaluation – Applicant Review
Applicant elects to pursue
Extended Evaluation?
Extended Evaluation can be for any or
all of the four elements below:
Technical and Operational
Capability
Financial Capability
Geographical Names
Registry Services
But NOT for String Similarity or DNS
Stability
Application is confirmed as complete and ready for evaluation
during Administrative Completeness Check
String Similarity
String Similarity Panel
reviews applied-for strings
to ensure they are not too
similar to existing TLDs or
Reserved Names.
Panel compares all
applied-for strings
and creates
contention sets.
DNS Stability
All strings reviewed and
in extraordinary cases,
DNS Stability Panel may
perform extended review
for possible technical
stability issues.
Geographic Names
Geographic Names Panel
determines if applied-for
string is geographic name
requiring government
support.
Panel confirms
supporting
documentation
where required.
Technical and
Operational Capability
Technical and
Operational panel reviews
applicant’s answers to
questions and supporting
documentation.
Financial Capability
Financial panel
reviews applicant’s
answers to questions
and supporting
documentation.
Registry Services
Preliminary review of
applicant’s registry
services and referral to
RSTEP for further review
during Extended
Evaluation where
necessary
Extended Evaluation
process
Applicant continues to
subsequent steps.
Background Screening
Third-party provider
reviews applicant’s
background.
No Yes
No
ICANN will seek to publish contention
sets prior to publication of full IE
results.
Does applicant pass all
elements of Initial Evaluation?Annex:  Separable Country Names List
gTLD application restrictions on country or territory names are tied to listing in property fields of
the ISO 3166-1 standard. Notionally, the ISO 3166-1 standard has an “English short name” field
which is the common name for a country and can be used for such protections; however, in
some cases this does not represent the common name. This registry seeks to add additional
protected elements which are derived from definitions in the ISO 3166-1 standard. An
explanation of the various classes is included below.
Separable Country Names List
Code English Short Name Cl. Separable Name
ax Åland Islands B1 Åland
as American Samoa C Tutuila
C Swain’s Island
ao Angola C Cabinda
ag Antigua and Barbuda A Antigua
A Barbuda
C Redonda Island
au Australia C Lord Howe Island
C Macquarie Island
C Ashmore Island
C Cartier Island
C Coral Sea Islands
bo Bolivia, Plurinational State of  B1 Bolivia
bq Bonaire, Sint Eustatius and Saba A Bonaire
A Sint Eustatius
A Saba
ba Bosnia and Herzegovina A Bosnia
A Herzegovina
br Brazil C Fernando de Noronha Island
C Martim Vaz Islands
C Trinidade Island
io British Indian Ocean Territory C Chagos Archipelago
C Diego Garcia
bn Brunei Darussalam B1 Brunei
C Negara Brunei Darussalam
cv Cape Verde C São Tiago
C São Vicente
ky Cayman Islands C Grand Cayman
cl Chile C Easter Island
C Juan Fernández Islands
C Sala y Gómez Island
C San Ambrosio Island
C San Félix Island
cc Cocos (Keeling) Islands A Cocos Islands
A Keeling Islands
co Colombia C Malpelo Island
C San Andrés Island
C Providencia Island
km Comoros C Anjouan
C Grande Comore
C Mohéli
ck Cook Islands C Rarotonga
cr Costa Rica C Coco Island
ec Ecuador C Galápagos Islands
gq Equatorial Guinea C Annobón Island
C Bioko IslandC Río Muni
fk Falkland Islands (Malvinas) B1 Falkland Islands
B1 Malvinas
fo Faroe Islands A Faroe
fj Fiji C Vanua Levu
C Viti Levu
C Rotuma Island
pf French Polynesia C Austral Islands
C Gambier Islands
C Marquesas Islands
C Society Archipelago
C Tahiti
C Tuamotu Islands
C Clipperton Island
tf French Southern Territories C Amsterdam Islands
C Crozet Archipelago
C Kerguelen Islands
C Saint Paul Island
gr Greece C Mount Athos
B1 **
gd Grenada C Southern Grenadine Islands
C Carriacou
gp Guadeloupe C la Désirade
C Marie-Galante
C les Saintes
hm Heard Island and McDonald Islands A Heard Island
A McDonald Islands
va Holy See (Vatican City State) A Holy See
A Vatican
hn Honduras C Swan Islands
in India C Amindivi Islands
C Andaman Islands
C Laccadive Islands
C Minicoy Island
C Nicobar Islands
ir Iran, Islamic Republic of B1 Iran
ki Kiribati C Gilbert Islands
C Tarawa
C Banaba
C Line Islands
C Kiritimati
C Phoenix Islands
C Abariringa
C Enderbury Island
kp Korea, Democratic People’s
Republic of
C North Korea
kr Korea, Republic of C South Korea
la Lao People’s Democratic Republic B1 Laos
ly Libyan Arab Jamahiriya  B1 Libya
mk Macedonia, the Former Yugoslav
Republic of
B1 **
my Malaysia C Sabah
C Sarawak
mh Marshall Islands C Jaluit
Kwajalein
Majuro
mu Mauritius C Agalega Islands
C Cargados Carajos Shoals
C Rodrigues Islandfm Micronesia, Federated States of B1 Micronesia
C Caroline Islands (see also pw)
C Chuuk
C Kosrae
C Pohnpei
C Yap
md Moldova, Republic of B1 Moldova
C Moldava
nc New Caledonia C Loyalty Islands
mp Northern Mariana Islands C Mariana Islands
C Saipan
om Oman C Musandam Peninsula
pw Palau C Caroline Islands (see also fm)
C Babelthuap
ps Palestinian Territory, Occupied B1 Palestine
pg Papua New Guinea C Bismarck Archipelago
C Northern Solomon Islands
C Bougainville
pn Pitcairn C Ducie Island
C Henderson Island
C Oeno Island
re Réunion C Bassas da India
C Europa Island
C Glorioso Island
C Juan de Nova Island
C Tromelin Island
ru Russian Federation B1 Russia
C Kaliningrad Region
sh Saint Helena, Ascension, and
Tristan de Cunha
A Saint Helena
A Ascension
A Tristan de Cunha
C Gough Island
C Tristan de Cunha Archipelago
kn Saint Kitts and Nevis A Saint Kitts
A Nevis
pm Saint Pierre and Miquelon A Saint Pierre
A Miquelon
vc Saint Vincent and the Grenadines A Saint Vincent
A The Grenadines
C Northern Grenadine Islands
C Bequia
C Saint Vincent Island
ws Samoa C Savai’i
C Upolu
st Sao Tome and Principe A Sao Tome
A Principe
sc Seychelles C Mahé
C Aldabra Islands
C Amirante Islands
C Cosmoledo Islands
C Farquhar Islands
sb Solomon Islands C Santa Cruz IslandsC Southern Solomon Islands
C Guadalcanal
za South Africa C Marion Island
C Prince Edward Island
gs South Georgia and the South
Sandwich Islands
A South Georgia
A South Sandwich Islands
sj Svalbard and Jan Mayen A Svalbard
A Jan Mayen
C Bear Island
sy Syrian Arab Republic B1 Syria
tw Taiwan, Province of China B1 Taiwan
C Penghu Islands
C Pescadores
tz Tanzania, United Republic of B1 Tanzania
tl Timor-Leste C Oecussi
to Tonga C Tongatapu
tt Trinidad and Tobago A Trinidad
A Tobago
tc Turks and Caicos Islands A Turks Islands
A Caicos Islands
tv Tuvalu C Fanafuti
ae United Arab Emirates B1 Emirates
us United States B2 America
um United States Minor Outlying
Islands
C Baker Island
C Howland Island
C Jarvis Island
C Johnston Atoll
C Kingman Reef
C Midway Islands
C Palmyra Atoll
C Wake Island
C Navassa Island
vu Vanuatu C Efate
C Santo
ve Venezuela, Bolivarian Republic of B1 Venezuela
C Bird Island
vg Virgin Islands, British B1 Virgin Islands
C Anegada
C Jost Van Dyke
C Tortola
C Virgin Gorda
vi Virgin Islands, US B1 Virgin Islands
C Saint Croix
C Saint John
C Saint Thomas
wf Wallis and Futuna A Wallis
A Futuna
C Hoorn Islands
C Wallis Islands
C Uvea
ye Yemen C Socotra IslandMaintenance
A Separable Country Names Registry will be maintained and published by ICANN Staff.
Each time the ISO 3166-1 standard is updated with a new entry, this registry will be reappraised
to identify if the changes to the standard warrant changes to the entries in this registry. Appraisal
will be based on the criteria listing in the “Eligibility” section of this document.
Codes reserved by the ISO 3166 Maintenance Agency do not have any implication on this
registry, only entries derived from normally assigned codes appearing in ISO 3166-1 are eligible.
If an ISO code is struck off the ISO 3166-1 standard, any entries in this registry deriving from that
code must be struck.
Eligibility
Each record in this registry is derived from the following possible properties:
In the first two cases, the registry listing must be directly derivative from the English Short Name by
excising words and articles. These registry listings do not include vernacular or other non-official
terms used to denote the country.
Eligibility is calculated in class order. For example, if a term can be derived both from Class A
and Class C, it is only listed as Class A.
Class A: The ISO 3166-1 English Short Name is comprised of multiple, separable
parts whereby the country is comprised of distinct sub-entities. Each of
these separable parts is eligible in its own right for consideration as a
country name. For example, “Antigua and Barbuda” is comprised of
“Antigua” and “Barbuda.”
Class B: The ISO 3166-1 English Short Name (1) or the ISO 3166-1 English Full Name
(2) contains additional language as to the type of country the entity is,
which is often not used in common usage when referencing the
country. For example, one such short name is “The Bolivarian Republic
of Venezuela” for a country in common usage referred to as
“Venezuela.”
** Macedonia is a separable name in the context of this list; however,
due to the ongoing dispute listed in UN documents between the
Hellenic Republic (Greece) and the Former Yugoslav Republic of
Macedonia over the name, no country will be afforded attribution or
rights to the name “Macedonia” until the dispute over the name has
been resolved. See http://daccess-ddsny.un.org/doc/UNDOC/GEN/N93/240/37/IMG/N9324037.pdf.
Class C: The ISO 3166-1 Remarks column containing synonyms of the country
name, or sub-national entities, as denoted by “often referred to as,”
“includes”, “comprises”, “variant” or “principal islands”.Attachment to Module 2
Sample Letter of Government Support
[This letter should be provided on official letterhead]
ICANN
Suite 330, 4676 Admiralty Way
Marina del Rey, CA 90292
Attention: New gTLD Evaluation Process
Subject: Letter for support for [TLD requested]
This letter is to confirm that [government entity] fully supports the application for [TLD] submitted
to ICANN by [applicant] in the New gTLD Program.  As the [Minister/Secretary/position] I confirm
that I have the authority of the [x government/public authority] to be writing to you on this
matter. [Explanation of government entity, relevant department, division, office, or agency, and
what its functions and responsibilities are]
The gTLD will be used to [explain your understanding of how the name will be used by the
applicant. This could include policies developed regarding who can register a name, pricing
regime and management structures.]  [Government/public authority/department] has worked
closely with the applicant in the development of this proposal.
The [x government/public authority] supports this application, and in doing so, understands that
in the event that the application is successful, [applicant] will be required to enter into a Registry
Agreement with ICANN. In doing so, they will be required to pay fees to ICANN and comply with
consensus policies developed through the ICANN multi-stakeholder policy processes.  
[Government / public authority] further understands that, in the event of a dispute between
[government/public authority] and the applicant, ICANN will comply with a legally binding order
from a court in the jurisdiction of [government/public authority].
[Optional] This application is being submitted as a community-based application, and as such it
is understood that the Registry Agreement will reflect the community restrictions proposed in the
application.  In the event that we believe the registry is not complying with these restrictions,
possible avenues of recourse include the Registry Restrictions Dispute Resolution Procedure.
[Optional]  I can advise that in the event that this application is successful [government/public
authority] will enter into a separate agreement with the applicant. This agreement will outline
the conditions under which we support them in the operation of the TLD, and circumstances
under which we would withdraw that support. ICANN will not be a party to this agreement, and
enforcement of this agreement lies fully with [government/public authority].  [Government / public authority] understands that the Geographic Names Panel engaged by
ICANN will, among other things, conduct due diligence on the authenticity of this
documentation.  I would request that if additional information is required during this process, that
[name and contact details] be contacted in the first instance.
Thank you for the opportunity to support this application.
Yours sincerely
Signature from relevant government/public authority
      A-1
Attachment to Module 2
Evaluation Questions and Criteria
Since ICANN was founded in 1998 as a not-for-profit, multi-stakeholder organization, one of its
key mandates has been to promote competition in the domain name market. ICANN’s mission
specifically calls for the corporation to maintain and build on processes that will ensure
competition and consumer interests – without compromising Internet security and stability. This
includes the consideration and implementation of new gTLDs. It is ICANN’s goal to make the
criteria and evaluation as objective as possible.
While new gTLDs are viewed by ICANN as important to fostering choice, innovation and
competition in domain registration services, the decision to launch these coming new gTLD
application rounds followed a detailed and lengthy consultation process with all constituencies
of the global Internet community.
Any public or private sector organization can apply to create and operate a new gTLD.
However the process is not like simply registering or buying a second-level domain name.
Instead, the application process is to evaluate and select candidates capable of running a
registry, a business that manages top level domains such as, for example, .COM or .INFO. Any
successful applicant will need to meet published operational and technical criteria in order to
preserve Internet stability and interoperability.
 I.  Principles of the Technical and Financial New gTLD Evaluation Criteria
 Principles of conservatism. This is the first round of what is to be an ongoing process for
the introduction of new TLDs, including Internationalized Domain Names. Therefore, the
criteria in this round require applicants to provide a thorough and thoughtful analysis of
the technical requirements to operate a registry and the proposed business model.
 The criteria and evaluation should be as objective as possible.
 With that goal in mind, an important objective of the new TLD process is to diversify
the namespace, with different registry business models and target audiences. In
some cases, criteria that are objective, but that ignore the differences in business
models and target audiences of new registries, will tend to make the process
exclusionary. For example, the business model for a registry targeted to a small
community need not possess the same robustness in funding and technical
infrastructure as a registry intending to compete with large gTLDs. Therefore purely
objective criteria such as a requirement for a certain amount of cash on hand will not
provide for the flexibility to consider different business models. The process must
provide for an objective evaluation framework, but allow for adaptation according
to the differing models applicants will present. Within that framework, applicant
responses will be evaluated against the criteria in light of the proposed model.
 Therefore the criteria should be flexible: able to scale with the overall business
approach, providing that the planned approach is consistent and coherent, and
can withstand highs and lows.     A-2
 Criteria can be objective in areas of registrant protection, for example:
 Providing for funds to continue operations in the event of a registry failure.
 Adherence to data escrow, registry failover, and continuity planning
requirements.
 The evaluation must strike the correct balance between establishing the business and
technical competence of the applicant to operate a registry (to serve the interests of
registrants), while not asking for the detailed sort of information or making the judgment
that a venture capitalist would. ICANN is not seeking to certify business success but
instead seeks to encourage innovation while providing certain safeguards for registrants.
 New registries must be added in a way that maintains DNS stability and security.
Therefore, ICANN asks several questions so that the applicant can demonstrate an
understanding of the technical requirements to operate a registry.  ICANN will ask the
applicant to demonstrate actual operational technical compliance prior to delegation.
This is in line with current prerequisites for the delegation of a TLD.
 Registrant protection is emphasized in both the criteria and the scoring. Examples of this
include asking the applicant to:
 Plan for the occurrence of contingencies and registry failure by putting in place
financial resources to fund the ongoing resolution of names while a replacement
operator is found or extended notice can be given to registrants,
 Demonstrate a capability to understand and plan for business contingencies to
afford some protections through the marketplace,
 Adhere to DNS stability and security requirements as described in the technical
section, and
 Provide access to the widest variety of services.
II. Aspects of the Questions Asked in the Application and Evaluation Criteria
The technical and financial questions are intended to inform and guide the applicant in aspects
of registry start-up and operation. The established registry operator should find the questions
straightforward while inexperienced applicants should find them a natural part of planning.
Evaluation and scoring (detailed below) will emphasize:
 How thorough are the answers? Are they well thought through and do they provide a
sufficient basis for evaluation?
 Demonstration of the ability to operate and fund the registry on an ongoing basis:
 Funding sources to support technical operations in a manner that ensures stability
and security and supports planned expenses,
 Resilience and sustainability in the face of ups and downs, anticipation of
contingencies,
 Funding to carry on operations in the event of failure.     A-3
 Demonstration that the technical plan will likely deliver on best practices for a registry
and identification of aspects that might raise DNS stability and security issues.
 Ensures plan integration, consistency and compatibility (responses to questions are not
evaluated individually but in comparison to others):
 Funding adequately covers technical requirements,
 Funding covers costs,
 Risks are identified and addressed, in comparison to other aspects of the plan.
III. Scoring
Evaluation
 The questions, criteria, scoring and evaluation methodology are to be conducted in
accordance with the principles described earlier in section I. With that in mind, globally
diverse evaluation panelists will staff evaluation panels. The diversity of evaluators and
access to experts in all regions of the world will ensure application evaluations take into
account cultural, technical and business norms in the regions from which applications
originate.
 Evaluation teams will consist of two independent panels. One will evaluate the
applications against the financial criteria. The other will evaluate the applications against
the technical & operational criteria. Given the requirement that technical and financial
planning be well integrated, the panels will work together and coordinate information
transfer where necessary. Other relevant experts (e.g., technical, audit, legal, insurance,
finance) in pertinent regions will provide advice as required.
 Precautions will be taken to ensure that no member of the Evaluation Teams will have
any interest or association that may be viewed as a real or potential conflict of interest
with an applicant or application. All members must adhere to the Code of Conduct and
Conflict of Interest guidelines that are found in Module 2.
 Communications between the evaluation teams and the applicants will be through an
online interface. During the evaluation, evaluators may pose a set of clarifying questions
to an applicant, to which the applicant may respond through the interface.
Confidentiality: ICANN will post applications after the close of the application submission
period. The application form notes which parts of the application will be posted.
Scoring
 Responses will be evaluated against each criterion. A score will be assigned according
to the scoring schedule linked to each question or set of questions. In several questions, 1
point is the maximum score that may be awarded. In several other questions, 2 points are
awarded for a response that exceeds requirements, 1 point is awarded for a response
that meets requirements and 0 points are awarded for a response that fails to meet
requirements. Each question must receive at least a score of “1,” making each a
“pass/fail” question.
 In the Continuity question in the financial section(see Question #50), up to 3 points are
awarded if an applicant provides, at the application stage, a financial instrument that
will guarantee ongoing registry operations in the event of a business failure. This extra     A-4
point can serve to guarantee passing the financial criteria for applicants who score the
minimum passing score for each of the individual criteria. The purpose of this weighting is
to reward applicants who make early arrangements for the protection of registrants and
to accept relatively riskier business plans where registrants are protected.
 There are 21 Technical & Operational questions. Each question has a criterion and
scoring associated with it. The scoring for each is 0, 1, or 2 points as described above.
One of the questions (IDN implementation) is optional. Other than the optional questions,
all Technical & Operational criteria must be scored a 1 or more or the application will fail
the evaluation.
 The total technical score must be equal to or greater than 22 for the application to pass.
That means the applicant can pass by:
 Receiving a 1 on all questions, including the optional question, and a 2 on at least
one mandatory question; or
 Receiving a 1 on all questions, excluding the optional question and a 2 on at least
two mandatory questions.  
This scoring methodology requires a minimum passing score for each question and a
slightly higher average score than the per question minimum to pass.
 There are six Financial questions and six sets of criteria that are scored by rating the
answers to one or more of the questions. For example, the question concerning registry
operation costs requires consistency between the technical plans (described in the
answers to the Technical & Operational questions) and the costs (described in the
answers to the costs question).
 The scoring for each of the Financial criteria is 0, 1 or 2 points as described above with
the exception of the Continuity question, for which up to 3 points are possible. All
questions must receive at least a 1 or the application will fail the evaluation.
 The total financial score on the six criteria must be 8 or greater for the application to
pass. That means the applicant can pass by:
 Scoring a 3 on the continuity criteria, or
 Scoring a 2 on any two financial criteria.
 Applications that do not pass Initial Evaluation can enter into an extended evaluation
process as described in Module 2. The scoring is the same.
 
   A-5
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
Applicant
Information
1 Full legal name of the Applicant (the established
entity that would enter into a Registry Agreement
with ICANN)
Y Responses to Questions 1 - 12 are required
for a complete application.  Responses are
not scored.
2 Address of the principal place of business of the
Applicant. This address will be used for
contractual purposes. No Post Office boxes are
allowed.
Y
3 Phone number for the Applicant’s principal place
of business.
Y
4 Fax number for the Applicant’s principal place of
business.
Y
5 Website or URL, if applicable. Y
Primary Contact for
this Application
6 Name Y The primary contact will receive all
communications regarding the application.
Either the primary or the secondary contact
may respond. In the event of a conflict, the
communication received from the primary
contact will be taken as authoritative. Both
contacts listed should also be prepared to
receive inquiries from the public.
Title Y
Address Y
Phone number Y
Fax number Y
Email address Y
Secondary Contact
for this Application
7 Name Y The secondary contact will be copied on all
communications regarding the application.
Either the primary or the secondary contact
may respond.
Title Y
Address Y
Phone number Y
Fax number Y
Email address Y
Proof of Legal
Establishment
8 (a) Legal form of the Applicant. (e.g., partnership,
corporation, non-profit institution).   YA-6
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
(b) State the specific national or other jurisdiction
that defines the type of entity identified in 8(a).
Y In the event of questions regarding proof of
establishment, the applicant may be asked
for additional details, such as the specific
national or other law applying to this type of
entity
(c) Attach evidence of the applicant’s
establishment as the type of entity identified in
Question 8(a) above, in accordance with the
applicable laws identified in Question 8(b).
Y Applications without valid proof of legal
establishment will not be evaluated further.
9 (a) If the applying entity is publicly traded, provide
the exchange and symbol.
Y
(b) If the applying entity is a subsidiary, provide
the parent company.
Y
(c) If the applying entity is a joint venture, list all
joint venture partners.
Y
10 Business ID, Tax ID, VAT registration number, or
equivalent of the Applicant.
N
Applicant
Background
11 (a) Enter the full name, contact information
(permanent residence), and position of all
directors (i.e., members of the applicant’s Board
of Directors, if applicable).
Partial Applicants should be aware that the names
and positions of the individuals listed in
response to this question will be published
as part of the application. The contact
information listed for individuals is for
identification purposes only and will not be
published as part of the application.
Background checks may be conducted on
individuals named in the applicant’s
response to question 11. Any material
misstatement or misrepresentation (or
omission of material information) may cause
the application to be rejected.
The applicant certifies that it has obtained
permission for the posting of the names and
positions of individuals included in this
application.
(b) Enter the full name, contact information
(permanent residence), and position of all officers
and partners. Officers are high-level management
officials of a corporation or business, for example,
a CEO, vice president, secretary, chief financial
officer. Partners would be listed in the context of
a partnership or other such form of legal entity.
PartialA-7
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
(c) Enter the full name, contact information
(permanent residence of individual or principal
place of business of entity) and position of all
shareholders holding at least 15% of shares, and
percentage held by each.
Partial
(d) For an applying entity that does not have
directors, officers, partners, or shareholders,
enter the full name, contact information
(permanent residence of individual or principal
place of business of entity) and position of all
individuals having overall legal or executive
responsibility for the applying entity.
Partial
(e) Indicate whether the applicant or any of the
individuals named above:
i. within the past ten years, has been convicted of
any crime related to financial or corporate
governance activities, or has been judged by a
court to have committed fraud or breach of
fiduciary duty, or has been the subject of a
judicial determination that is the substantive
equivalent of any of these;
ii. within the past ten years, has been disciplined
by any government or industry regulatory body
for conduct involving dishonesty or misuse of
funds of others;
iii.  within the past ten years has been convicted
of any willful tax-related fraud or willful evasion of
tax liabilities;
iv.  within the past ten years has been convicted
of perjury, forswearing, failing to cooperate with a
law enforcement investigation, or making false
statements to a law enforcement agency or
representative;
v.  has ever been convicted of any crime
involving the use of computers, telephony
systems, telecommunications or the Internet to
facilitate the commission of crimes;
vi. has ever been convicted of any crime involving
the use of a weapon, force, or the threat of force;
vii.  has ever been convicted of any violent or
sexual offense victimizing children, the elderly, or
N ICANN may deny an otherwise qualified
application based on the background
screening process. See section 1.2.1 of the
guidebook.A-8
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
individuals with disabilities;
viii. has ever been convicted of the illegal sale,
manufacture, or distribution of pharmaceutical
drugs, or been convicted or successfully
extradited for any offense described in Article 3 of
the United Nations Convention Against Illicit
Traffic in Narcotic Drugs and Psychotropic
Substances of 1988;
ix. has ever been convicted or successfully
extradited for any offense described in the United
Nations Convention against Transnational
Organized Crime (all Protocols);
x. has been convicted, within the respective
timeframes, of aiding, abetting, facilitating,
enabling, conspiring to commit, or failing to report
any of the listed crimes (i.e., within the past 10
years for crimes listed in (i) - (iv) above, or ever
for the crimes listed in (v) – (ix) above);
xi. has entered a guilty plea as part of a plea
agreement or has a court case in any jurisdiction
with a disposition of Adjudicated Guilty or
Adjudication Withheld (or regional equivalents)
within the respective timeframes listed above for
any of the listed crimes (i.e., within the past 10
years for crimes listed in (i) – (iv) above, or ever
for the crimes listed in (v) – (ix) above);
xii. is the subject of a disqualification imposed by
ICANN and in effect at the time of this
application.
If any of the above events have occurred, please
provide details.
(f) Indicate whether the applicant or any of the
individuals named above have been involved in
any decisions indicating that the applicant or
individual named in the application was engaged
in cybersquatting, as defined in the Uniform
Domain Name Dispute Resolution Policy
(UDRP), Anti-cybersquatting Consumer
Protection Act (ACPA), or other equivalent
legislation, or was engaged in reverse domain
name hijacking under the UDRP or bad faith or
reckless disregard under the ACPA or equivalent
N ICANN may deny an otherwise qualified
application based on the background
screening process.  See section 1.2.1 of the
guidebook for details.A-9
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
legislation.
(g) Disclose whether the applicant or any of the
individuals named above has been involved in
any administrative or other legal proceeding in
which allegations of intellectual property
infringement relating to registration or use of a
domain name have been made.  Provide an
explanation related to each such instance.
N ICANN may deny an otherwise qualified
application based on the background
screening process.  See section 1.2.1 of the
guidebook for details.
(h) Provide an explanation for any additional
background information that may be found
concerning the applicant or any individual named
in the application, which may affect eligibility,
including any criminal convictions not identified
above.
N
Evaluation Fee 12 (a) Enter the confirmation information for
payment of the evaluation fee (e.g., wire transfer
confirmation number).
N The evaluation fee is paid in the form of a
deposit at the time of user registration, and
submission of the remaining amount at the
time the full application is submitted. The
information in question 12 is required for
each payment.
The full amount in USD must be received by
ICANN. Applicant is responsible for all
transaction fees and exchange rate
fluctuation.
Fedwire is the preferred wire mechanism;
SWIFT is also acceptable. ACH is not
recommended as these funds will take
longer to clear and could affect timing of the
application processing.
(b) Payer name N
(c) Payer address N
(d) Wiring bank N
(e) Bank address NA-10
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
(f) Wire date N
Applied-for gTLD
string
13 Provide the applied-for gTLD string. If applying
for an IDN, provide the U-label.
Y Responses to Questions 13-17 are not
scored, but are used for database and
validation purposes.
The U-label is an IDNA-valid string of
Unicode characters, including at least one
non-ASCII character.
14 (a) If applying for an IDN, provide the A-label
(beginning with “xn--“).
Y
(b) If an IDN, provide the meaning, or
restatement of the string in English, that is, a
description of the literal meaning of the string in
the opinion of the applicant.
Y
(c) If an IDN, provide the language of the label
(both in English and as referenced by ISO-639-
1).
Y
(d) If an IDN, provide the script of the label (both
in English and as referenced by ISO 15924).
Y
(e) If an IDN, list all code points contained in the
U-label according to Unicode form.
Y For example, the string “HELLO” would be
listed as U+0048 U+0065 U+006C U+006C
U+006F.
15 (a) If an IDN, upload IDN tables for the
proposed registry.  An IDN table must include:
1. the applied-for gTLD string relevant to the
tables,
2. the script or language designator (as
defined in BCP 47),
3. table version number,
4. effective date (DD Month YYYY), and
5. contact name, email address, and phone
number.
Submission of IDN tables in a standards-based
format is encouraged.
Y In the case of an application for an IDN
gTLD, IDN tables must be submitted for the
language or script for the applied-for gTLD
string. IDN tables must also be submitted for
each language or script in which the
applicant intends to offer IDN registrations at
the second level.
(b) Describe the process used for
development of the IDN tables submitted,
including consultations and sources used.
Y
(c) List any variants to the applied-for gTLD
string according to the relevant IDN tables.
Y Variant TLD strings will not be delegated as
a result of this application. Variant strings
will be checked for consistency and, if the
application is approved, will be entered on a
Declared IDN Variants List to allow for future A-11
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
allocation once a variant management
mechanism is established for the top level.
Inclusion of variant TLD strings in this
application is for information only and
confers no right or claim to these strings
upon the applicant.
16 Describe the applicant's efforts to ensure that
there are no known operational or rendering
problems concerning the applied-for gTLD string.
If such issues are known, describe steps that will
be taken to mitigate these issues in software and
other applications.
   Y
17 OPTIONAL.
Provide a representation of the label according to
the International Phonetic Alphabet
(http://www.langsci.ucl.ac.uk/ipa/).
Y If provided, this information will be used as a
guide to ICANN in communications
regarding the application.
Mission/Purpose 18 (a) Describe the mission/purpose of your
proposed gTLD.
Y The information gathered in response to
Question 18 is intended to inform the postlaunch review of the New gTLD Program,
from the perspective of assessing the
relative costs and benefits achieved in the
expanded gTLD space.
For the application to be considered
complete, answers to this section must be
fulsome and sufficiently quantitative and
detailed to inform future study on plans vs.
results.
The New gTLD Program will be reviewed, as
specified in section 9.3 of the Affirmation of
Commitments. This will include
consideration of the extent to which the
introduction or expansion of gTLDs has
promoted competition, consumer trust and
consumer choice, as well as effectiveness of
(a) the application and evaluation process,
and (b) safeguards put in place to mitigate
issues involved in the introduction or
expansion.
The information gathered in this section will
be one source of input to help inform this
review. This information is not used as part
of the evaluation or scoring of the
application, except to the extent that the
information may overlap with questions or
evaluation areas that are scored.A-12
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
An applicant wishing to designate this
application as community-based should
ensure that these responses are consistent
with its responses for question 20 below.    
(b) How do you expect that your proposed gTLD
will benefit registrants, Internet users, and
others?
Y Answers should address the following points:
 
i. What is the goal of your
proposed gTLD in terms of
areas of specialty, service
levels, or reputation?
ii. What do you anticipate your
proposed gTLD will add to the
current space, in terms of
competition, differentiation, or
innovation?  
iii. What goals does your
proposed gTLD have in terms
of user experience?  
iv. Provide a complete description
of the applicant’s intended
registration policies in support
of the goals listed above.  
v. Will your proposed gTLD
impose any measures for
protecting the privacy or
confidential information of
registrants or users? If so,
please describe any such
measures.
Describe whether and in what ways outreach
and communications will help to achieve your
projected benefits.
18 (c) What operating rules will you adopt to
eliminate or minimize social costs (e.g., time
or financial resource costs, as well as
various types of consumer vulnerabilities)?
What other steps will you take to minimize
negative consequences/costs imposed upon
consumers?
i.
Y Answers should address the following points:
i. How will multiple applications
for a particular domain name
be resolved, for example, by
auction or on a first-come/firstserve basis?
ii. Explain any cost benefits for
registrants you intend to A-13
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
implement (e.g., advantageous
pricing, introductory discounts,
bulk registration discounts).
iii. Note that the Registry
Agreement requires that
registrars be offered the option
to obtain initial domain name
registrations for periods of one
to ten years at the discretion of
the registrar, but no greater
than ten years. Additionally,
the Registry Agreement
requires advance written
notice of price increases. Do
you intend to make contractual
commitments to registrants
regarding the magnitude of
price escalation? If so, please
describe your plans.
Community-based
Designation
19 Is the application for a community-based TLD? Y There is a presumption that the application
is a standard application (as defined in the
Applicant Guidebook) if this question is left
unanswered.
The applicant’s designation as standard or
community-based cannot be changed once
the application is submitted.
20 (a) Provide the name and full description of the
community that the applicant is committing to
serve. In the event that this application is
included in a community priority evaluation, it will
be scored based on the community identified in
response to this question. The name of the
community does not have to be formally adopted
for the application to be designated as
community-based.
Y Descriptions should include:
• How the community is delineated
from Internet users generally.  Such
descriptions may include, but are not
limited to, the following:  membership,
registration, or licensing processes,
operation in a particular industry, use
of a language.
• How the community is structured and
organized. For a community
consisting of an alliance of groups,
details about the constituent parts are
required.
• When the community was
established, including the date(s) of
formal organization, if any, as well as
a description of community activities
to date.
Responses to Question 20
will be regarded as firm
commitments to the specified
community and reflected in
the Registry Agreement,
provided the application is
successful.
Responses are not scored in
the Initial Evaluation.
Responses may be scored in
a community priority
evaluation, if applicable.
Criteria and scoring
methodology for the
community priority evaluation
are described in Module 4 of
the Applicant Guidebook.A-14
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
• The current estimated size of the
community, both as to membership
and geographic extent.
(b) Explain the applicant’s relationship to the
community identified in 20(a).
Y Explanations should clearly state:
• Relations to any community
organizations.
• Relations to the community and its
constituent parts/groups.
• Accountability mechanisms of the
applicant to the community.
(c) Provide a description of the community-based
purpose of the applied-for gTLD.
Y Descriptions should include:
• Intended registrants in the TLD.
• Intended end-users of the TLD.
• Related activities the applicant has
carried out or intends to carry out in
service of this purpose.
• Explanation of how the purpose is of
a lasting nature.
(d)  Explain the relationship between the appliedfor gTLD string and the community identified in
20(a).
Y Explanations should clearly state:
• relationship to the established name,
if any, of the community.
• relationship to the identification of
community members.
• any connotations the string may have
beyond the community.
(e)  Provide a complete description of the
applicant’s intended registration policies in
support of the community-based purpose of the
applied-for gTLD. Policies and enforcement
mechanisms are expected to constitute a
coherent set.  
Y Descriptions should include proposed
policies, if any, on the following:
• Eligibility:  who is eligible to register a
second-level name in the gTLD, and
how will eligibility be determined.
• Name selection:  what types of
second-level names may be
registered in the gTLD.
• Content/Use:  what restrictions, if
any, the registry operator will impose
on how a registrant may use its
registered name.
• Enforcement:  what investigation
practices and mechanisms exist to
enforce the policies above, what
resources are allocated for A-15
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
enforcement, and what appeal
mechanisms are available to
registrants.
(f) Attach any written endorsements for the
application from established institutions
representative of the community identified in
20(a). An applicant may submit written
endorsements by multiple institutions, if relevant
to the community.
Y At least one such endorsement is required
for a complete application. The form and
content of the endorsement are at the
discretion of the party providing the
endorsement; however, the letter must
identify the applied-for gTLD string and the
applying entity, include an express
statement support for the application, and
the supply the contact information of the
entity providing the endorsement.
Endorsements from institutions not
mentioned in the response to 20(b) should
be accompanied by a clear description of
each such institution's relationship to the
community.
Geographic Names 21 (a) Is the application for a geographic name? Y An applied-for gTLD string is considered a
geographic name requiring government
support if it is: (a) the capital city name of a
country or territory listed in the ISO 3166-1
standard; (b) a city name, where it is clear
from statements in the application that the
applicant intends to use the gTLD for
purposes associated with the city name; (c)
a sub-national place name listed in the ISO
3166-2 standard; or (d) a name listed as a
UNESCO region or appearing on the
“Composition of macro geographic
(continental) or regions, geographic subregions, and selected economic and other
groupings” list. See Module 2 for complete
definitions and criteria.    
An application for a country or territory
name, as defined in the Applicant
Guidebook, will not be approved.
(b) If a geographic name, attach documentation
of support or non-objection from all relevant
governments or public authorities.
N See the documentation requirements in
Module 2 of the Applicant Guidebook.
Protection of
Geographic Names
22 Describe proposed measures for protection of
geographic names at the second and other levels
in the applied-for gTLD. This should include any
applicable rules and procedures for reservation
and/or release of such names.
Y
Applicants should consider and describe
how they will incorporate Governmental
Advisory Committee (GAC) advice in their
management of second-level domain name A-16
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
registrations. See “Principles regarding New
gTLDs” at
https://gacweb.icann.org/display/gacweb/Ne
w+gTLDs.
For reference, applicants may draw on
existing methodology developed for the
reservation and release of country names in
the .INFO top-level domain. See
https://gacweb.icann.org/display/gacweb/Ne
w+gTLDs.
Proposed measures will be posted for public
comment as part of the application.
However, note that procedures for release
of geographic names at the second level
must be separately approved according to
Specification 5 of the Registry Agreement.
Registry Services 23 Provide name and full description of all the
Registry Services to be provided.  Descriptions
should include both technical and business
components of each proposed service, and
address any potential security or stability
concerns.
The following registry services are customary
services offered by a registry operator:
A. Receipt of data from registrars concerning
registration of domain names and name
servers.
B. Dissemination of TLD zone files.
C. Dissemination of contact or other information
concerning domain name registrations
(Whois service).
D. Internationalized Domain Names, where
offered.
E. DNS Security Extensions (DNSSEC).
The applicant must describe whether any of
these registry services are intended to be offered
in a manner unique to the TLD.
Additional proposed registry services that are
Y Registry Services are defined as the
following:  (1) operations of the Registry
critical to the following tasks: (i) the receipt
of data from registrars concerning
registrations of domain names and name
servers; (ii) provision to registrars of status
information relating to the zone servers for
the TLD; (iii) dissemination of TLD zone
files; (iv) operation of the Registry zone
servers; and (v) dissemination of contact
and other information concerning domain
name server registrations in the TLD as
required by the Registry Agreement; and (2)
other products or services that the Registry
Operator is required to provide because of
the establishment of a Consensus Policy;
(3) any other products or services that only
a Registry Operator is capable of providing,
by reason of its designation as the Registry
Operator. A full definition of Registry
Services can be found at
http://www.icann.org/en/registries/rsep/rsep.
html.
Security:  For purposes of this Applicant
Guidebook, an effect on security by the
proposed Registry Service means (1) the
unauthorized disclosure, alteration, insertion
or destruction of Registry Data, or (2) the
unauthorized access to or disclosure of
   Responses are not scored. A
preliminary assessment will
be made to determine if
there are potential security or
stability issues with any of
the applicant's proposed
Registry Services. If any
such issues are identified,
the application will be
referred for an extended
review. See the description
of the Registry Services
review process in Module 2
of the Applicant Guidebook.
Any information contained in
the application may be
considered as part of the
Registry Services review.
If its application is approved,
applicant may engage in only
those registry services
defined in the application,
unless a new request is
submitted to ICANN in
accordance with the Registry
Agreement. A-17
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
unique to the registry must also be described. information or resources on the Internet by
systems operating in accordance with
applicable standards.
Stability:  For purposes of this Applicant
Guidebook, an effect on stability shall mean
that the proposed Registry Service (1) is not
compliant with applicable relevant standards
that are authoritative and published by a
well-established, recognized and
authoritative standards body, such as
relevant Standards-Track or Best Current
Practice RFCs sponsored by the IETF, or (2)
creates a condition that adversely affects
the throughput, response time, consistency
or coherence of responses to Internet
servers or end systems, operating in
accordance with applicable relevant
standards that are authoritative and
published by a well-established, recognized
and authoritative standards body, such as
relevant Standards-Track or Best Current
Practice RFCs and relying on Registry
Operator's delegation information or
provisioning.
Demonstration of
Technical &
Operational
Capability
(External)
24 Shared Registration System (SRS) Performance:
describe
• the plan for operation of a robust and
reliable SRS. SRS is a critical registry
function for enabling multiple registrars to
provide domain name registration services
in the TLD. SRS must include the EPP
interface to the registry, as well as any
other interfaces intended to be provided, if
they are critical to the functioning of the
registry. Please refer to the requirements
in Specification 6 (section 1.2) and
Specification 10 (SLA Matrix) attached to
the Registry Agreement; and
• resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the criteria
(number and description of personnel
roles allocated to this area).
   A complete answer should include, but is not
limited to:
• A high-level SRS system description;
Y The questions in this section (24-44) are
intended to give applicants an opportunity to
demonstrate their technical and operational
capabilities to run a registry. In the event
that an applicant chooses to outsource one
or more parts of its registry operations, the
applicant should still provide the full details
of the technical arrangements.
Note that the resource plans provided in this
section assist in validating the technical and
operational plans as well as informing the
cost estimates in the Financial section
below.
Questions 24-30(a) are designed to provide
a description of the applicant’s intended
technical and operational approach for those
registry functions that are outward-facing,
i.e., interactions with registrars, registrants,
and various DNS users. Responses to these
questions will be published to allow review
by affected parties.
0-1 Complete answer
demonstrates:
(1) a plan for operating a
robust and reliable SRS, one
of the five critical registry
functions;
(2) scalability and
performance consistent with
the overall business
approach, and planned size
of the registry;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section; and
(4) evidence of compliance
with Specification 6 (section
1.2) to the Registry
Agreement.
1 - meets requirements:  Response
includes
(1) An adequate description of SRS
that substantially demonstrates the
applicant’s capabilities and
knowledge required to meet this
element;
(2) Details of a well-developed plan to
operate a robust and reliable SRS;
(3) SRS plans are sufficient to result in
compliance with Specification 6 and
Specification 10 to the Registry
Agreement;
(4) SRS is consistent with the technical,
operational and financial approach
described in the application; and
(5) Demonstrates that adequate
technical resources are already on
hand, or committed or readily
available to carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.A-18
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
• Representative network diagram(s);
• Number of servers;
• Description of interconnectivity with other
registry systems;
• Frequency of synchronization between
servers; and
• Synchronization scheme (e.g., hot
standby, cold standby).
A complete answer is expected to be no more than
5 pages. (As a guide, one page contains
approximately 4000 characters).
25 Extensible Provisioning Protocol (EPP): provide a
detailed description of the interface with
registrars, including how the applicant will comply
with EPP in RFCs 3735 (if applicable), and 5730-
5734.
If intending to provide proprietary EPP
extensions, provide documentation consistent
with RFC 3735, including the EPP templates and
schemas that will be used.
Describe resourcing plans (number and
description of personnel roles allocated to this
area).
A complete answer is expected to be no more
than 5 pages. If there are proprietary EPP
extensions, a complete answer is also expected
to be no more than 5 pages per EPP extension.
Y 0-1 Complete answer
demonstrates:
(1) complete knowledge and
understanding of this aspect
of registry technical
requirements;
(2) a technical plan
scope/scale consistent with
the overall business
approach and planned size
of the registry; and
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section;
(4) ability to comply with
relevant RFCs;
(5) if applicable, a welldocumented implementation
of any proprietary EPP
extensions; and
(6) if applicable, how
proprietary EPP extensions
are consistent with the
registration lifecycle as
described in Question 27.
1 - meets requirements:  Response
includes
(1) Adequate description of EPP  that
substantially demonstrates the
applicant’s capability and
knowledge required to meet this
element;
(2) Sufficient evidence that any
proprietary EPP extensions are
compliant with RFCs and provide all
necessary functionalities for the
provision of registry services;
(3) EPP interface is consistent with the
technical, operational, and financial
approach as described in the
application; and
(4) Demonstrates that technical
resources are already on hand, or
committed or readily available.
0 - fails requirements:
Does not meet all the requirements to
score 1.A-19
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
26 Whois: describe
• how the applicant will comply with Whois
specifications for data objects, bulk
access, and lookups as defined in
Specifications 4 and 10 to the Registry
Agreement;
• how the Applicant's Whois service will
comply with RFC 3912; and
• resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
A complete answer should include, but is not limited
to:
• A high-level Whois system description;
• Relevant network diagram(s);
• IT and infrastructure resources (e.g.,
servers, switches, routers and other
components);
• Description of interconnectivity with other
registry systems; and
• Frequency of synchronization between
servers.
To be eligible for a score of 2, answers must also
include:
• Provision for Searchable Whois
capabilities; and
• A description of potential forms of abuse of
this feature, how these risks will be
mitigated, and the basis for these
descriptions.
A complete answer is expected to be no more than
5 pages.
Y The Registry Agreement (Specification 4)
requires provision of Whois lookup services for
all names registered in the TLD. This is a
minimum requirement. Provision for
Searchable Whois as defined in the scoring
column is a requirement for achieving a score
of 2 points.
0-2 Complete answer
demonstrates:
(1) complete knowledge and
understanding of this aspect
of registry technical
requirements, (one of the five
critical registry functions);
(2) a technical plan
scope/scale consistent with
the overall business
approach and planned size
of the registry;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section;
(4) ability to comply with
relevant RFCs;
(5) evidence of compliance
with Specifications 4 and 10
to the Registry Agreement;
and
(6) if applicable, a welldocumented implementation
of Searchable Whois.
2 – exceeds requirements:  Response
meets all the attributes for a score of 1
and includes:
(1) A Searchable Whois service:  Whois
service includes web-based search
capabilities by domain name,
registrant name, postal address,
contact names, registrar IDs, and
Internet Protocol addresses without
arbitrary limit. Boolean search
capabilities may be offered. The
service shall include appropriate
precautions to avoid abuse of this
feature (e.g., limiting access to
legitimate authorized users), and
the application demonstrates
compliance with any applicable
privacy laws or policies.
1 - meets requirements:  Response
includes
(1) adequate description of Whois
service that substantially
demonstrates the applicant’s
capability and knowledge required
to meet this element;
(2) Evidence that Whois services are
compliant with RFCs, Specifications
4 and 10 to the Registry Agreement,
and any other contractual
requirements including all
necessary functionalities for user
interface;
(3) Whois capabilities consistent with
the technical, operational, and
financial approach as described in
the application; and
(4) demonstrates an adequate level of
resources that are already on hand
or readily available to carry out this
function.
0 - fails requirements:
Does not meet all the requirements to
score 1.A-20
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
27 Registration Life Cycle: provide a detailed
description of the proposed registration lifecycle
for domain names in the proposed gTLD. The
description must:
•    explain the various registration states as
well as the criteria and procedures that
are used to change state;
•    describe the typical registration lifecycle
of create/update/delete and all
intervening steps such as pending,
locked, expired, and transferred that
may apply;
•    clearly explain any time elements that
are involved - for instance details of
add-grace or redemption grace periods,
or notice periods for renewals or
transfers; and
•    describe resourcing plans for this aspect
of the criteria (number and description
of personnel roles allocated to this
area).
The description of the registration lifecycle
should be supplemented by the inclusion of a
state diagram, which captures definitions,
explanations of trigger points, and transitions
from state to state.
If applicable, provide definitions for aspects of
the registration lifecycle that are not covered by
standard EPP RFCs.
A complete answer is expected to be no more
than 5 pages.
Y 0-1 Complete answer
demonstrates:
(1) complete knowledge and
understanding of registration
lifecycles and states;
(2) consistency with any
specific commitments made
to registrants as adapted to
the overall business
approach for the proposed
gTLD; and
(3) the ability to comply with
relevant RFCs.
1 - meets requirements: Response
includes
(1) An adequate description of the
registration lifecycle that
substantially demonstrates the
applicant’s capabilities and
knowledge required to meet this
element;
(2) Details of a fully developed
registration life cycle with definition
of various registration states,
transition between the states, and
trigger points;
(3) A registration lifecycle that is
consistent with any commitments to
registrants and with technical,
operational, and financial plans
described in the application; and
(4) Demonstrates an adequate level of
resources that are already on hand
or committed or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.
28 Abuse Prevention and Mitigation:  Applicants
should describe the proposed policies and
procedures to minimize abusive registrations and
other activities that have a negative impact on
Internet users. A complete answer should
include, but is not limited to:
• An implementation plan to establish and
publish on its website a single abuse point
of contact responsible for addressing
matters requiring expedited attention and
providing a timely response to abuse
complaints concerning all names
registered in the TLD through all registrars
of record, including those involving a
reseller;
Y Note that, while orphan glue often supports
correct and ordinary operation of the DNS,
registry operators will be required to take
action to remove orphan glue records (as
defined at
http://www.icann.org/en/committees/security/s
ac048.pdf) when provided with evidence in
written form that such records are present in
connection with malicious conduct.
0-2 Complete answer
demonstrates:
(1) Comprehensive abuse
policies, which include
clear definitions of what
constitutes abuse in the
TLD, and procedures
that will effectively
minimize potential for
abuse in the TLD;
(2) Plans are adequately
resourced in the planned
costs detailed in the
financial section;
2 – exceeds requirements:  Response
meets all the attributes for a score of 1
and includes:
(1) Details of measures to promote
Whois accuracy, using measures
specified here or other measures
commensurate in their
effectiveness; and
(2) Measures from at least one
additional area to be eligible for 2
points as described in the question.
1 - meets requirements
Response includes:
(1) An adequate description of abuse
prevention and mitigation policies A-21
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
• Policies for handling complaints regarding
abuse;
• Proposed measures for removal of orphan
glue records for names removed from the
zone when provided with evidence in
written form that the glue is present in
connection with malicious conduct (see
Specification 6); and
• Resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the criteria
(number and description of personnel roles
allocated to this area).
To be eligible for a score of 2, answers must
include measures to promote Whois accuracy as
well as measures from one other area as
described below.
• Measures to promote Whois accuracy (can
be undertaken by the registry directly or by
registrars via requirements in the RegistryRegistrar Agreement (RRA)) may include,
but are not limited to:
o Authentication of registrant
information as complete and
accurate at time of registration.
Measures to accomplish this
could include performing
background checks, verifying all
contact information of principals
mentioned in registration data,
reviewing proof of establishment
documentation, and other means.
o Regular monitoring of registration
data for accuracy and
completeness, employing
authentication methods, and
establishing policies and
procedures to address domain
names with inaccurate or
incomplete Whois data; and
o If relying on registrars to enforce
measures, establishing policies
and procedures to ensure
compliance, which may include
audits, financial incentives,
penalties, or other means. Note
that the requirements of the RAA
(3) Policies and procedures
identify and address the
abusive use of
registered names at
startup and on an
ongoing basis; and
(4) When executed in
accordance with the
Registry Agreement,
plans will result in
compliance with
contractual
requirements.
and procedures that substantially
demonstrates the applicant’s
capabilities and knowledge required
to meet this element;
(2) Details of well-developed abuse
policies and procedures;
(3) Plans are sufficient to result in
compliance with contractual
requirements;
(4) Plans are consistent with the
technical, operational, and financial
approach described in the
application, and any commitments
made to registrants; and
(5) Demonstrates an adequate level of
resources that are on hand,
committed, or readily available to
carry out this function.
0 – fails requirements
Does not meet all the requirements to
score 1.A-22
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
will continue to apply to all
ICANN-accredited registrars.
• A description of policies and procedures
that define malicious or abusive behavior,
capture metrics, and establish Service
Level Requirements for resolution,
including service levels for responding to
law enforcement requests. This may
include rapid takedown or suspension
systems and sharing information regarding
malicious or abusive behavior with industry
partners;
• Adequate controls to ensure proper
access to domain functions (can be
undertaken by the registry directly or by
registrars via requirements in the RegistryRegistrar Agreement (RRA)) may include,
but are not limited to:
o Requiring multi-factor
authentication (i.e., strong
passwords, tokens, one-time
passwords) from registrants to
process update, transfers, and
deletion requests;
o Requiring multiple, unique points
of contact to request and/or
approve update, transfer, and
deletion requests; and
o Requiring the notification of
multiple, unique points of contact
when a domain has been
updated, transferred, or deleted.
A complete answer is expected to be no more
than 20 pages.
29 Rights Protection Mechanisms: Applicants must
describe how their registry will comply with
policies and practices that minimize abusive
registrations and other activities that affect the
legal rights of others, such as the Uniform
Domain Name Dispute Resolution Policy
(UDRP), Uniform Rapid Suspension (URS)
system, and Trademark Claims and Sunrise
services at startup.
A complete answer should include:
• A description of how the registry
operator will implement safeguards
Y 0-2 Complete answer describes
mechanisms designed to:
(1) prevent abusive
registrations, and
(2) identify and address the
abusive use of registered
names on an ongoing basis.
2 - exceeds requirements:  Response
meets all attributes for a score of 1 and
includes:
(1) Identification of rights protection as
a core objective, supported by a
well-developed plan for rights
protection; and
(2) Mechanisms for providing effective
protections that exceed minimum
requirements (e.g., RPMs in
addition to those required in the
registry agreement).
1 - meets requirements: Response
includesA-23
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
against allowing unqualified
registrations (e.g., registrations made
in violation of the registry’s eligibility
restrictions or policies), and reduce
opportunities for behaviors such as
phishing or pharming. At a minimum,
the registry operator must offer a
Sunrise period and a Trademark
Claims service during the required
time periods, and implement
decisions rendered under the URS
on an ongoing basis; and
•    A description of resourcing plans for the
initial implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
To be eligible for a score of 2, answers must also
include additional measures specific to rights
protection, such as abusive use policies, takedown
procedures, registrant pre-verification, or
authentication procedures, or other covenants.
A complete answer is expected to be no more than
10 pages.
(1) An adequate description of RPMs
that substantially demonstrates the
applicant’s capabilities and
knowledge required to meet this
element;
(2) A commitment from the applicant to
implement of rights protection
mechanisms sufficient to comply
with minimum requirements in
Specification 7;
(3) Plans that are sufficient to result in
compliance with contractual
requirements;
(4) Mechanisms that are consistent
with the technical, operational, and
financial approach described in the
application; and
(5) Demonstrates an adequate level of
resources that are on hand,
committed, or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score a 1.
30 (a) Security Policy: provide a summary of the
security policy for the proposed registry,
including but not limited to:
• indication of any independent assessment
reports demonstrating security capabilities,
and provisions for periodic independent
assessment reports to test security
capabilities;
• description of any augmented security
levels or capabilities commensurate with
the nature of the applied for gTLD string,
including the identification of any existing
international or industry relevant security
standards the applicant commits to
following (reference site must be
provided);
• list of commitments made to registrants
concerning security levels.
To be eligible for a score of 2, answers must also
include:
Y Criterion 5 calls for security levels to be
appropriate for the use and level of trust
associated with the TLD string, such as, for
example, financial services oriented TLDs.
“Financial services” are activities performed
by financial institutions, including:  1) the
acceptance of deposits and other repayable
funds; 2) lending; 3) payment and
remittance services; 4) insurance or
reinsurance services; 5) brokerage services;
6) investment services and activities; 7)
financial leasing; 8) issuance of guarantees
and commitments; 9) provision of financial
advice; 10) portfolio management and
advice; or 11) acting as a financial
clearinghouse. Financial services is used as
an example only; other strings with
exceptional potential to cause harm to
consumers would also be expected to
deploy appropriate levels of security.
0-2 Complete answer
demonstrates:
(1) detailed description of
processes and solutions
deployed to manage logical
security across infrastructure
and systems, monitoring and
detecting threats and
security vulnerabilities and
taking appropriate steps to
resolve them;
(2)  security capabilities are
consistent with the overall
business approach and
planned size of the registry;
(3) a technical plan
adequately resourced in the
planned costs detailed in the
financial section;
(4) security measures are
consistent with any
commitments made to
registrants regarding security
2 - exceeds requirements:  Response
meets all attributes for a score of 1 and
includes:
(1) Evidence of highly developed and
detailed security capabilities, with
various baseline security levels,
independent benchmarking of
security metrics, robust periodic
security monitoring, and continuous
enforcement; and
(2) an independent assessment report
is provided demonstrating effective
security controls are either in place
or have been designed, and are
commensurate with the applied-for
gTLD string. (This could be ISO
27001 certification or other wellestablished and recognized industry
certifications for the registry
operation. If new independent
standards for demonstration of
effective security controls are
established, such as the High A-24
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
• Evidence of an independent assessment
report demonstrating effective security
controls (e.g., ISO 27001).
A summary of the above should be no more than 20
pages. Note that the complete security policy for the
registry is required to be submitted in accordance
with 30(b).
levels; and
(5) security measures are
appropriate for the appliedfor gTLD string (For
example, applications for
strings with unique trust
implications, such as
financial services-oriented
strings, would be expected to
provide a commensurate
level of security).
Security Top Level Domain
(HSTLD) designation, this could
also be included.)
1 - meets requirements:  Response
includes:
(1) Adequate description of security
policies and procedures that
substantially demonstrates the
applicant’s capability and
knowledge required to meet this
element;
(2) A description of adequate security
capabilities, including enforcement
of logical access control, threat
analysis, incident response and
auditing. Ad-hoc oversight and
governance and leading practices
being followed;
(3) Security capabilities consistent with
the technical, operational, and
financial approach as described in
the application, and any
commitments made to registrants;
(4) Demonstrates that an adequate
level of  resources are on hand,
committed or readily available to
carry out this function; and
(5) Proposed security measures are
commensurate with the nature of
the applied-for gTLD string.
0 - fails requirements:  Does not meet
all the requirements to score 1.
Demonstration of
Technical &
Operational
Capability (Internal)
30 (b) Security Policy: provide the complete security
policy and procedures for the proposed
registry, including but not limited to:
• system (data, server, application /
services) and network access control,
ensuring systems are maintained in a
secure fashion, including details of how
they are monitored, logged and backed
up;
• resources to secure integrity of updates
between registry systems and
nameservers, and between nameservers,
if any;
• independent assessment reports
demonstrating security capabilities
(submitted as attachments), if any;
• provisioning and other measures that
N Questions 30(b) – 44 are designed to
provide a description of the applicant’s
intended technical and operational approach
for those registry functions that are internal
to the infrastructure and operations of the
registry. To allow the applicant to provide full
details and safeguard proprietary
information, responses to these questions
will not be published.A-25
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
mitigate risks posed by denial of service
attacks;
• computer and network incident response
policies, plans, and processes;
• plans to minimize the risk of unauthorized
access to its systems or tampering with
registry data;
• intrusion detection mechanisms, a threat
analysis for the proposed registry, the
defenses that will be deployed against
those threats, and provision for periodic
threat analysis updates;
• details for auditing capability on all network
access;
• physical security approach;
• identification of department or group
responsible for the registry’s security
organization;
• background checks conducted on security
personnel;
• description of the main security threats to
the registry operation that have been
identified; and
• resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the criteria
(number and description of personnel roles
allocated to this area).
31 Technical Overview of Proposed Registry:
provide a technical overview of the proposed
registry.
The technical plan must be adequately
resourced, with appropriate expertise and
allocation of costs. The applicant will provide
financial descriptions of resources in the next
section and those resources must be reasonably
related to these technical requirements.
The overview should include information on the
estimated scale of the registry’s technical
operation, for example, estimates for the number
of registration transactions and DNS queries per
month should be provided for the first two years
of operation.
N To the extent this answer is affected by the
applicant's intent to outsource various
registry operations, the applicant should
describe these plans (e.g., taking advantage
of economies of scale or existing facilities).
However, the response must include
specifying the technical plans, estimated
scale, and geographic dispersion as
required by the question.
0-1 Complete answer
demonstrates:
(1) complete knowledge
and understanding of
technical aspects of registry
requirements;
(2) an adequate level of
resiliency for the registry’s
technical operations;
(3) consistency with
planned or currently
deployed
technical/operational
solutions;
(4) consistency with the
overall business approach
and planned size of the
1 - meets requirements:  Response
includes:
(1) A description that substantially
demonstrates the applicant’s
capabilities and knowledge required
to meet this element;
(2) Technical plans consistent with the
technical, operational, and financial
approach as described in the
application;
(3) Demonstrates an adequate level of
resources that are on hand,
committed, or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.A-26
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
In addition, the overview should account for
geographic dispersion of incoming network traffic
such as DNS, Whois, and registrar transactions.
If the registry serves a highly localized registrant
base, then traffic might be expected to come
mainly from one area.
This high-level summary should not repeat
answers to questions below. Answers should
include a visual diagram(s) to highlight dataflows,
to provide context for the overall technical
infrastructure. Detailed diagrams for subsequent
questions should be able to map back to this
high-level diagram(s). The visual diagram(s) can
be supplemented with documentation, or a
narrative, to explain how all of the Technical &
Operational components conform.
A complete answer is expected to be no more
than 10 pages.
registry;
(5) adequate resourcing
for technical plan in the
planned costs detailed in the
financial section; and
(6) consistency with
subsequent technical
questions.
32 Architecture: provide documentation for the
system and network architecture that will support
registry operations for the proposed scale of the
registry. System and network architecture
documentation must clearly demonstrate the
applicant’s ability to operate, manage, and
monitor registry systems. Documentation should
include multiple diagrams or other components
including but not limited to:
• Detailed network diagram(s) showing the full
interplay of registry elements, including but
not limited to SRS, DNS, Whois, data
escrow, and registry database functions;
• Network and associated systems necessary
to support registry operations, including:
 Anticipated TCP / IP addressing scheme,
 Hardware (i.e., servers, routers,
networking components, virtual machines
and key characteristics (CPU and RAM,
Disk space, internal network connectivity,
and make and model)),
 Operating system and versions, and
 Software and applications (with version
information) necessary to support registry
operations, management, and monitoring
• General overview of capacity planning,
including bandwidth allocation plans;
• List of providers / carriers; and
• Resourcing plans for the initial
N 0-2 Complete answer
demonstrates:
(1) detailed and coherent
network architecture;
(2) architecture providing
resiliency for registry
systems;
(3) a technical plan
scope/scale that is consistent
with the overall business
approach and planned size
of the registry; and
(4) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section.
2 - exceeds requirements: Response
meets all attributes for a score of 1 and
includes
(1) Evidence of highly developed and
detailed network architecture that is
able to scale well above stated
projections for high registration
volumes, thereby significantly
reducing the risk from unexpected
volume surges and demonstrates
an ability to adapt quickly to support
new technologies and services that
are not necessarily envisaged for
initial registry startup; and
(2) Evidence of a highly available,
robust, and secure infrastructure.
1 - meets requirements:  Response
includes
(1) An adequate description of the
architecture that substantially
demonstrates the applicant’s
capabilities and knowledge required
to meet this element;
(2) Plans for network architecture
describe all necessary elements;
(3) Descriptions demonstrate adequate
network architecture providing
robustness and security of the A-27
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
implementation of, and ongoing maintenance
for, this aspect of the criteria (number and
description of personnel roles allocated to
this area).
To be eligible for a score of 2, answers must also
include evidence of a network architecture design
that greatly reduces the risk profile of the
proposed registry by providing a level of
scalability and adaptability (e.g., protection
against DDoS attacks) that far exceeds the
minimum configuration necessary for the
expected volume.
A complete answer is expected to be no more
than 10 pages.
registry;
(4) Bandwidth and SLA are consistent
with the technical, operational, and
financial approach as described in
the application; and
(5) Demonstrates an adequate level of
resources that are on hand, or
committed or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.
33 Database Capabilities: provide details of
database capabilities including but not limited to:
• database software;
• storage capacity (both in raw terms [e.g.,
MB, GB] and in number of registrations /
registration transactions);
• maximum transaction throughput (in total
and by type of transaction);
• scalability;
• procedures for object creation, editing, and
deletion, and user and credential
management;
• high availability;
• change management procedures;
• reporting capabilities; and
• resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the criteria
(number and description of personnel roles
allocated to this area).
A registry database data model can be included to
provide additional clarity to this response.
Note:  Database capabilities described should be in
reference to registry services and not necessarily
related support functions such as Personnel or
Accounting, unless such services are inherently
intertwined with the delivery of registry services.
To be eligible for a score of 2, answers must also
include evidence of database capabilities that
N 0-2 Complete answer
demonstrates:
(1) complete knowledge and
understanding of database
capabilities to meet the
registry technical
requirements;
(2)  database capabilities
consistent with the overall
business approach and
planned size of the registry;
and
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section.
 
2 - exceeds requirements: Response
meets all attributes for a score of 1 and
includes
(1) Highly developed and detailed
description of database capabilities
that are able to scale well above
stated projections for high
registration volumes, thereby
significantly reducing the risk from
unexpected volume surges and
demonstrates an ability to adapt
quickly to support new technologies
and services that are not
necessarily envisaged for registry
startup; and
(2) Evidence of comprehensive
database capabilities, including
high scalability and redundant
database infrastructure, regularly
reviewed operational and reporting
procedures following leading
practices.
1 - meets requirements:
Response includes
(1)   An adequate description of
database capabilities that
substantially demonstrates the
applicant’s capabilities and
knowledge required to meet this
element;
(2)   Plans for database capabilities
describe all necessary elements;
(3)   Descriptions demonstrate adequate A-28
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
greatly reduce the risk profile of the proposed
registry by providing a level of scalability and
adaptability that far exceeds the minimum
configuration necessary for the expected volume.
A complete answer is expected to be no more than
5 pages.
database capabilities, with database
throughput, scalability, and
database operations with limited
operational governance;
(4)   Database capabilities are consistent
with the technical, operational, and
financial approach as described in
the application; and
(5)      Demonstrates that an adequate
level of resources that are on hand,
or committed or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.
34 Geographic Diversity: provide a description of
plans for geographic diversity of:
a. name servers, and
b. operations centers.
Answers should include, but are not limited to:
•  the intended physical locations of
systems, primary and back-up
operations centers (including security
attributes), and other infrastructure;
•   any registry plans to use Anycast or
other topological and geographical
diversity measures, in which case, the
configuration of the relevant service
must be included;
•    resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
To be eligible for a score of 2, answers must also
include evidence of a geographic diversity plan
that greatly reduces the risk profile of the
proposed registry by ensuring the continuance of
all vital business functions (as identified in the
applicant’s continuity plan in Question 39) in the
event of a natural or other disaster) at the
principal place of business or point of presence.
A complete answer is expected to be no more
than 5 pages.
N 0-2 Complete answer
demonstrates:
(1) geographic diversity of
nameservers and operations
centers;
(2) proposed geo-diversity
measures are consistent with
the overall business
approach and planned size
of the registry; and
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section.
2 - exceeds requirements:  Response
meets all attributes for a score of 1 and
includes
(1) Evidence of highly developed
measures for geo-diversity of
operations, with locations and
functions to continue all vital
business functions in the event of a
natural or other disaster at the
principal place of business or point
of presence; and
(2) A high level of availability, security,
and bandwidth.
1 - meets requirements:  Response
includes
(1)   An adequate description of
Geographic Diversity that
substantially demonstrates the
applicant’s capabilities and
knowledge required to meet this
element;
(2)   Plans provide adequate geodiversity of name servers and
operations to continue critical
registry functions in the event of a
temporary outage at the principal
place of business or point of
presence;
(3) Geo-diversity plans are consistent
with technical, operational, and
financial approach as described in
the application; and
(4) Demonstrates adequate resourcesA-29
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
that are on hand, or committed or
readily available to carry out this
function.
0 - fails requirements:
Does not meet all the requirements to
score 1.
35 DNS Service: describe the configuration and
operation of nameservers, including how the
applicant will comply with relevant RFCs.
All name servers used for the new gTLD must be
operated in compliance with the DNS protocol
specifications defined in the relevant RFCs,
including but not limited to: 1034, 1035, 1982,
2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343,
and 4472.
•    Provide details of the intended DNS
Service including, but not limited to:   A
description of the DNS services to be
provided, such as query rates to be
supported at initial operation, and
reserve capacity of the system. How will
these be scaled as a function of growth
in the TLD? Similarly, describe how
services will scale for name server
update method and performance.
•   RFCs that will be followed – describe
how services are compliant with RFCs
and if these are dedicated or shared
with any other functions
(capacity/performance) or DNS zones.
•   The resources used to implement the
services - describe complete server
hardware and software. including
network bandwidth and addressing
plans for servers.  Also include
resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
•   Demonstrate how the system will
function - describe how the proposed
infrastructure will be able to deliver the
performance described in Specification
10 (section 2) attached to the Registry
Agreement.
N Note that the use of DNS wildcard resource
records as described in RFC 4592 or any
other method or technology for synthesizing
DNS resource records or using redirection
within the DNS by the registry is prohibited
in the Registry Agreement.
Also note that name servers for the new
gTLD must comply with IANA Technical
requirements for authoritative name servers:
http://www.iana.org/procedures/nameserverrequirements.html.
0-1 Complete answer
demonstrates:
(1) adequate description of
configurations of
nameservers and
compliance with respective
DNS protocol-related RFCs;
(2) a technical plan
scope/scale that is consistent
with the overall business
approach and planned size
of the registry;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section;
(4) evidence of compliance
with Specification 6 to the
Registry Agreement; and
(5) evidence of complete
knowledge and
understanding of
requirements for DNS
service, one of the five
critical registry functions.
1 - meets requirements:  Response
includes:
(1)  Adequate description of DNS
service that that substantially
demonstrates the applicant’s
capability and knowledge required
to meet this element;
(2)  Plans are sufficient to result in
compliance with DNS protocols
(Specification 6, section 1.1)
and required performance
specifications Specification 10,
Service Level Matrix;
(3) Plans are consistent with
technical, operational, and
financial approach as described
in the application; and
(4) Demonstrates an adequate level
of resources that are on hand, or
committed or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.A-30
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
Examples of evidence include:
• Server configuration standard (i.e.,
planned configuration).
• Network addressing and bandwidth for
query load and update propagation.
• Headroom to meet surges.
A complete answer is expected to be no more than
10 pages.
36 IPv6 Reachability: provide a description of plans
for providing IPv6 transport including, but not
limited to:
•    How the registry will support IPv6
access to Whois, Web-based Whois and
any other Registration Data Publication
Service as described in Specification 6
(section 1.5) to the Registry Agreement.
•    How the registry will comply with the
requirement in Specification 6 for having
at least two nameservers reachable
over IPv6.
•    List all services that will be provided
over IPv6, and describe the IPv6
connectivity and provider diversity that
will be used.
•    Resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
A complete answer is expected to be no more than
5 pages.
N IANA nameserver requirements are
available at
http://www.iana.org/procedures/nameserverrequirements.html.
0-1 Complete answer
demonstrates:
(1) complete knowledge and
understanding of this aspect
of registry technical
requirements;
(2) a technical plan
scope/scale that is consistent
with the overall business
approach and planned size
of the registry;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section; and
(4) evidence of compliance
with Specification 6 to the
Registry Agreement.
1 - meets requirements:  Response
includes
(1) Adequate description of IPv6
reachability that substantially
demonstrates the applicant’s
capability and knowledge required
to meet this element;
(2) A description of an adequate
implementation plan addressing
requirements for IPv6 reachability,
indicating IPv6 reachability allowing
IPv6 transport in the network over
two independent IPv6 capable
networks in compliance to IPv4
IANA specifications, and
Specification 10;
(3) IPv6 plans consistent with the
technical, operational, and financial
approach as described in the
application; and
(4)   Demonstrates an adequate level of
resources that are on hand,
committed or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.A-31
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
37 Data Backup Policies & Procedures: provide
• details of frequency and procedures for
backup of data,
• hardware, and systems used for backup,
• data format,
• data backup features,
• backup testing procedures,
• procedures for retrieval of data/rebuild of
database,
• storage controls and procedures, and
• resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the criteria
(number and description of personnel
roles allocated to this area).
A complete answer is expected to be no more
than 5 pages.
N 0-1 Complete answer
demonstrates:
(1) detailed backup and
retrieval processes deployed;
(2) backup and retrieval
process and frequency are
consistent with the overall
business approach and
planned size of the registry;
and
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section.
1 - meets requirements:  Response
includes
(1) Adequate description of backup
policies and procedures that
substantially demonstrate the
applicant’s capabilities and
knowledge required to meet this
element;
(2) A description of  leading practices
being or to be followed;
(3) Backup procedures consistent with
the technical, operational, and
financial approach as described in
the application; and
(4) Demonstrates an adequate level of
resources that are on hand, or
committed or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score a 1.
38 Data Escrow: describe
•    how the applicant will comply with the
data escrow requirements documented
in the Registry Data Escrow
Specification (Specification 2 of the
Registry Agreement); and
•    resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
A complete answer is expected to be no more than
5 pages
N 0-1 Complete answer
demonstrates:
(1) complete knowledge and
understanding of  data
escrow, one of the five
critical registry functions;
(2) compliance with
Specification 2 of the
Registry Agreement;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial  section; and
(4) the escrow arrangement
is consistent with the overall
business approach and
size/scope of the registry.
1 – meets requirements:  Response
includes
(1)  Adequate description of a Data
Escrow process that substantially
demonstrates the applicant’s
capability and knowledge required
to meet this element;
(2)  Data escrow plans are sufficient to
result in compliance with the Data
Escrow Specification (Specification
2 to the Registry Agreement);
(3)  Escrow capabilities are consistent
with the technical, operational, and
financial approach as described in
the application; and
(4)  Demonstrates an adequate level of
resources that are on hand,
committed, or readily available to
carry out this function.
0 – fails requirements:
Does not meet all the requirements to
score a 1.A-32
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
39 Registry Continuity: describe how the applicant
will comply with registry continuity obligations as
described in Specification 6 (section 3) to the
registry agreement. This includes conducting
registry operations using diverse, redundant
servers to ensure continued operation of critical
functions in the case of technical failure.
Describe resourcing plans for the initial
implementation of, and ongoing maintenance for,
this aspect of the criteria (number and description
of personnel roles allocated to this area).
The response should include, but is not limited
to, the following elements of the business
continuity plan:
•   Identification of risks and threats to
compliance with registry continuity
obligations;
•   Identification and definitions of vital
business functions (which may include
registry services beyond the five critical
registry functions) versus other registry
functions and supporting operations and
technology;
•   Definitions of Recovery Point Objectives
and Recovery Time Objective; and
•   Descriptions of testing plans to promote
compliance with relevant obligations.
To be eligible for a score of 2, answers must also
include:
• A highly detailed plan that provides for
leading practice levels of availability; and
• Evidence of concrete steps such as a
contract with a backup provider (in
addition to any currently designated
service operator) or a maintained hot site.
A complete answer is expected to be no more than
15 pages.
N For reference, applicants should review the
ICANN gTLD Registry Continuity Plan at
http://www.icann.org/en/registries/continuity/
gtld-registry-continuity-plan-25apr09-en.pdf.
A Recovery Point Objective (RPO) refers to
the point in time to which data should be
recovered following a business disruption or
disaster. The RPO allows an organization to
define a window of time before a disruption
or disaster during which data may be lost
and is independent of the time it takes to get
a system back on-line.If the RPO of a
company is two hours, then when a system
is brought back on-line after a
disruption/disaster, all data must be restored
to a point within two hours before the
disaster.
A Recovery Time Objective (RTO) is the
duration of time within which a process must
be restored after a business disruption or
disaster to avoid what the entity may deem
as unacceptable consequences. For
example, pursuant to the draft Registry
Agreement DNS service must not be down
for longer than 4 hours. At 4 hours ICANN
may invoke the use of an Emergency Back
End Registry Operator to take over this
function. The entity may deem this to be an
unacceptable consequence therefore they
may set their RTO to be something less
than 4 hours and would build continuity
plans accordingly.
Vital business functions are functions that
are critical to the success of the operation.
For example, if a registry operator provides
an additional service beyond the five critical
registry functions, that it deems as central to
its TLD, or supports an operation that is
central to the TLD, this might be identified
as a vital business function.
0-2 Complete answer
demonstrates:
(1) detailed description
showing plans for
compliance with registry
continuity obligations;
(2) a technical plan
scope/scale that is consistent
with the overall business
approach and planned size
of the registry;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section; and
(4) evidence of compliance
with Specification 6 to the
Registry Agreement.
2 - exceeds requirements:  Response
meets all attributes for a score of 1 and
includes:
(1) Highly developed and detailed
processes for maintaining registry
continuity; and
(2) Evidence of concrete steps, such as
a contract with a backup service
provider or a maintained hot site.
1 - meets requirements: Response
includes:
(1)   Adequate description of a Registry
Continuity plan that substantially
demonstrates capability and
knowledge required to meet this
element;
(2)   Continuity plans are sufficient to
result in compliance with
requirements (Specification 6);
(3) Continuity plans are consistent with
the technical, operational, and
financial approach as described in
the application; and
(4) Demonstrates an adequate level of
resources that are on hand,
committed readily available to carry
out this function.
0 - fails requirements:  Does not meet
all the requirements to score a 1.
40 Registry Transition: provide a Service Migration
plan (as described in the Registry Transition
Processes) that could be followed in the event
that it becomes necessary to permanently
transition the proposed gTLD to a new operator.
The plan must take into account, and be
N 0-1 Complete answer
demonstrates:
(1) complete knowledge and
understanding of the
Registry Transition
Processes; and
1 - meets requirements:  Response
includes
(1) Adequate description of a registry
transition plan that substantially
demonstrates the applicant’s
capability and knowledge required A-33
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
consistent with the vital business functions
identified in the previous question.
Elements of the plan may include, but are not
limited to:
• Preparatory steps needed for the
transition of critical registry functions;
• Monitoring during registry transition
and efforts to minimize any
interruption to critical registry functions
during this time; and
• Contingency plans in the event that
any part of the registry transition is
unable to move forward according to
the plan.
A complete answer is expected to be no more than
10 pages.
(2) a technical plan
scope/scale consistent with
the overall business
approach and planned size
of the registry.
to meet this element;
(2) A description  of an adequate
registry transition plan with
appropriate monitoring during
registry transition; and
(3) Transition plan is consistent with the
technical, operational, and financial
approach as described in the
application.
0 - fails requirements:  Does not meet
all the requirements to score a 1.
41 Failover Testing: provide
•    a description of the failover testing plan,
including mandatory annual testing of
the plan. Examples may include a
description of plans to test failover of
data centers or operations to alternate
sites, from a hot to a cold facility,
registry data escrow testing, or other
mechanisms. The plan must take into
account and be consistent with the vital
business functions identified in
Question 39; and
•    resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
The failover testing plan should include, but is not
limited to, the following elements:
• Types of testing (e.g., walkthroughs,
takedown of sites) and the frequency of
testing;
• How results are captured, what is done
with the results, and with whom results are
shared;
• How test plans are updated (e.g., what
triggers an update, change management
N 0-1 Complete answer
demonstrates:
(1) complete knowledge and
understanding of this aspect
of registry technical
requirements;
(2) a technical plan
scope/scale consistent with
the overall business
approach and planned size
of the registry; and
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section.
1 - meets requirements:  Response
includes
(1)  An adequate description of a failover
testing plan that substantially
demonstrates the applicant’s
capability and knowledge required
to meet this element;
(2)  A description of an adequate failover
testing plan with an appropriate
level of review and analysis of
failover testing results;  
(3)  Failover testing plan is consistent
with the technical, operational, and
financial approach as described in
the application; and
(4)  Demonstrates an adequate level of
resources that are on hand,
committed or readily available to
carry out this function.
0 – fails requirements
Does not meet all the requirements to
score a 1.A-34
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
processes for making updates);
• Length of time to restore critical registry
functions;
• Length of time to restore all operations,
inclusive of critical registry functions; and
• Length of time to migrate from one site to
another.
A complete answer is expected to be no more
than10 pages.
42 Monitoring and Fault Escalation Processes:
provide
• a description of the proposed (or actual)
arrangements for monitoring critical
registry systems (including SRS, database
systems, DNS servers, Whois service,
network connectivity, routers and
firewalls). This description should explain
how these systems are monitored and the
mechanisms that will be used for fault
escalation and reporting, and should
provide details of the proposed support
arrangements for these registry systems.
• resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the criteria
(number and description of personnel
roles allocated to this area).
To be eligible for a score of 2, answers must also
include:
•    Meeting the fault tolerance / monitoring
guidelines described
•    Evidence of commitment to provide a
24x7 fault response team.
A complete answer is expected to be no more than
10 pages.
N 0-2 Complete answer
demonstrates:
(1) complete knowledge and
understanding of this aspect
of registry technical
requirements;
(2) a technical plan
scope/scale that is consistent
with the overall business
approach and planned size
of the registry;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section; and
(4) consistency with the
commitments made to
registrants and registrars
regarding system
maintenance.
2 - exceeds requirements:  Response
meets all attributes for a score of 1 and
includes
(1)  Evidence showing highly developed
and detailed fault
tolerance/monitoring and redundant
systems deployed with real-time
monitoring tools / dashboard
(metrics) deployed and reviewed
regularly;
(2)  A high level of availability that allows
for the ability to respond to faults
through a 24x7 response team.
1 - meets requirements:  Response
includes
(1)  Adequate description of monitoring
and fault escalation processes that
substantially demonstrates the
applicant’s capability and knowledge
required to meet this element;
(2)  Evidence showing adequate fault
tolerance/monitoring systems
planned with an appropriate level of
monitoring and limited periodic
review being performed;
(3)  Plans are consistent with the
technical, operational, and financial
approach described in the
application; and
(4)  Demonstrates an adequate level of
resources that are on hand,
committed or readily available to
carry out this function.
0 - fails requirements:  Does not meet A-35
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
all the requirements to score 1.
43 DNSSEC: Provide
•   The registry’s DNSSEC policy statement
(DPS), which should include the policies
and procedures the proposed registry
will follow, for example, for signing the
zone file, for verifying and accepting DS
records from child domains, and for
generating, exchanging, and storing
keying material;
•  Describe how the DNSSEC
implementation will comply with relevant
RFCs, including but not limited to:
RFCs 4033, 4034, 4035, 5910, 4509,
4641, and 5155 (the latter will only be
required if Hashed Authenticated Denial
of Existence will be offered); and
•   resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).
A complete answer is expected to be no more
than 5 pages.  Note, the DPS is required to be
submitted as part of the application
N 0-1 Complete answer
demonstrates:
(1) complete knowledge and
understanding of this aspect
of registry technical
requirements, one of the five
critical registry functions;
(2) a technical plan
scope/scale that is consistent
with the overall business
approach and planned size
of the registry;
(3) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section; and
(4) an ability to comply with
relevant RFCs.
1 - meets requirements:  Response
includes
(1) An adequate description of
DNSSEC that substantially
demonstrates the applicant’s
capability and knowledge required
to meet this element;
(2) Evidence that TLD zone files will be
signed at time of launch, in
compliance with required RFCs,
and registry offers provisioning
capabilities to accept public key
material from registrants through
the SRS ;
(3) An adequate description of key
management procedures in the
proposed TLD, including providing
secure encryption key management
(generation, exchange, and
storage);
(4) Technical plan is consistent with the
technical, operational, and financial
approach as described in the
application; and
(5) Demonstrates an adequate level of
resources that are already on hand,
committed or readily available to
carry out this function.
0 - fails requirements:
Does not meet all the requirements to
score 1.
44 OPTIONAL.
IDNs:
•   State whether the proposed registry will
support the registration of IDN labels in
the TLD, and if so, how. For example,
explain which characters will be
supported, and provide the associated
IDN Tables with variant characters
identified, along with a corresponding
registration policy. This includes public
interfaces to the databases such as
Whois and EPP.
•   Describe how the IDN implementation
N IDNs are an optional service at time of
launch. Absence of IDN implementation or
plans will not detract from an applicant’s
score. Applicants who respond to this
question with plans for implementation of
IDNs at time of launch will be scored
according to the criteria indicated here.
0-1 IDNs are an optional service.
Complete answer
demonstrates: (1) complete
knowledge and
understanding of this aspect
of registry technical
requirements;
(2) a technical plan that is
adequately resourced in the
planned costs detailed in the
financial section;
(3) consistency with the
commitments made to
1 - meets requirements for this
optional element:  Response includes
(1) Adequate description of IDN
implementation that substantially
demonstrates the applicant’s
capability and knowledge required
to meet this element;
(2) An adequate description of the IDN
procedures, including complete IDN
tables, compliance with IDNA/IDN
guidelines and RFCs, and periodic
monitoring of IDN operations;
(3) Evidence of ability to resolve A-36
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
will comply with RFCs 5809-5893 as
well as the ICANN IDN Guidelines at
http://www.icann.org/en/topics/idn/imple
mentation-guidelines.htm.
•   Describe resourcing plans for the initial
implementation of, and ongoing
maintenance for, this aspect of the
criteria (number and description of
personnel roles allocated to this area).  
A complete answer is expected to be no more than
10 pages plus attachments.
registrants and the
technical, operational, and
financial approach described
in the application;
(4) issues regarding use of
scripts are settled and IDN
tables are complete and
publicly available; and
(5) ability to comply with
relevant RFCs.
rendering and known IDN issues or
spoofing attacks;
(4) IDN plans are consistent with the
technical, operational, and financial
approach as described in the
application; and
(5) Demonstrates an adequate level of
resources that are on hand,
committed readily available to carry
out this function.
0 - fails requirements:  Does not meet
all the requirements to score a 1.
Demonstration of
Financial Capability
45 Financial Statements: provide
•    audited or independently certified
financial statements for the most
recently completed fiscal year for the
applicant, and
•    audited or unaudited financial
statements for the most recently ended
interim financial period for the applicant
for which this information may be
released.
For newly-formed applicants, or where financial
statements are not audited, provide:
• the latest available unaudited financial
statements; and
• an explanation as to why audited or
independently certified financial
statements are not available.
At a minimum, the financial statements should
be provided for the legal entity listed as the
applicant.
Financial statements are used in the analysis of
projections and costs.
A complete answer should include:
• balance sheet;
• income statement;
• statement of shareholders equity/partner
capital;
• cash flow statement, and
• letter of auditor or independent
certification, if applicable.
N The questions in this section (45-50) are
intended to give applicants an opportunity to
demonstrate their financial capabilities to
run a registry.
0-1 Audited or independently
certified financial statements
are prepared in accordance
with International Financial
Reporting Standards (IFRS)
adopted by the International
Accounting Standards Board
(IASB) or nationally
recognized accounting
standards (e.g., GAAP). This
will include a balance sheet
and income statement
reflecting the applicant’s
financial position and results
of operations, a statement of
shareholders equity/partner
capital, and a cash flow
statement. In the event the
applicant is an entity newly
formed for the purpose of
applying for a gTLD and with
little to no operating history
(less than one year), the
applicant must submit, at a
minimum, pro forma financial
statements including all
components listed in the
question.   Where audited or
independently certified
financial statements are not
available, applicant has
provided an adequate
explanation as to the
accounting practices in its
jurisdiction and has provided,
at a minimum, unaudited
financial statements.
1 - meets requirements:  Complete
audited or independently certified
financial statements are provided, at the
highest level available in the applicant’s
jurisdiction. Where such audited or
independently certified financial
statements are not available, such as for
newly-formed entities, the applicant has
provided an explanation and has
provided, at a minimum, unaudited
financial statements.
0 - fails requirements:  Does not meet
all the requirements to score 1. For
example, entity with an operating history
fails to provide audited or independently
certified statements.A-37
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
46 Projections Template: provide financial
projections for costs and funding using Template
1, Most Likely Scenario (attached).
Note, if certain services are outsourced, reflect
this in the relevant cost section of the template.
   
The template is intended to provide commonality
among TLD applications and thereby facilitate
the evaluation process.
A complete answer is expected to be no more
than 10 pages in addition to the template.
N 0-1 Applicant has provided a
thorough model that
demonstrates a sustainable
business (even if break-even
is not achieved through the
first three years of
operation).
Applicant’s description of
projections development is
sufficient to show due
diligence.
1 - meets requirements:
(1)  Financial projections  adequately
describe the cost, funding and risks
for the application
(2)  Demonstrates resources and plan
for sustainable operations; and
(3)  Financial assumptions about the
registry operations, funding and
market are identified, explained, and
supported.
0 - fails requirements:  Does not meet
all of the requirements to score a 1.
47 Costs and capital expenditures:  in conjunction with
the financial projections template, describe and
explain:
•    the expected operating costs and
capital expenditures of setting up and
operating the proposed registry;
•   any functions to be outsourced, as
indicated in the cost section of the
template, and the reasons for
outsourcing;
•   any significant variances between years
in any category of expected costs; and
•    a description of the basis / key
assumptions including rationale for the
costs provided in the projections
template. This may include an
executive summary or summary
outcome of studies, reference data, or
other steps taken to develop the
responses and validate any
assumptions made.
As described in the Applicant Guidebook, the
information provided will be considered in light of
the entire application and the evaluation criteria.
Therefore, this answer should agree with the
information provided in Template 1 to:  1)
maintain registry operations, 2) provide registry
services described above, and 3) satisfy the
technical requirements described in the
Demonstration of Technical & Operational
Capability section. Costs should include both
fixed and variable costs.
N This question is based on the template
submitted in question 46.
0-2 Costs identified are
consistent with the proposed
registry services, adequately
fund technical requirements,
and are consistent with
proposed mission/purpose of
the registry. Costs projected
are reasonable for a registry
of size and scope described
in the application. Costs
identified include the funding
costs (interest expenses and
fees) related to the continued
operations instrument
described in Question 50
below.
Key assumptions and their
rationale are clearly
described and may include,
but are not limited to:
•   Key components of
capital
expenditures;
•   Key components of
operating costs, unit
operating costs,
headcount, number
of
technical/operating/
equipment units,
marketing, and
other costs; and
• Costs of outsourcing,
2 - exceeds requirements:  Response
meets all of the attributes for a score of
1 and:
(1)  Estimated costs and assumptions
are conservative and consistent with
an operation of the registry
volume/scope/size as described by
the applicant;
(2)  Estimates are derived from actual
examples of previous or existing
registry operations or equivalent;
and
(3)  Conservative estimates are based
on those experiences and describe
a range of anticipated costs and use
the high end of those estimates.
1 - meets requirements:
(1)  Cost elements are reasonable and
complete (i.e., cover all of the
aspects of registry operations:
registry services, technical
requirements and other aspects as
described by the applicant);
(2)  Estimated costs and assumptions
are consistent and defensible with
an operation of the registry
volume/scope/size as described by
the applicant; and
(3) Projections are reasonably aligned
with the historical financial
statements provided in Question 45.
0 - fails requirements:  Does not meet
all the requirements to score a 1.A-38
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
To be eligible for a score of two points, answers
must demonstrate a conservative estimate of
costs based on actual examples of previous or
existing registry operations with similar approach
and projections for growth and costs or
equivalent. Attach reference material for such
examples.
A complete answer is expected to be no more
than 10 pages.
                 
if any.
(b) Describe anticipated ranges in projected
costs. Describe factors that affect those ranges.
A complete answer is expected to be no more
than 10 pages.
N
48 (a) Funding and Revenue:  Funding can be
derived from several sources (e.g., existing
capital or proceeds/revenue from operation of
the proposed registry).
Describe:
I) How existing funds will provide resources for
both:  a)  start-up of operations, and b) ongoing
operations;
II)  the revenue model including projections for
transaction volumes and price (if the applicant
does not intend to rely on registration revenue in
order to cover the costs of the registry's
operation, it must clarify how the funding for the
operation will be developed and maintained in a
stable and sustainable manner);
III) outside sources of funding (the applicant
must, where applicable, provide evidence of the
commitment by the party committing the funds).
Secured vs unsecured funding should be clearly
identified, including associated sources of
funding (i.e., different types of funding, level and
type of security/collateral, and key items) for
each type of funding;
IV) Any significant variances between years in
any category of funding and revenue; and
V) A description of the basis / key assumptions
N 0-2 Funding resources are
clearly identified and
adequately provide for
registry cost projections.
Sources of capital funding
are clearly identified, held
apart from other potential
uses of those funds and
available. The plan for
transition of funding sources
from available capital to
revenue from operations (if
applicable) is described.
Outside sources of funding
are documented and verified.
Examples of evidence for
funding sources include, but
are not limited to:
•   Executed funding
agreements;
•   A letter of credit;
•   A  commitment
letter; or
• A bank statement.
Funding commitments may
2 - exceeds requirements:
Response meets all the attributes for a
score of 1 and
(1) Existing funds (specifically all funds
required for start-up) are quantified,
on hand, segregated in an account
available only to the applicant for
purposes of the application only, ;
(2) If on-going operations are to be at
least partially resourced from
existing funds (rather than revenue
from on-going operations) that
funding is segregated and
earmarked for this purpose only in
an amount adequate for three years
operation;
(3) If ongoing operations are to be at
least partially resourced from
revenues, assumptions made are
conservative and take into
consideration studies, reference
data, or other steps taken to
develop the response and validate
any assumptions made; and
(4) Cash flow models are prepared
which link funding and revenue
assumptions to projected actual A-39
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
including rationale for the funding and revenue
provided in the projections template. This may
include an executive summary or summary
outcome of studies, reference data, or other
steps taken to develop the responses and
validate any assumptions made; and
VI) Assurances that funding and revenue
projections cited in this application are consistent
with other public and private claims made to
promote the business and generate support.
To be eligible for a score of 2 points, answers
must demonstrate:
I) A conservative estimate of funding and
revenue; and
II) Ongoing operations that are not
dependent on projected revenue.
A complete answer is expected to be no more than
10 pages.
be conditional on the
approval of the application.
Sources of capital funding
required to sustain registry
operations on an on-going
basis are identified. The
projected revenues are
consistent with the size and
projected penetration of the
target markets.
Key assumptions and their
rationale are clearly
described and address, at a
minimum:
•   Key components of
the funding plan
and their key terms;
and
•   Price and number of
registrations.
business activity.
1 - meets requirements:
(1) Assurances provided that materials
provided to investors and/or lenders
are consistent with the projections
and assumptions included in the
projections templates;
(2) Existing funds (specifically all funds
required for start-up) are quantified,
committed, identified as available to
the applicant;
(3) If on-going operations are to be at
least partially resourced from
existing funds (rather than revenue
from on-going operations) that
funding is quantified and its sources
identified in an amount adequate for
three years operation;
(4) If ongoing operations are to be at
least partially resourced from
revenues, assumptions made are
reasonable and are directly related
to projected business volumes,
market size and penetration; and
(5) Projections are reasonably aligned
with the historical financial
statements provided in Question 45.
0 - fails requirements:  Does not meet
all the requirements to score a 1.
(b) Describe anticipated ranges in projected
funding and revenue. Describe factors that affect
those ranges.
A complete answer is expected to be no more
than 10 pages.
N
49 (a) Contingency Planning:  describe your
contingency planning:
•    Identify any projected barriers/risks to
implementation of the business
approach described in the application
and how they affect cost, funding,
revenue, or timeline in your planning;
•   Identify the impact of any particular
regulation, law or policy that might
impact the Registry Services offering;
and
•   Describe the measures to mitigate the
N 0-2 Contingencies and risks are
identified, quantified, and
included in the cost, revenue,
and funding analyses. Action
plans are identified in the
event contingencies occur.
The model is resilient in the
event those contingencies
occur.  Responses address
the probability and resource
impact of the contingencies
identified.
2 - exceeds requirements:  Response
meets all attributes for a score of 1 and:
(1)  Action plans and operations are
adequately resourced in the existing
funding and revenue plan even if
contingencies occur.
1 - meets requirements:
(1)  Model adequately identifies the key
risks (including operational,
business, legal, jurisdictional,
financial, and other relevant risks);
(2)  Response gives consideration to
probability and resource impact of A-40
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
key risks as described in this question.
A complete answer should include, for each
contingency, a clear description of the impact to
projected revenue, funding, and costs for the 3-
year period presented in Template 1 (Most Likely
Scenario).
To be eligible for a score of 2 points, answers
must demonstrate that action plans and
operations are adequately resourced in the
existing funding and revenue plan even if
contingencies occur.
A complete answer is expected to be no more
than10 pages.
contingencies identified; and
(3) If resources are not available to fund
contingencies in the existing plan,
funding sources and a plan for
obtaining them are identified.
0 - fails requirements:  Does not meet
all the requirements to score a 1.
(b) Describe your contingency planning where
funding sources are so significantly reduced that
material deviations from the implementation
model are required. In particular, describe:
•    how on-going technical requirements
will be met; and
•    what alternative funding can be
reasonably raised at a later time.
Provide an explanation if you do not believe
there is any chance of reduced funding.
Complete a financial projections template
(Template 2, Worst Case Scenario)
A complete answer is expected to be no more
than 10 pages, in addition to the template.
N
(c) Describe your contingency planning
where activity volumes so significantly exceed
the high projections that material deviation from
the implementation model are required. In
particular, how will on-going technical
requirements be met?
A complete answer is expected to be no more
than 10 pages.
N
50  (a) Provide a cost estimate for funding critical
registry functions on an annual basis, and a
rationale for these cost estimates
commensurate with the technical,
operational, and financial approach
described in the application.
N Registrant protection is critical and thus new
gTLD applicants are requested to provide
evidence indicating that the critical functions
will continue to be performed even if the
registry fails. Registrant needs are best
protected by a clear demonstration that the
0-3 Figures provided are based
on an accurate estimate of
costs. Documented evidence
or detailed plan for ability to
fund on-going critical registry
functions for registrants for a
3 - exceeds requirements:
Response meets all the attributes for a
score of 1 and:
(1)   Financial instrument is secured and
in place to provide for on-going
operations for at least three years in A-41
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
The critical functions of a registry which
must be supported even if an applicant’s
business and/or funding fails are:
(1) DNS resolution for registered domain
names
Applicants should consider ranges of
volume of daily DNS queries (e.g., 0-
100M, 100M-1B, 1B+), the
incremental costs associated with
increasing levels of such queries, and
the ability to meet SLA performance
metrics.
(2) Operation of the Shared Registration
System
Applicants should consider ranges of
volume of daily EPP transactions
(e.g., 0-200K, 200K-2M, 2M+), the
incremental costs associated with
increasing levels of such queries, and
the ability to meet SLA performance
metrics.  
(3) Provision of Whois service
Applicants should consider ranges of
volume of daily Whois queries (e.g.,
0-100K, 100k-1M, 1M+), the
incremental costs associated with
increasing levels of such queries, and
the ability to meet SLA performance
metrics for both web-based and port-
43 services.  
(4) Registry data escrow deposits
Applicants should consider
administration, retention, and transfer
fees as well as daily deposit (e.g., full
or incremental) handling. Costs may
vary depending on the size of the files
in escrow (i.e., the size of the registry
database).
basic registry functions are sustained for an
extended period even in the face of registry
failure. Therefore, this section is weighted
heavily as a clear, objective measure to
protect and serve registrants.
The applicant has two tasks associated with
adequately making this demonstration of
continuity for critical registry functions. First,
costs for maintaining critical registrant
protection functions are to be estimated
(Part a). In evaluating the application, the
evaluators will adjudge whether the estimate
is reasonable given the systems architecture
and overall business approach described
elsewhere in the application.
The Continuing Operations Instrument (COI)
is invoked by ICANN if necessary to pay for
an Emergency Back End Registry Operator
(EBERO) to maintain the five critical registry
functions for a period of three to five years.
Thus, the cost estimates are tied to the cost
for a third party to provide the functions, not
to the applicant’s actual in-house or
subcontracting costs for provision of these
functions.
Note that ICANN is building a model for
these costs in conjunction with potential
EBERO service providers. Thus, guidelines
for determining the appropriate amount for
the COI will be available to the applicant.
However, the applicant will still be required
to provide its own estimates and explanation
in response to this question.
period of three years in the
event of registry failure,
default or until a successor
operator can be designated.
Evidence of financial
wherewithal to fund this
requirement prior to
delegation. This requirement
must be met prior to or
concurrent with the execution
of the Registry Agreement.
the event of failure.
1 - meets requirements:
(1)  Costs are commensurate with
technical, operational, and financial
approach as described in the
application; and
(2)  Funding is identified and instrument
is described to provide for on-going
operations of at least three years in
the event of failure.
0 - fails requirements:  Does not meet
all the requirements to score a 1.A-42
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
(5) Maintenance of a properly signed
zone in accordance with DNSSEC
requirements.
Applicants should consider ranges of
volume of daily DNS queries (e.g., 0-
100M, 100M-1B, 1B+), the
incremental costs associated with
increasing levels of such queries, and
the ability to meet SLA performance
metrics.  
List the estimated annual cost for each of these
functions (specify currency used).
A complete answer is expected to be no more
than 10 pages.
(b) Applicants must provide evidence as to how
the funds required for performing these critical
registry functions will be available and
guaranteed to fund registry operations (for the
protection of registrants in the new gTLD) for a
minimum of three years following the termination
of the Registry Agreement. ICANN has identified
two methods to fulfill this requirement:
(i) Irrevocable standby letter of credit (LOC)
issued by a reputable financial institution.
• The amount of the LOC must be equal to
or greater than the amount required to fund the
registry operations specified above for at least
three years.  In the event of a draw upon the
letter of credit, the actual payout would be tied to
the cost of running those functions.
• The LOC must name ICANN or its
designee as the beneficiary.  Any funds paid out
would be provided to the designee who is
operating the required registry functions.
• The LOC must have a term of at least five
years from the delegation of the TLD.  The LOC
may be structured with an annual expiration date
if it contains an evergreen provision providing for
annual extensions, without amendment, for an
indefinite number of periods until the issuing
bank informs the beneficiary of its final expiration
or until the beneficiary releases the LOC as
evidenced in writing.  If the expiration date
occurs prior to the fifth anniversary of the
delegation of the TLD, applicant will be required
to obtain a replacement instrument.
N Second (Part b), methods of securing the
funds required to perform those functions for
at least three years are to be described by
the applicant in accordance with the criteria
below. Two types of instruments will fulfill
this requirement. The applicant must identify
which of the two methods is being
described. The instrument is required to be
in place at the time of the execution of the
Registry Agreement.A-43
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
• The LOC must be issued by a reputable
financial institution insured at the highest level in
its jurisdiction. This may include a bank or
insurance company with a strong international
reputation that has a strong credit rating issued
by a third party rating agency such as Standard
& Poor’s (AA or above), Moody’s (Aa or above),
or A.M. Best (A-X or above). Documentation
should indicate by whom the issuing institution is
insured.
• The LOC will provide that ICANN or its
designee shall be unconditionally entitled to a
release of funds (full or partial) thereunder upon
delivery of written notice by ICANN or its
designee.
• Applicant should attach an original copy
of the executed letter of credit or a draft of the
letter of credit containing the full terms and
conditions. If not yet executed, the Applicant will
be required to provide ICANN with an original
copy of the executed LOC prior to or concurrent
with the execution of the Registry Agreement.
• The LOC must contain at least the
following required elements:
o Issuing bank and date of issue.
o Beneficiary:  ICANN / 4676 Admiralty
Way, Suite 330 / Marina del Rey, CA 90292 /
US, or its designee.
o Applicant’s complete name and address.
o LOC identifying number.
o Exact amount in USD.
o Expiry date.
o Address, procedure, and required forms
whereby presentation for payment is to be made.
o Conditions:
 Partial drawings from the letter of credit
may be made provided that such payment shall
reduce the amount under the standby letter of
credit.
 All payments must be marked with the
issuing bank name and the bank’s standby letter
of credit number.
 LOC may not be modified, amended, or
amplified by reference to any other document,
agreement, or instrument.
 The LOC is subject to the International
Standby Practices (ISP 98) International
Chamber of Commerce (Publication No. 590), or
to an alternative standard that has been A-44
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
demonstrated to be reasonably equivalent.
(ii) A deposit into an irrevocable cash escrow
account held by a reputable financial institution.
• The amount of the deposit must be equal
to or greater than the amount required to fund
registry operations for at least three years.
• Cash is to be held by a third party
financial institution which will not allow the funds
to be commingled with the Applicant’s operating
funds or other funds and may only be accessed
by ICANN or its designee if certain conditions
are met.
• The account must be held by a reputable
financial institution insured at the highest level in
its jurisdiction. This may include a bank or
insurance company with a strong international
reputation that has a strong credit rating issued
by a third party rating agency such as Standard
& Poor’s (AA or above), Moody’s (Aa or above),
or A.M. Best (A-X or above). Documentation
should indicate by whom the issuing institution is
insured.
• The escrow agreement relating to the
escrow account will provide that ICANN or its
designee shall be unconditionally entitled to a
release of funds (full or partial) thereunder upon
delivery of written notice by ICANN or its
designee.
• The escrow agreement must have a term
of five years from the delegation of the TLD.
• The funds in the deposit escrow account
are not considered to be an asset of ICANN.  
• Any interest earnings less bank fees are
to accrue to the deposit, and will be paid back to
the applicant upon liquidation of the account to
the extent not used to pay the costs and
expenses of maintaining the escrow.
• The deposit plus accrued interest, less
any bank fees in respect of the escrow, is to be
returned to the applicant if the funds are not
used to fund registry functions due to a triggering
event or after five years, whichever is greater.
• The Applicant will be required to provide
ICANN an explanation as to the amount of the
deposit, the institution that will hold the deposit,
and the escrow agreement for the account at the
time of submitting an application.A-45
# Question
Included
in public
posting Notes
Scoring
Range Criteria Scoring
• Applicant should attach evidence of
deposited funds in the escrow account, or
evidence of provisional arrangement for deposit
of funds.  Evidence of deposited funds and terms
of escrow agreement must be provided to
ICANN prior to or concurrent with the execution
of the Registry Agreement.Instructions: TLD Applicant – Financial Projections
Instructions: TLD Applicant – Financial Projections
The application process requires the applicant to submit two cash basis Financial Projections.
The first projection (Template 1) should show the Financial Projections associated with the Most Likely
scenario expected. This projection should include the forecasted registration volume, registration fee,
and all costs and capital expenditures expected during the start‐up period and during the first three
years of operations. Template 1 relates to Question 46 (Projections Template) in the application.
We also ask that applicants show as a separate projection (Template 2) the Financial Projections
associated with a realistic Worst Case scenario. Template 2 relates to Question 49 (Contingency
Planning) in the application.
For each Projection prepared, please include Comments and Notes on the bottom of the projection (in
the area provided) to provide those reviewing these projections with information regarding:
1. Assumptions used, significant variances in Operating Cash Flows and Capital Expenditures from
year‐to‐year;
2. How you plan to fund operations;
3. Contingency planning
As you complete Template 1 and Template 2, please reference data points and/or formulas used in your
calculations (where appropriate).
Section I – Projected Cash inflows and outflows
Projected Cash Inflows
Lines A and B. Provide the number of forecasted registrations and the registration fee for years 1, 2, and
3. Leave the Start‐up column blank. The start‐up period is for cash costs and capital expenditures only;
there should be no cash projections input to this column.
Line C. Multiply lines A and B to arrive at the Registration Cash Inflow for line C.
Line D. Provide projected cash inflows from any other revenue source for years 1, 2, and 3. For any
figures provided on line D, please disclose the source in the Comments/Notes box of Section I.  Note, do
not include funding in Line D as that is covered in Section VI.
Line E. Add lines C and D to arrive at the total cash inflow.
Projected Operating Cash Outflows
Start up costs ‐ For all line items (F thru L) Please describe the total period of time this start‐up cost is
expected to cover in the Comments/Notes box.Instructions: TLD Applicant – Financial Projections
Line F. Provide the projected labor costs for marketing, customer support, and technical support for
start‐up, year 1, year 2, and year 3.  Note, other labor costs should be put in line L (Other Costs) and
specify the type of labor and associated projected costs in the Comments/Notes box of this section.
Line G. Marketing Costs represent the amount spent on advertising, promotions, and other marketing
activities. This amount should not include labor costs included in Marketing Labor (line F).  
Lines H through K. Provide projected costs for facilities, G&A, interests and taxes, and Outsourcing for
start‐up as well as for years 1, 2, and 3. Be sure to list the type of activities that are being outsourced.
You may combine certain activities from the same provider as long as an appropriate description of the
services being combined is listed in the Comments/Notes box.
Line L. Provide any other projected operating costs for start‐up, year 1, year 2, year 3.  Be sure to specify
the type of cost in the Comments/Notes box.
Line M. Add lines F through L to arrive at the total costs for line M.
Line N. Subtract line E from line M to arrive at the projected net operation number for line N.
Section IIa – Breakout of Fixed and Variable Operating Cash Outflows
Line A. Provide the projected variable operating cash outflows including labor and other costs that are
not fixed in nature.  Variable operating cash outflows are expenditures that fluctuate in relationship with
increases or decreases in production or level of operations.
Line B. Provide the projected fixed operating cash outflows.  Fixed operating cash outflows are
expenditures that do not generally fluctuate in relationship with increases or decreases in production or
level of operations. Such costs are generally necessary to be incurred in order to operate the base line
operations of the organization or are expected to be incurred based on contractual commitments.
Line C – Add lines A and B to arrive at total Fixed and Variable Operating Cash Outflows for line C.  This
must equal Total Operating Cash Outflows from Section I, Line M.
Section IIb – Breakout of Critical Registry Function Operating Cash Outflows
Lines A – E.  Provide the projected cash outflows for the five critical registry functions.  If these functions
are outsourced, the component of the outsourcing fee representing these functions must be separately
identified and provided.  The projected cash outflow for these functions will form the basis of the 3‐year
reserve required in Question 50 of the application.
Line F. If there are other critical registry functions based on the applicant’s registry business model then
the projected cash outflow for this function must be provided with a description added to the
Comment/Notes box.
Line G. Add lines A through F to arrive at the Total Critical Registry Function Cash Outflows.
Line H – Equals the cash outflows for the critical registry functions projected over 3 years (Columns H, I,
and J)Instructions: TLD Applicant – Financial Projections
Section III – Projected Capital Expenditures
Lines A through C. Provide projected hardware, software, and furniture & equipment capital
expenditures for start‐up as well as for years 1, 2, and 3. Please describe the total period of time the
start‐up cost is expected to cover in the Comments/Notes box.
Line D. Provide any projected capital expenditures as a result of outsourcing.  This should be included
for start‐up and years 1, 2, and 3. Specify the type of expenditure and describe the total period of time
the start‐up cost is expected to cover in the Comments/Notes box of Section III.
Line E – Please describe “other” capital expenditures in the Comments/Notes box.
Line F. Add lines A through E to arrive at the Total Capital Expenditures.
Section IV – Projected Assets & Liabilities
Lines A through C. Provide projected cash, account receivables, and other current assets for start‐up as
well as for years 1, 2, and 3. For Other Current Assets, specify the type of asset and describe the total
period of time the start‐up cost is expected to cover in the Comments/Notes box.
Line D. Add lines A, B, C to arrive at the Total Current Assets.
Lines E through G. Provide projected accounts payable, short‐term debt, and other current liabilities for
start‐up as well as for years 1, 2, and 3. For Other Current Liabilities, specify the type of liability and
describe the total period of time the start‐up up cost is expected to cover in the Comments/Notes box.
Line H. Ad lines E through G to arrive at the total current liabilities.
Lines I through K. Provide the projected fixed assets (PP&E), the 3‐year reserve, and long‐term assets for
start‐up as well as for years 1, 2, and 3. Please describe the total period of time the start‐up cost is
expected to cover in the Comments/Notes box.
Line L. Ad lines I through K to arrive at the total long‐term assets.
Line M. Provide the projected long‐term debt for start‐up as well as for years 1, 2, and 3. Please describe
the total period of time the start‐up cost is expected to cover in the Comments/Notes box
Section V – Projected Cash Flow
Cash flow is driven by Projected Net Operations (Section I), Projected Capital Expenditures (Section III),
and Projected Assets & Liabilities (Section IV).
Line A. Provide the projected net operating cash flows for start‐up as well as for years 1, 2, and 3. Please
describe the total period of time the start‐up cost is expected to cover in the Comments/Notes box.Instructions: TLD Applicant – Financial Projections
Line B. Provide the projected capital expenditures for start‐up as well as for years 1, 2, and 3. Please
describe the total period of time the start‐up cost is expected to cover in the Comments/Notes box of
Section V.
Lines C through F. Provide the projected change in non‐cash current assets, total current liabilities, debt
adjustments, and other adjustments for start‐up as well as for years 1, 2, and 3. Please describe the total
period of time the start‐up cost is expected to cover in the Comments/Notes box.
Line G. Add lines A through F to arrive at the projected net cash flow for line H.
Section VI – Sources of Funds
Lines A & B. Provide projected funds from debt and equity at start‐up. Describe the sources of debt and
equity funding as well as the total period of time the start‐up is expected to cover in the
Comments/Notes box. Please also provide evidence the funding (e.g., letter of commitment).
Line C. Add lines A and B to arrive at the total sources of funds for line C.
General Comments – Regarding Assumptions Used, Significant Variances
Between Years, etc.
Provide explanations for any significant variances between years (or expected in years beyond the
timeframe of the template) in any category of costing or funding.
General Comments – Regarding how the Applicant Plans to Fund Operations
Provide general comments explaining how you will fund operations. Funding should be explained in
detail in response to question 48.
General Comments – Regarding Contingencies
Provide general comments to describe your contingency planning. Contingency planning should be
explained in detail in response to question 49.Comments / Notes
In local currency (unless noted otherwise)
Provide name of local currency used.
Sec. Reference / Formula Start‐up Costs Year 1 Year 2 Year 3
I) Projected Cash Inflows and Outflows
A) Forecasted registration volume                             ‐                      62,000                      80,600                    104,780 Registration was forecasted based on recent market
surveys which we have attached and discussed below.
B) Registration fee $                         ‐ $                       5.00 $                       5.50 $                       6.05 We do not anticipate significant increases in Registration
Fees subsequent to year 3.
C) Registration cash inflows A * B                             ‐                    310,000                    443,300                    633,919
D) Other cash inflows                             ‐                      35,000                      48,000                      62,000 Other cash inflows represent advertising monies expected
from display ads on our website.
E) Total Cash Inflows                             ‐                    345,000                    491,300                    695,919
   Projected Operating Cash Outflows
F) Labor:
i) Marketing Labor                      25,000                      66,000                      72,000                      81,000 Costs are further detailed and explained in response to
question 47.
ii) Customer Support Labor                        5,000                      68,000                      71,000                      74,000
iii) Technical Labor                      32,000                      45,000                      47,000                      49,000
G) Marketing                      40,000                      44,000                      26,400                      31,680
H) Facilities                        7,000                      10,000                      12,000                      14,400
I) General & Administrative                      14,000                    112,000                    122,500                    136,000
J) Interest and Taxes                      27,500                      29,000                      29,800                      30,760
K) Outsourcing Operating Costs, if any (list the type of activities being outsourced): Provide a list and associated cost for each outsourced
function.
i) Hot site maintenance                        5,000                        7,500                        7,500                        7,500 Outsourcing hot site to ABC Company, cost based on
number of servers hosted and customer support
ii) Critical Registry Functions                      32,000                      37,500                      41,000                      43,000 Outsourced critical registry and other functions to ABC
registry.  Costs are based on expected domains and
queries
iii) {list type of activities being outsourced}                              ‐ ‐                              ‐                              ‐                              Provide a description of the outsourced activities and how
costs were determined
iv) {list type of activities being outsourced}                              ‐ ‐                              ‐                              ‐                              Provide a description of the outsourced activities and how
costs were determined
v) {list type of activities being outsourced}                              ‐ ‐                              ‐                              ‐                              Provide a description of the outsourced activities and how
costs were determined
vi) {list type of activities being outsourced}                              ‐ ‐                              ‐                              ‐                              Provide a description of the outsourced activities and how
costs were determined
L) Other Operating Costs                      12,200                      18,000                      21,600                      25,920
M) Total Operating Cash Outflows                    199,700                    437,000                    450,800                    493,260
N) Projected Net Operating Cash flow E ‐ M                  (199,700)                     (92,000)                      40,500                    202,659
IIa) Break out of Fixed and Variable Operating Cash Outflows
A) Total Variable Operating Costs                      72,067                    163,417                    154,464                    200,683 Variable Costs:
‐Start Up equals all labor plus 75% of marketing.
‐Years 1 through 3 equal 75% of all labor plus 50% of
Marketing, and 30% of G&A and Other costs
B) Total Fixed Operating Costs                    127,633                    273,583                    296,336                    292,577 Fixed Costs: equals Total Costs less Variable Costs
C) Total Operating Cash Outflows = Sec. I) M                    199,700                    437,000                    450,800                    493,260
CHECK                              ‐ ‐                              ‐                              ‐                              Check that II) C equals I) N.
IIb) Break out of Critical Registry Function Operating Cash Outflows Note: ICANN is working on cost model that will be
provided at a later date
A) Operation of SRS                        5,000                        5,500                        6,050 Commensurate with Question 24
B) Provision of Whois                        6,000                        6,600                        7,260 Commensurate with Question 26
C) DNS Resolution for Registered Domain Names                        7,000                        7,700                        8,470 Commensurate with Question 35
D) Registry Data Escrow                        8,000                        8,800                        9,680 Commensurate with Question 38
E) Maintenance of Zone in accordance with DNSSEC                        9,000                        9,900                      10,890 Commensurate with Question 43
G) Total Critical Function Cash Outflows                             ‐                      35,000                      38,500                      42,350
H) 3‐year Total 115,850                  
III) Projected Capital Expenditures
A) Hardware                      98,000                      21,000                     16,000                     ‐ 58,000 Hardware & Software have a useful life of 3 years
B) Software                      32,000                      18,000                      24,000                      11,000
C) Furniture & Other Equipment                      43,000                      22,000                      14,000                       ‐ 16,000 Furniture & other equipment have a useful life of 5 years
D) Outsourcing Capital Expenditures, if any (list the type of capital expenditures)
i)                              ‐ ‐                              ‐                              ‐                              List and describe each identifiable type of outsourcing.
ii)                              ‐ ‐                              ‐                              ‐                              List and describe each identifiable type of outsourcing.
iii)                              ‐ ‐                              ‐                              ‐                              List and describe each identifiable type of outsourcing.
iv)                              ‐ ‐                              ‐                              ‐                              List and describe each identifiable type of outsourcing.
v)                              ‐ ‐                              ‐                              ‐                              List and describe each identifiable type of outsourcing.
vi)                              ‐ ‐                              ‐                              ‐                              List and describe each identifiable type of outsourcing.
ED) Other Capital Expenditures
F) Total Capital Expenditures                    173,000                      61,000                      54,000                      85,000
IV) Projected Assets & Liabilities
A) Cash                    705,300                    556,300                    578,600                    784,600
B) Accounts receivable                      70,000                    106,000                    160,000
C) Other current assets                      40,000                      60,000                      80,000
D) Total Current Assets                    705,300                    666,300                    744,600                1,024,600
E) Accounts payable                      41,000                    110,000                    113,000                    125,300
F) Short‐term Debt
G) Other Current Liabilities
H) Total Current Liabilities                      41,000                    110,000                    113,000                    125,300
I) Total Property, Plant & Equipment (PP&E) = Sec III) F: cumulative
Prior Years + Cur Yr
                   173,000                    234,000                    288,000                    373,000
J) 3‐year Reserve = IIb) H)                    115,850                    115,850                    115,850                    115,850
K) Other Long‐term Assets
L) Total Long‐term Assets                    288,850                    349,850                    403,850                    488,850
M) Total Long‐term Debt                1,000,000                1,000,000                1,000,000                1,000,000 Principal payments on the line of credit with XYZ Bank will
not be incurred until Year 5.  Interest will be paid as
incurred and is reflected in Sec I) J.
V) Projected Cash flow (excl. 3‐year Reserve)
A) Net operating cash flows = Sec. I) N                  (199,700)                     (92,000)                      40,500                    202,659
B) Capital expenditures = Sec. III) FE                  (173,000)                     (61,000)                     (54,000)                     (85,000)
C) Change in Non Cash Current Assets = Sec. IV) (B+C):
Prior Yr ‐ Cur Yr
n/a (110,000)                                       (56,000)                     (74,000)
D) Change in Total Current Liabilities = Sec. IV) H:
Cur Yr ‐ Prior Yr
                     41,000                      69,000                        3,000                      12,300 The $41k in Start Up Costs represents an offset of the
Accounts Payable reflected in the Projected balance
sheet.  Subsequent years are based on changes in Current
Liabilities where Prior Year is subtracted from the Current
year
E) Debt Adjustments
= Sec IV) F and M:
Cur Yr ‐ Prior Yr n/a                              ‐ ‐                              ‐                            
F) Other Adjustments
G) Projected Net Cash flow (331,700)                                    (194,000)                     (66,500)                      55,959
VI) Sources of funds
A) Debt:
i) On‐hand at time of application                1,000,000 See below for comments on funding. Revenues are
further detailed and explained in response to question 48.
ii) Contingent and/or committed but not yet on‐
hand
B) Equity:
i) On‐hand at time of application
ii) Contingent and/or committed but not yet on‐
hand
                            ‐
C) Total Sources of funds                1,000,000
General Comments regarding contingencies:
Although we expect to be cash flow positive by the end of year 2, the recently negotiated line of credit will cover our operating costs for the first 4 years of operation if necessary. We have also entered into an
agreement with XYZ Co. to assume our registrants should our business model not have the ability to sustain itself in future years. Agreement with XYZ Co. has been included with our application. A full description
of risks and a range of potential outcomes and impacts are included in our responses to Question 49. These responses have quantified the impacts of certain probabilities and our negotiated funding and action
plans as shown, are adequate to fund our  Worst Case Scenario.
TLD Applicant ‐‐ Financial Projections : Sample
Live / Operational
General Comments (Notes Regarding Assumptions Used, Significant Variances Between Years, etc.):
We expect the number of registrations to grow at approximately 30% per year with an increase in the registration fee of $1 per year for the first three years. These volume assumptions are based on the attached
(i) market data and (ii) published benchmark registry growth. Fee assumptions are aligned with the growth plan and anticipated demand based on the registration curve. We anticipate our costs will increase at a
controlled pace over the first three years except for marketing costs which will be higher in the start‐up and first year as we establish our brand name and work to increase registrations.  Operating costs are
supported by the attached (i) benchmark report for a basket of similar registries and (ii) a build‐up of costs based on our current operations. Our capital expenditures will be greatest in the start‐up phase and then
our need to invest in computer hardware and software will level off after the start‐up period.  Capital expenses are based on contract drafts and discussions held with vendors. We have included and referenced the
hardware costs to support the estimates. Our investment in Furniture and Equipment will be greatest in the start‐up period as we build our infrastructure and then decrease in the following periods.
Start‐up: Our start‐up phase is anticipated to comprise [X] months in line with benchmark growth curves indicated by prior start‐ups and published market data. Our assumptions were derived from the attached
support
Comments regarding how the Applicant plans to Fund operations:
We have recently negotiated a line of credit with XYZ Bank (a copy of the fully executed line of credit agreement has been included with our application) and this funding will allow us to purchase necessary
equipment and pay for employees and other Operating Costs during our start‐up period and the first few years of operations.  We expect that our business operation will be self funded (i.e., revenue from
operations will cover all anticipated costs and capital expenditures) by the second half of our second year in operation; we also expect to become profitable with positive cash flow in year three.Comments / Notes
In local currency (unless noted otherwise) Provide name of local currency used.
Sec. Reference / Formula Start‐up Costs Year 1 Year 2 Year 3
I) Projected Cash inflows and outflows
A) Forecasted registration volume
B) Registration fee
C) Registration cash inflows                             ‐ ‐                             ‐                          
D) Other cash inflows
E) Total Cash Inflows                             ‐ ‐                             ‐                             ‐                          
   Projected Operating Cash Outflows
F) Labor:
i) Marketing Labor
ii) Customer Support Labor
iii) Technical Labor
G) Marketing
H) Facilities
I) General & Administrative
J) Interest and Taxes
K) Outsourcing Operating Costs, if any (list the type of activities being outsourced):
i) {list type of activities being outsourced}
ii) {list type of activities being outsourced}
iii) {list type of activities being outsourced}
iv) {list type of activities being outsourced}
v) {list type of activities being outsourced}
vi) {list type of activities being outsourced}
L) Other Operating costs
M) Total Operating Cash Outflows                             ‐ ‐                             ‐                             ‐                          
N) Projected Net Operating Cash flow                             ‐ ‐                             ‐                             ‐                          
IIa) Break out of Fixed and Variable Operating Cash Outflows
A) Total Variable Operating Costs
B) Total Fixed Operating Costs
C) Total Operating Cash Outflows                             ‐ ‐                             ‐                             ‐                          
CHECK                             ‐ ‐                             ‐                             ‐                          
IIb) Break out of Critical Function Operating Cash Outflows
A) Operation of SRS
B) Provision of Whois
C) DNS Resolution for Registered Domain Names
D) Registry Data Escrow
E) Maintenance of Zone in accordance with DNSSEC
G) Total Critical Registry Function Cash Outflows                             ‐ ‐                             ‐                             ‐                          
H) 3‐year Total                            ‐
III) Projected Capital Expenditures
A) Hardware
B) Software
C) Furniture & Other Equipment
D) Outsourcing Capital Expenditures, if any (list the type of capital expenditures)
i)
ii)
iii)
iv)
v)
vi)
E) Other Capital Expenditures
F) Total Capital Expenditures                             ‐ ‐                             ‐                             ‐                          
IV) Projected Assets & Liabilities
A) Cash
B) Accounts receivable
C) Other current assets
D) Total Current Assets                             ‐ ‐                             ‐                             ‐                          
E) Accounts payable
F) Short‐term Debt
G) Other Current Liabilities
H) Total Current Liabilities                             ‐ ‐                             ‐                             ‐                          
I) Total Property, Plant & Equipment (PP&E)                             ‐ ‐                             ‐                             ‐                          
J) 3‐year Reserve                             ‐ ‐                             ‐                          
K) Other Long‐term Assets
L) Total Long‐term Assets                             ‐ ‐                             ‐                             ‐                          
M) Total Long‐term Debt
V) Projected Cash flow (excl. 3‐year Reserve)
A) Net operating cash flows                             ‐ ‐                             ‐                             ‐                          
C) Capital expenditures                             ‐ ‐                             ‐                             ‐                          
D) Change in Non Cash Current Assets n/a                             ‐ ‐                             ‐                          
E) Change in Total Current Liabilities                             ‐ ‐                             ‐                             ‐                          
F) Debt Adjustments n/a                            ‐                            ‐                            ‐
G) Other Adjustments
H) Projected Net Cash flow                             ‐ ‐                             ‐                             ‐                          
VI) Sources of funds
A) Debt:
i) On‐hand at time of application
ii) Contingent and/or committed but not yet on‐hand
B) Equity:
i) On‐hand at time of application
ii) Contingent and/or committed but not yet on‐hand
C) Total Sources of funds                            ‐
Template 1 ‐ Financial Projections: Most Likely
Live / Operational
General Comments (Notes Regarding Assumptions Used, Significant Variances Between Years, etc.):
Comments regarding how the Applicant plans to Fund operations:
General Comments regarding contingencies:Comments / Notes
In local currency (unless noted otherwise)
Provide name of local currency used.
Sec. Reference / Formula Start‐up Costs Year 1 Year 2 Year 3
I) Projected Cash inflows and outflows
A) Forecasted registration volume
B) Registration fee
C) Registration cash inflows                             ‐ ‐                             ‐                          
D) Other cash inflows
E) Total Cash Inflows                             ‐ ‐                             ‐                             ‐                          
   Projected Operating Cash Outflows
F) Labor:
i) Marketing Labor
ii) Customer Support Labor
iii) Technical Labor
G) Marketing
H) Facilities
I) General & Administrative
J) Interest and Taxes
K) Outsourcing Operating Costs, if any (list the type of activities being outsourced):
i) {list type of activities being outsourced}
ii) {list type of activities being outsourced}
iii) {list type of activities being outsourced}
iv) {list type of activities being outsourced}
v) {list type of activities being outsourced}
vi) {list type of activities being outsourced}
L) Other Operating costs
M) Total Operating Cash Outflows                             ‐ ‐                             ‐                             ‐                          
N) Projected Net Operating Cash flow                             ‐ ‐                             ‐                             ‐                          
IIa) Break out of Fixed and Variable Operating Cash Outflows
A) Total Variable Operating Costs
B) Total Fixed Operating Costs
C) Total Operating Cash Outflows                             ‐ ‐                             ‐                             ‐                          
CHECK                             ‐ ‐                             ‐                             ‐                          
IIb) Break out of Critical Function Operating Cash Outflows
A) Operation of SRS
B) Provision of Whois
C) DNS Resolution for Registered Domain Names
D) Registry Data Escrow
E) Maintenance of Zone in accordance with DNSSEC
G) Total Critical Registry Function Cash Outflows                             ‐ ‐                             ‐                             ‐                          
H) 3‐year Total                            ‐
III) Projected Capital Expenditures
A) Hardware
B) Software
C) Furniture & Other Equipment
D) Outsourcing Capital Expenditures, if any (list the type of capital expenditures)
i)
ii)
iii)
iv)
v)
vi)
E) Other Capital Expenditures
F) Total Capital Expenditures                             ‐ ‐                             ‐                             ‐                          
IV) Projected Assets & Liabilities
A) Cash
B) Accounts receivable
C) Other current assets
D) Total Current Assets                             ‐ ‐                             ‐                             ‐                          
E) Accounts payable
F) Short‐term Debt
G) Other Current Liabilities
H) Total Current Liabilities                             ‐ ‐                             ‐                             ‐                          
I) Total Property, Plant & Equipment (PP&E)                             ‐ ‐                             ‐                             ‐                          
J) 3‐year Reserve                             ‐ ‐                             ‐                          
K) Other Long‐term Assets
L) Total Long‐term Assets                             ‐ ‐                             ‐                             ‐                          
M) Total Long‐term Debt
V) Projected Cash flow (excl. 3‐year Reserve)
A) Net operating cash flows                             ‐ ‐                             ‐                             ‐                          
C) Capital expenditures                             ‐ ‐                             ‐                             ‐                          
D) Change in Non Cash Current Assets n/a                             ‐ ‐                             ‐                          
E) Change in Total Current Liabilities                             ‐ ‐                             ‐                             ‐                          
F) Debt Adjustments n/a                            ‐                             ‐ ‐                          
G) Other Adjustments
H) Projected Net Cash flow                             ‐ ‐                             ‐                             ‐                          
VI) Sources of funds
A) Debt:
i) On‐hand at time of application
ii) Contingent and/or committed but not yet on‐hand
B) Equity:
i) On‐hand at time of application
ii) Contingent and/or committed but not yet on‐hand
C) Total Sources of funds                            ‐
Template 2 ‐ Financial Projections: Worst Case
Live / Operational
Comments regarding how the Applicant plans to Fund operations:
General Comments regarding contingencies:
General Comments (Notes Regarding Assumptions Used, Significant Variances Between Years, etc.):gTLD Applicant
Guidebook
(v. 2011-09-19)
Module 3
19 September 2011Applicant Guidebook | version 2011-09-19
3-1
Module 3
Objection Procedures
This module describes two types of mechanisms that may
affect an application:
I. The procedure by which ICANN’s Governmental
Advisory Committee may provide GAC Advice on
New gTLDs to the ICANN Board of Directors
concerning a specific application. This module
describes the purpose of this procedure, and how
GAC Advice on New gTLDs is considered by the
ICANN Board once received.
II. The dispute resolution procedure triggered by a
formal objection to an application by a third party.
This module describes the purpose of the objection
and dispute resolution mechanisms, the grounds for
lodging a formal objection to a gTLD application,
the general procedures for filing or responding to
an objection, and the manner in which dispute
resolution proceedings are conducted.
This module also discusses the guiding principles, or
standards, that each dispute resolution panel will
apply in reaching its expert determination.
All applicants should be aware of the possibility that
a formal objection may be filed against any
application, and of the procedures and options
available in the event of such an objection.
3.1 GAC Advice on New gTLDs
The GAC has expressed the intention to develop a
standard vocabulary and set of rules for use in providing its
advice in this program. These will be published and, as a
result, this section might be updated to reflect the terms
established by the GAC.
ICANN’s Governmental Advisory Committee was formed to
consider and provide advice on the activities of ICANN as
they relate to concerns of governments, particularly
matters where there may be an interaction between
ICANN's policies and various laws and international
agreements or where they may affect public policy issues.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-2
The process for GAC Advice on New gTLDs is intended to
address applications that are identified by governments to
be problematic, e.g., that potentially violate national law
or raise sensitivities.
GAC members can raise concerns about any application
to the GAC. The GAC as a whole will consider concerns
raised by GAC members, and agree on GAC advice to
forward to the ICANN Board of Directors.
The GAC can provide advice on any application. For the
Board to be able to consider the GAC advice during the
evaluation process, the GAC advice would have to be
submitted by the close of the Objection Filing Period (see
Module 1).
GAC Advice may take several forms, among them:
I. The GAC advises ICANN that it is the consensus1
of the
GAC that a particular application should not proceed.
This will create a strong presumption for ICANN that the
application should not be approved. In the event that
the ICANN Board determines to approve an
application despite the consensus advice of the GAC,
pursuant to the ICANN Bylaws, the GAC and the ICANN
Board will then try, in good faith and in a timely and
efficient manner, to find a mutually acceptable
solution. In the event the Board determines not to
accept the GAC Advice, the Board will provide a
rationale for its decision.
II. The GAC provides advice that indicates that some
governments are concerned about a particular
application. Such advice will be passed on to the
applicant but will not create the presumption that the
application should be denied, and such advice would
not require the Board to undertake the process for
attempting to find a mutually acceptable solution with
the GAC should the application be approved. Note
that in any case, that the Board will take seriously any
other advice that GAC might provide and will consider
entering into dialogue with the GAC to understand the
scope of the concerns expressed.
III. The GAC advises ICANN that an application should not
proceed unless remediated. This will raise a strong
presumption for the Board that the application should
                                                         
1
The GAC will clarify the basis on which consensus advice is developed.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-3
not proceed. If there is a remediation method
available in the Guidebook (such as securing
government approval), that action may be taken.
However, material amendments to applications are
generally prohibited and if there is no remediation
method available, the application will not go forward
and the applicant can re-apply in the second round.
Where GAC Advice on New gTLDs is received by the Board
concerning an application, ICANN will publish the Advice
and endeavor to notify the relevant applicant(s) promptly.
The applicant will have a period of 21 calendar days from
the publication date in which to submit a response to the
ICANN Board.
ICANN will consider the GAC Advice on New gTLDs as soon
as practicable. The Board may consult with independent
experts, such as those designated to hear objections in the
New gTLD Dispute Resolution Procedure, in cases where
the issues raised in the GAC advice are pertinent to one of
the subject matter areas of the objection procedures. The
receipt of GAC advice will not toll the processing of any
application (i.e., an application will not be suspended but
will continue through the stages of the application
process).
3.2 Public Objection and Dispute
Resolution Process
The independent dispute resolution process is designed to
protect certain interests and rights. The process provides a
path for formal objections during evaluation of the
applications. It allows a party with standing to have its
objection considered before a panel of qualified experts.
A formal objection can be filed only on four enumerated
grounds, as described in this module. A formal objection
initiates a dispute resolution proceeding. In filing an
application for a gTLD, the applicant agrees to accept the
applicability of this gTLD dispute resolution process.
Similarly, an objector accepts the applicability of this gTLD
dispute resolution process by filing its objection.
As described in section 3.1 above, ICANN’s Governmental
Advisory Committee has a designated process for
providing advice to the ICANN Board of Directors on
matters affecting public policy issues, and these objection
procedures would not be applicable in such a case. The
GAC may provide advice on any topic and is not limited to Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-4
the grounds for objection enumerated in the public
objection and dispute resolution process.
3.2.1  Grounds for Objection
A formal objection may be filed on any one of the
following four grounds:
String Confusion Objection – The applied-for gTLD string is
confusingly similar to an existing TLD or to another appliedfor gTLD string in the same round of applications.
Legal Rights Objection – The applied-for gTLD string
infringes the existing legal rights of the objector.
Limited Public Interest Objection – The applied-for gTLD
string is contrary to generally accepted legal norms of
morality and public order that are recognized under
principles of international law.
Community Objection – There is substantial opposition to
the gTLD application from a significant portion of the
community to which the gTLD string may be explicitly or
implicitly targeted.
The rationales for these objection grounds are discussed in
the final report of the ICANN policy development process
for new gTLDs. For more information on this process, see
http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-
08aug07.htm.
3.2.2  Standing to Object
Objectors must satisfy standing requirements to have their
objections considered. As part of the dispute proceedings,
all objections will be reviewed by a panel of experts
designated by the applicable Dispute Resolution Service
Provider (DRSP) to determine whether the objector has
standing to object. Standing requirements for the four
objection grounds are:
Objection ground Who may object
String confusion Existing TLD operator or gTLD applicant in current round.
In the case where an IDN ccTLD Fast Track request has
been submitted before the public posting of gTLD
applications received, and the Fast Track requestor wishes
to file a string confusion objection to a gTLD application, the
Fast Track requestor will be granted standing.
Legal rights Rightsholders
Limited public interest No limitations on who may file – however, subject to a
“quick look” designed for early conclusion of frivolous and/or
abusive objectionsModule 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-5
Objection ground Who may object
Community Established institution associated with a clearly delineated
community
3.2.2.1  String Confusion Objection
Two types of entities have standing to object:
• An existing TLD operator may file a string confusion
objection to assert string confusion between an
applied-for gTLD and the TLD that it currently
operates.
• Any gTLD applicant in this application round may
file a string confusion objection to assert string
confusion between an applied-for gTLD and the
gTLD for which it has applied, where string
confusion between the two applicants has not
already been found in the Initial Evaluation. That is,
an applicant does not have standing to object to
another application with which it is already in a
contention set as a result of the Initial Evaluation.
In the case where an existing TLD operator successfully
asserts string confusion with an applicant, the application
will be rejected.
In the case where a gTLD applicant successfully asserts
string confusion with another applicant, the only possible
outcome is for both applicants to be placed in a
contention set and to be referred to a contention
resolution procedure (refer to Module 4, String Contention
Procedures). If an objection by one gTLD applicant to
another gTLD application is unsuccessful, the applicants
may both move forward in the process without being
considered in direct contention with one another.
3.2.2.2  Legal Rights Objection
A rightsholder has standing to file a legal rights objection.
The source and documentation of the existing legal rights
the objector is claiming (which may include either
registered or unregistered trademarks) are infringed by the
applied-for gTLD must be included in the filing.  
An intergovernmental organization (IGO) is eligible to file a
legal rights objection if it meets the criteria for registration
of a .INT domain name2
:
                                                         
2
See also http://www.iana.org/domains/int/policy/.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-6
a) An international treaty between or among national
governments must have established the organization;
and
b) The organization that is established must be widely
considered to have independent international legal
personality and must be the subject of and governed
by international law.
The specialized agencies of the UN and the organizations
having observer status at the UN General Assembly are
also recognized as meeting the criteria.
3.2.2.3  Limited Public Interest Objection
Anyone may file a Limited Public Interest Objection. Due to
the inclusive standing base, however, objectors are subject
to a “quick look” procedure designed to identify and
eliminate frivolous and/or abusive objections. An objection
found to be manifestly unfounded and/or an abuse of the
right to object may be dismissed at any time.
A Limited Public Interest objection would be manifestly
unfounded if it did not fall within one of the categories that
have been defined as the grounds for such an objection
(see subsection 3.5.3).
A Limited Public Interest objection that is manifestly
unfounded may also be an abuse of the right to object. An
objection may be framed to fall within one of the
accepted categories for Limited Public Interest objections,
but other facts may clearly show that the objection is
abusive. For example, multiple objections filed by the same
or related parties against a single applicant may constitute
harassment of the applicant, rather than a legitimate
defense of legal norms that are recognized under general
principles of international law. An objection that attacks
the applicant, rather than the applied-for string, could be
an abuse of the right to object.3
                                                         
3
The jurisprudence of the European Court of Human Rights offers specific examples of how the term “manifestly ill-founded” has
been interpreted in disputes relating to human rights. Article 35(3) of the European Convention on Human Rights provides:  “The
Court shall declare inadmissible any individual application submitted under Article 34 which it considers incompatible with the
provisions of the Convention or the protocols thereto, manifestly ill-founded, or an abuse of the right of application.” The ECHR
renders reasoned decisions on admissibility, pursuant to Article 35 of the Convention. (Its decisions are published on the Court’s
website http://www.echr.coe.int.) In some cases, the Court briefly states the facts and the law and then announces its decision,
without discussion or analysis. E.g., Decision as to the Admissibility of Application No. 34328/96 by Egbert Peree against the
Netherlands (1998). In other cases, the Court reviews the facts and the relevant legal rules in detail, providing an analysis to support
its conclusion on the admissibility of an application. Examples of such decisions regarding applications alleging violations of Article
10 of the Convention (freedom of expression) include:  Décision sur la recevabilité de la requête no 65831/01 présentée par Roger
Garaudy contre la France (2003); Décision sur la recevabilité de la requête no 65297/01 présentée par Eduardo Fernando Alves
Costa contre le Portugal (2004).Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-7
The quick look is the Panel’s first task, after its appointment
by the DRSP and is a review on the merits of the objection.
The dismissal of an objection that is manifestly unfounded
and/or an abuse of the right to object would be an Expert
Determination, rendered in accordance with Article 21 of
the New gTLD Dispute Resolution Procedure.
In the case where the quick look review does lead to the
dismissal of the objection, the proceedings that normally
follow the initial submissions (including payment of the full
advance on costs) will not take place, and it is currently
contemplated that the filing fee paid by the applicant
would be refunded, pursuant to Procedure Article 14(e).
3.2.2.4  Community Objection
Established institutions associated with clearly delineated
communities are eligible to file a community objection. The
community named by the objector must be a community
strongly associated with the applied-for gTLD string in the
application that is the subject of the objection. To qualify
for standing for a community objection, the objector must
prove both of the following:
It is an established institution – Factors that may be
considered in making this determination include, but are
not limited to:
• Level of global recognition of the institution;
• Length of time the institution has been in existence;
and
• Public historical evidence of its existence, such as
the presence of a formal charter or national or
international registration, or validation by a
government, inter-governmental organization, or
treaty. The institution must not have been
established solely in conjunction with the gTLD
application process.
It has an ongoing relationship with a clearly delineated
community – Factors that may be considered in making
this determination include, but are not limited to:
                                                                                                                                                                               
The jurisprudence of the European Court of Human Rights also provides examples of the abuse of the right of application being
sanctioned, in accordance with ECHR Article 35(3). See, for example, Décision partielle sur la recevabilité de la requête no
61164/00 présentée par Gérard Duringer et autres contre la France et de la requête no 18589/02 contre la France (2003).     Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-8
• The presence of mechanisms for participation in
activities, membership, and leadership;
• Institutional purpose related to the benefit of the
associated community;
• Performance of regular activities that benefit the
associated community; and
• The level of formal boundaries around the
community.
The panel will perform a balancing of the factors listed
above, as well as other relevant information, in making its
determination. It is not expected that an objector must
demonstrate satisfaction of each and every factor
considered in order to satisfy the standing requirements.
3.2.3    Dispute Resolution Service Providers
To trigger a dispute resolution proceeding, an objection
must be filed by the posted deadline date, directly with the
appropriate DRSP for each objection ground.
• The International Centre for Dispute Resolution has
agreed in principle to administer disputes brought
pursuant to string confusion objections.
• The Arbitration and Mediation Center of the World
Intellectual Property Organization has agreed in
principle to administer disputes brought pursuant to
legal rights objections.
• The International Center of Expertise of the
International Chamber of Commerce has agreed in
principle to administer disputes brought pursuant to
Limited Public Interest and Community Objections.
ICANN selected DRSPs on the basis of their relevant
experience and expertise, as well as their willingness and
ability to administer dispute proceedings in the new gTLD
Program. The selection process began with a public call for
expressions of interest4
followed by dialogue with those
candidates who responded. The call for expressions of
interest specified several criteria for providers, including
established services, subject matter expertise, global
capacity, and operational capabilities. An important
aspect of the selection process was the ability to recruit
                                                         
4
See http://www.icann.org/en/announcements/announcement-21dec07.htm. Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-9
panelists who will engender the respect of the parties to
the dispute.
3.2.4  Options in the Event of Objection
Applicants whose applications are the subject of an
objection have the following options:
The applicant can work to reach a settlement with the
objector, resulting in withdrawal of the objection or the
application;
The applicant can file a response to the objection and
enter the dispute resolution process (refer to Section 3.2); or
The applicant can withdraw, in which case the objector
will prevail by default and the application will not proceed
further.
If for any reason the applicant does not file a response to
an objection, the objector will prevail by default.
3.2.5    Independent Objector
A formal objection to a gTLD application may also be filed
by the Independent Objector (IO). The IO does not act on
behalf of any particular persons or entities, but acts solely in
the best interests of the public who use the global Internet.
In light of this public interest goal, the Independent
Objector is limited to filing objections on the grounds of
Limited Public Interest and Community.  
Neither ICANN staff nor the ICANN Board of Directors has
authority to direct or require the IO to file or not file any
particular objection. If the IO determines that an objection
should be filed, he or she will initiate and prosecute the
objection in the public interest.
Mandate and Scope - The IO may file objections against
“highly objectionable” gTLD applications to which no
objection has been filed. The IO is limited to filing two types
of objections:  (1) Limited Public Interest objections and (2)
Community objections. The IO is granted standing to file
objections on these enumerated grounds, notwithstanding
the regular standing requirements for such objections (see
subsection 3.1.2).
The IO may file a Limited Public Interest objection against
an application even if a Community objection has been
filed, and vice versa.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-10
The IO may file an objection against an application,
notwithstanding the fact that a String Confusion objection
or a Legal Rights objection was filed.
Absent extraordinary circumstances, the IO is not permitted
to file an objection to an application where an objection
has already been filed on the same ground.
The IO may consider public comment when making an
independent assessment whether an objection is
warranted. The IO will have access to application
comments received during the comment period.
In light of the public interest goal noted above, the IO shall
not object to an application unless at least one comment
in opposition to the application is made in the public
sphere.
Selection – The IO will be selected by ICANN, through an
open and transparent process, and retained as an
independent consultant. The Independent Objector will be
an individual with considerable experience and respect in
the Internet community, unaffiliated with any gTLD
applicant.
Although recommendations for IO candidates from the
community are welcomed, the IO must be and remain
independent and unaffiliated with any of the gTLD
applicants. The various rules of ethics for judges and
international arbitrators provide models for the IO to
declare and maintain his/her independence.
The IO’s (renewable) tenure is limited to the time necessary
to carry out his/her duties in connection with a single round
of gTLD applications.
Budget and Funding – The IO’s budget would comprise two
principal elements:  (a) salaries and operating expenses,
and (b) dispute resolution procedure costs – both of which
should be funded from the proceeds of new gTLD
applications.
As an objector in dispute resolution proceedings, the IO is
required to pay filing and administrative fees, as well as
advance payment of costs, just as all other objectors are
required to do. Those payments will be refunded by the
DRSP in cases where the IO is the prevailing party.
In addition, the IO will incur various expenses in presenting
objections before DRSP panels that will not be refunded,
regardless of the outcome. These expenses include the Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-11
fees and expenses of outside counsel (if retained) and the
costs of legal research or factual investigations.
3.3  Filing Procedures
The information included in this section provides a summary
of procedures for filing:
• Objections; and
• Responses to objections.
For a comprehensive statement of filing requirements
applicable generally, refer to the New gTLD Dispute
Resolution Procedure (“Procedure”) included as an
attachment to this module. In the event of any
discrepancy between the information presented in this
module and the Procedure, the Procedure shall prevail.
Note that the rules and procedures of each DRSP specific
to each objection ground must also be followed.
• For a String Confusion Objection, the applicable
DRSP Rules are the ICDR Supplementary Procedures
for ICANN’s New gTLD Program. These rules are
available in draft form and have been posted
along with this module.
• For a Legal Rights Objection, the applicable DRSP
Rules are the WIPO Rules for New gTLD Dispute
Resolution. These rules are available in draft form
and have been posted along with this module.
• For a Limited Public Interest Objection, the
applicable DRSP Rules are the Rules for Expertise of
the International Chamber of Commerce (ICC) 5
, as
supplemented by the ICC as needed.
• For a Community Objection, the applicable DRSP
Rules are the Rules for Expertise of the International
Chamber of Commerce (ICC)6
, as supplemented
by the ICC as needed.
3.3.1  Objection Filing Procedures
The procedures outlined in this subsection must be followed
by any party wishing to file a formal objection to an
                                                         
5
See http://www.iccwbo.org/court/expertise/id4379/index.html
6
Ibid.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-12
application that has been posted by ICANN. Should an
applicant wish to file a formal objection to another gTLD
application, it would follow these same procedures.
• All objections must be filed electronically with the
appropriate DRSP by the posted deadline date.
Objections will not be accepted by the DRSPs after
this date.
• All objections must be filed in English.
• Each objection must be filed separately. An
objector wishing to object to several applications
must file a separate objection and pay the
accompanying filing fees for each application that
is the subject of an objection. If an objector wishes
to object to an application on more than one
ground, the objector must file separate objections
and pay the accompanying filing fees for each
objection ground.
Each objection filed by an objector must include:
• The name and contact information of the objector.
• A statement of the objector’s basis for standing;
that is, why the objector believes it meets the
standing requirements to object.
• A description of the basis for the objection,
including:
 A statement giving the specific ground upon
which the objection is being filed.
 A detailed explanation of the validity of the
objection and why it should be upheld.
• Copies of any documents that the objector
considers to be a basis for the objection.
Objections are limited to 5000 words or 20 pages,
whichever is less, excluding attachments.
An objector must provide copies of all submissions to the
DRSP associated with the objection proceedings to the
applicant.
The DRSP will publish, and regularly update a list on its
website identifying all objections as they are filed. ICANN
will post on its website a notice of all objections filed once
the objection filing period has closed. Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-13
3.3.2  Objection Filing Fees
At the time an objection is filed, the objector is required to
pay a filing fee in the amount set and published by the
relevant DRSP. If the filing fee is not paid, the DRSP will
dismiss the objection without prejudice. See Section 1.5 of
Module 1 regarding fees.
Funding from ICANN for objection filing fees, as well as for
advance payment of costs (see subsection 3.4.7 below) is
available to the At-Large Advisory Committee (ALAC).
Funding for ALAC objection filing and dispute resolution
fees is contingent on publication by ALAC of its approved
process for considering and making objections. At a
minimum, the process for objecting to a gTLD application
will require: bottom-up development of potential
objections, discussion and approval of objections at the
Regional At-Large Organization (RALO) level, and a
process for consideration and approval of the objection by
the At-Large Advisory Committee.
Funding from ICANN for objection filing fees, as well as for
advance payment of costs, is available to individual
national governments in the amount of USD 50,000 with the
guarantee that a minimum of one objection per
government will be fully funded by ICANN where
requested. ICANN will develop a procedure for application
and disbursement of funds.
Funding available from ICANN is to cover costs payable to
the dispute resolution service provider and made directly
to the dispute resolution service provider; it does not cover
other costs such as fees for legal advice.
3.3.3   Response Filing Procedures
Upon notification that ICANN has published the list of all
objections filed (refer to subsection 3.3.1), the DRSPs will
notify the parties that responses must be filed within 30
calendar days of receipt of that notice. DRSPs will not
accept late responses. Any applicant that fails to respond
to an objection within the 30-day response period will be in
default, which will result in the objector prevailing.
• All responses must be filed in English.
• Each response must be filed separately. That is, an
applicant responding to several objections must file
a separate response and pay the accompanying
filing fee to respond to each objection.  Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-14
• Responses must be filed electronically.
Each response filed by an applicant must include:
• The name and contact information of the
applicant.
• A point-by-point response to the claims made by
the objector.
• Any copies of documents that it considers to be a
basis for the response.
       Responses are limited to 5000 words or 20 pages,
whichever is less, excluding attachments.
Each applicant must provide copies of all submissions to
the DRSP associated with the objection proceedings to the
objector.
3.3.4  Response Filing Fees
At the time an applicant files its response, it is required to
pay a filing fee in the amount set and published by the
relevant DRSP, which will be the same as the filing fee paid
by the objector. If the filing fee is not paid, the response will
be disregarded, which will result in the objector prevailing.
3.4  Objection Processing Overview
The information below provides an overview of the process
by which DRSPs administer dispute proceedings that have
been initiated. For comprehensive information, please refer
to the New gTLD Dispute Resolution Procedure (included as
an attachment to this module).
3.4.1  Administrative Review
Each DRSP will conduct an administrative review of each
objection for compliance with all procedural rules within 14
calendar days of receiving the objection. Depending on
the number of objections received, the DRSP may ask
ICANN for a short extension of this deadline.
If the DRSP finds that the objection complies with
procedural rules, the objection will be deemed filed, and
the proceedings will continue. If the DRSP finds that the
objection does not comply with procedural rules, the DRSP
will dismiss the objection and close the proceedings
without prejudice to the objector’s right to submit a new
objection that complies with procedural rules. The DRSP’s
review or rejection of the objection will not interrupt the
time limit for filing an objection.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-15
3.4.2  Consolidation of Objections
Once the DRSP receives and processes all objections, at its
discretion the DRSP may elect to consolidate certain
objections. The DRSP shall endeavor to decide upon
consolidation prior to issuing its notice to applicants that
the response should be filed and, where appropriate, shall
inform the parties of the consolidation in that notice.
An example of a circumstance in which consolidation
might occur is multiple objections to the same application
based on the same ground.
In assessing whether to consolidate objections, the DRSP
will weigh the efficiencies in time, money, effort, and
consistency that may be gained by consolidation against
the prejudice or inconvenience consolidation may cause.
The DRSPs will endeavor to have all objections resolved on
a similar timeline. It is intended that no sequencing of
objections will be established.
New gTLD applicants and objectors also will be permitted
to propose consolidation of objections, but it will be at the
DRSP’s discretion whether to agree to the proposal.
ICANN continues to strongly encourage all of the DRSPs to
consolidate matters whenever practicable.
3.4.3   Mediation
The parties to a dispute resolution proceeding are
encouraged—but not required—to participate in
mediation aimed at settling the dispute. Each DRSP has
experts who can be retained as mediators to facilitate this
process, should the parties elect to do so, and the DRSPs
will communicate with the parties concerning this option
and any associated fees.
If a mediator is appointed, that person may not serve on
the panel constituted to issue an expert determination in
the related dispute.
There are no automatic extensions of time associated with
the conduct of negotiations or mediation. The parties may
submit joint requests for extensions of time to the DRSP
according to its procedures, and the DRSP or the panel, if
appointed, will decide whether to grant the requests,
although extensions will be discouraged. Absent
exceptional circumstances, the parties must limit their
requests for extension to 30 calendar days.  Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-16
The parties are free to negotiate without mediation at any
time, or to engage a mutually acceptable mediator of
their own accord.
3.4.4  Selection of Expert Panels
A panel will consist of appropriately qualified experts
appointed to each proceeding by the designated DRSP.
Experts must be independent of the parties to a dispute
resolution proceeding. Each DRSP will follow its adopted
procedures for requiring such independence, including
procedures for challenging and replacing an expert for
lack of independence.
There will be one expert in proceedings involving a string
confusion objection.
There will be one expert, or, if all parties agree, three
experts with relevant experience in intellectual property
rights disputes in proceedings involving an existing legal
rights objection.
There will be three experts recognized as eminent jurists of
international reputation, with expertise in relevant fields as
appropriate, in proceedings involving a Limited Public
Interest objection.
There will be one expert in proceedings involving a
community objection.
Neither the experts, the DRSP, ICANN, nor their respective
employees, directors, or consultants will be liable to any
party in any action for damages or injunctive relief for any
act or omission in connection with any proceeding under
the dispute resolution procedures.
3.4.5  Adjudication
The panel may decide whether the parties shall submit any
written statements in addition to the filed objection and
response, and may specify time limits for such submissions.
In order to achieve the goal of resolving disputes rapidly
and at reasonable cost, procedures for the production of
documents shall be limited. In exceptional cases, the panel
may require a party to produce additional evidence.
Disputes will usually be resolved without an in-person
hearing. The panel may decide to hold such a hearing only
in extraordinary circumstances.  Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-17
3.4.6   Expert Determination
The DRSPs’ final expert determinations will be in writing and
will include:
• A summary of the dispute and findings;
• An identification of the prevailing party; and
• The reasoning upon which the expert determination
is based.
Unless the panel decides otherwise, each DRSP will publish
all decisions rendered by its panels in full on its website.
The findings of the panel will be considered an expert
determination and advice that ICANN will accept within
the dispute resolution process.
3.4.7   Dispute Resolution Costs
Before acceptance of objections, each DRSP will publish a
schedule of costs or statement of how costs will be
calculated for the proceedings that it administers under
this procedure. These costs cover the fees and expenses of
the members of the panel and the DRSP’s administrative
costs.
ICANN expects that string confusion and legal rights
objection proceedings will involve a fixed amount charged
by the panelists while Limited Public Interest and
community objection proceedings will involve hourly rates
charged by the panelists.
Within ten (10) business days of constituting the panel, the
DRSP will estimate the total costs and request advance
payment in full of its costs from both the objector and the
applicant. Each party must make its advance payment
within ten (10) days of receiving the DRSP’s request for
payment and submit to the DRSP evidence of such
payment. The respective filing fees paid by the parties will
be credited against the amounts due for this advance
payment of costs.
The DRSP may revise its estimate of the total costs and
request additional advance payments from the parties
during the resolution proceedings.
Additional fees may be required in specific circumstances;
for example, if the DRSP receives supplemental submissions
or elects to hold a hearing.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-18
If an objector fails to pay these costs in advance, the DRSP
will dismiss its objection and no fees paid by the objector
will be refunded.
If an applicant fails to pay these costs in advance, the
DSRP will sustain the objection and no fees paid by the
applicant will be refunded.
After the hearing has taken place and the panel renders its
expert determination, the DRSP will refund the advance
payment of costs to the prevailing party.
3.5  Dispute Resolution Principles
(Standards)
Each panel will use appropriate general principles
(standards) to evaluate the merits of each objection. The
principles for adjudication on each type of objection are
specified in the paragraphs that follow. The panel may also
refer to other relevant rules of international law in
connection with the standards.
The objector bears the burden of proof in each case.
The principles outlined below are subject to evolution
based on ongoing consultation with DRSPs, legal experts,
and the public.
3.5.1  String Confusion Objection
A DRSP panel hearing a string confusion objection will
consider whether the applied-for gTLD string is likely to result
in string confusion. String confusion exists where a string so
nearly resembles another that it is likely to deceive or cause
confusion. For a likelihood of confusion to exist, it must be
probable, not merely possible that confusion will arise in the
mind of the average, reasonable Internet user. Mere
association, in the sense that the string brings another string
to mind, is insufficient to find a likelihood of confusion.
3.5.2  Legal Rights Objection
In interpreting and giving meaning to GNSO
Recommendation 3 (“Strings must not infringe the existing
legal rights of others that are recognized or enforceable
under generally accepted and internationally recognized
principles of law”), a DRSP panel of experts presiding over a
legal rights objection will determine whether the potential
use of the applied-for gTLD by the applicant takes unfair
advantage of the distinctive character or the reputation of
the objector’s registered or unregistered trademark or
service mark (“mark”) or IGO name or acronym (as Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-19
identified in the treaty establishing the organization), or
unjustifiably impairs the distinctive character or the
reputation of the objector’s mark or IGO name or
acronym, or otherwise creates an impermissible likelihood
of confusion between the applied-for gTLD and the
objector’s mark or IGO name or acronym.
In the case where the objection is based on trademark
rights, the panel will consider the following non-exclusive
factors:
1. Whether the applied-for gTLD is identical or similar,
including in appearance, phonetic sound, or meaning,
to the objector’s existing mark.
2. Whether the objector’s acquisition and use of rights in
the mark has been bona fide.
3. Whether and to what extent there is recognition in the
relevant sector of the public of the sign corresponding
to the gTLD, as the mark of the objector, of the
applicant or of a third party.
4. Applicant’s intent in applying for the gTLD, including
whether the applicant, at the time of application for
the gTLD, had knowledge of the objector’s mark, or
could not have reasonably been unaware of that
mark, and including whether the applicant has
engaged in a pattern of conduct whereby it applied
for or operates TLDs or registrations in TLDs which are
identical or confusingly similar to the marks of others.
5. Whether and to what extent the applicant has used, or
has made demonstrable preparations to use, the sign
corresponding to the gTLD in connection with a bona
fide offering of goods or services or a bona fide
provision of information in a way that does not interfere
with the legitimate exercise by the objector of its mark
rights.
6. Whether the applicant has marks or other intellectual
property rights in the sign corresponding to the gTLD,
and, if so, whether any acquisition of such a right in the
sign, and use of the sign, has been bona fide, and
whether the purported or likely use of the gTLD by the
applicant is consistent with such acquisition or use.
7. Whether and to what extent the applicant has been
commonly known by the sign corresponding to the
gTLD, and if so, whether any purported or likely use of
the gTLD by the applicant is consistent therewith and
bona fide.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-20
8. Whether the applicant’s intended use of the gTLD
would create a likelihood of confusion with the
objector’s mark as to the source, sponsorship, affiliation,
or endorsement of the gTLD.
In the case where a legal rights objection has been filed by
an IGO, the panel will consider the following non-exclusive
factors:
1. Whether the applied-for gTLD is identical or similar,
including in appearance, phonetic sound or meaning,
to the name or acronym of the objecting IGO;
2. Historical coexistence of the IGO and the applicant’s
use of a similar name or acronym. Factors considered
may include:
a. Level of global recognition of both entities;
b. Length of time the entities have been in
existence;
c. Public historical evidence of their existence,
which may include whether the objecting IGO
has communicated its name or abbreviation
under Article 6ter of the Paris Convention for the
Protection of Industrial Property.
3. Whether and to what extent the applicant has used, or
has made demonstrable preparations to use, the sign
corresponding to the TLD in connection with a bona
fide offering of goods or services or a bona fide
provision of information in a way that does not interfere
with the legitimate exercise of the objecting IGO’s
name or acronym;
4. Whether and to what extent the applicant has been
commonly known by the sign corresponding to the
applied-for gTLD, and if so, whether any purported or
likely use of the gTLD by the applicant is consistent
therewith and bona fide; and
5. Whether the applicant’s intended use of the appliedfor gTLD would create a likelihood of confusion with the
objecting IGO’s name or acronym as to the source,
sponsorship, affiliation, or endorsement of the TLD.
3.5.3  Limited Public Interest Objection
An expert panel hearing a Limited Public Interest objection
will consider whether the applied-for gTLD string is contrary
to general principles of international law for morality and
public order.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-21
Examples of instruments containing such general principles
include:
• The Universal Declaration of Human Rights (UDHR)
• The International Covenant on Civil and Political
Rights (ICCPR)
• The Convention on the Elimination of All Forms of
Discrimination Against Women (CEDAW)
• The International Convention on the Elimination of
All Forms of Racial Discrimination
• Declaration on the Elimination of Violence against
Women
• The International Covenant on Economic, Social,
and Cultural Rights
• The Convention against Torture and Other Cruel,
Inhuman, or Degrading Treatment or Punishment
• The International Convention on the Protection of
the Rights of all Migrant Workers and Members of
their Families
• Slavery Convention
• Convention on the Prevention and Punishment of
the Crime of Genocide
• Convention on the Rights of the Child
Note that these are included to serve as examples, rather
than an exhaustive list. It should be noted that these
instruments vary in their ratification status. Additionally,
states may limit the scope of certain provisions through
reservations and declarations indicating how they will
interpret and apply certain provisions. National laws not
based on principles of international law are not a valid
ground for a Limited Public Interest objection.
Under these principles, everyone has the right to freedom
of expression, but the exercise of this right carries with it
special duties and responsibilities. Accordingly, certain
limited restrictions may apply.
The grounds upon which an applied-for gTLD string may be
considered contrary to generally accepted legal norms
relating to morality and public order that are recognized
under principles of international law are:
• Incitement to or promotion of violent lawless action; Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-22
• Incitement to or promotion of discrimination based
upon race, color, gender, ethnicity, religion or
national origin, or other similar types of
discrimination that violate generally accepted legal
norms recognized under principles of international
law;
• Incitement to or promotion of child pornography or
other sexual abuse of children; or
• A determination that an applied-for gTLD string
would be contrary to specific principles of
international law as reflected in relevant
international instruments of law.
The panel will conduct its analysis on the basis of the
applied-for gTLD string itself. The panel may, if needed, use
as additional context the intended purpose of the TLD as
stated in the application.
3.5.4  Community Objection
The four tests described here will enable a DRSP panel to
determine whether there is substantial opposition from a
significant portion of the community to which the string
may be targeted. For an objection to be successful, the
objector must prove that:
• The community invoked by the objector is a clearly
delineated community; and
• Community opposition to the application is
substantial; and
• There is a strong association between the
community invoked and the applied-for gTLD string;
and
• The application creates a likelihood of material
detriment to the rights or legitimate interests of a
significant portion of the community to which the
string may be explicitly or implicitly targeted. Each
of these tests is described in further detail below.
Community – The objector must prove that the community
expressing opposition can be regarded as a clearly
delineated community. A panel could balance a number
of factors to determine this, including but not limited to:
• The level of public recognition of the group as a
community at a local and/or global level;Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-23
• The level of formal boundaries around the
community and what persons or entities are
considered to form the community;
• The length of time the community has been in
existence;
• The global distribution of the community (this may
not apply if the community is territorial); and
• The number of people or entities that make up the
community.
If opposition by a number of people/entities is found, but
the group represented by the objector is not determined to
be a clearly delineated community, the objection will fail.
Substantial Opposition – The objector must prove
substantial opposition within the community it has identified
itself as representing. A panel could balance a number of
factors to determine whether there is substantial
opposition, including but not limited to:
• Number of expressions of opposition relative to the
composition of the community;
• The representative nature of entities expressing
opposition;
• Level of recognized stature or weight among
sources of opposition;
• Distribution or diversity among sources of
expressions of opposition, including:
 Regional
 Subsectors of community
 Leadership of community
 Membership of community
• Historical defense of the community in other
contexts; and
• Costs incurred by objector in expressing opposition,
including other channels the objector may have
used to convey opposition.
If some opposition within the community is determined, but
it does not meet the standard of substantial opposition, the
objection will fail.Module 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-24
Targeting – The objector must prove a strong association
between the applied-for gTLD string and the community
represented by the objector. Factors that could be
balanced by a panel to determine this include but are not
limited to:
• Statements contained in application;
• Other public statements by the applicant;
• Associations by the public.
If opposition by a community is determined, but there is no
strong association between the community and the
applied-for gTLD string, the objection will fail.
Detriment – The objector must prove that the application
creates a likelihood of material detriment to the rights or
legitimate interests of a significant portion of the
community to which the string may be explicitly or implicitly
targeted. An allegation of detriment that consists only of
the applicant being delegated the string instead of the
objector will not be sufficient for a finding of material
detriment.
Factors that could be used by a panel in making this
determination include but are not limited to:
• Nature and extent of damage to the reputation of
the community represented by the objector that
would result from the applicant’s operation of the
applied-for gTLD string;
• Evidence that the applicant is not acting or does
not intend to act in accordance with the interests
of the community or of users more widely, including
evidence that the applicant has not proposed or
does not intend to institute effective security
protection for user interests;
• Interference with the core activities of the
community that would result from the applicant’s
operation of the applied-for gTLD string;
• Dependence of the community represented by the
objector on the DNS for its core activities;
• Nature and extent of concrete or economic
damage to the community represented by the
objector that would result from the applicant’s
operation of the applied-for gTLD string; andModule 3
Dispute Resolution Procedures
Applicant Guidebook | version 2011-09-19
3-25
• Level of certainty that alleged detrimental
outcomes would occur.
If opposition by a community is determined, but there is no
likelihood of material detriment to the targeted community
resulting from the applicant’s operation of the applied-for
gTLD, the objection will fail.
The objector must meet all four tests in the standard for the
objection to prevail.DRAFT - New gTLD Program – Objection and
Dispute Resolution
Party with standing files objection directly
with Dispute Resolution Service Provider
(DRSP) for these grounds:
String Confusion
Legal Rights
Limited Public Interest; and/or
Community
Objector pays filing fee directly to DRSP
Objection filing
period closes
Objections specific to Limited
Public Interest are subject to
a “quick look,” designed to
identify and eliminate
frivolous and/or abusive
objections
Does applicant clear
all objections?
Applicant
withdraws
Yes No
10 Days
ICANN posts
notice of all
objections filed
30 Days
30 Days
10 Days
Advance payment
of costs due
Objection filed with
correct DRSP?
No – 7 Days to Correct
45 Days
Administrative
Review of
objections
Consolidation of
objections, if
applicable
Expert
Determination
DRSP appoints
panel
DRSPs notify
applicants of
relevant
objections
Applicant files
response and
pays filing fee
DRSP sends
estimation of
costs to parties
Objection filing
period opens
Applicant proceeds to
subsequent stage
DRSP posts
objection details
on its website
Yes
Objection meets
procedural rules?
Yes
Objection
dismissed
No
DRSP and ICANN
update respective
websites to reflect
determinationAttachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-1
Attachment to Module 3
New gTLD Dispute Resolution Procedure
These Procedures were designed with an eye toward timely and efficient dispute
resolution.  As part of the New gTLD Program, these Procedures apply to all proceedings
administered by each of the dispute resolution service providers (DRSP).  Each of the DRSPs
has a specific set of rules that will also apply to such proceedings.   Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-2
NEW GTLD DISPUTE RESOLUTION PROCEDURE
Article 1. ICANN’s New gTLD Program
(a) The Internet Corporation for Assigned Names and Numbers (“ICANN”) has
implemented a program for the introduction of new generic Top-Level Domain Names
(“gTLDs”) in the internet.  There will be a succession of rounds, during which applicants
may apply for new gTLDs, in accordance with terms and conditions set by ICANN.
(b) The new gTLD program includes a dispute resolution procedure, pursuant to which
disputes between a person or entity who applies for a new gTLD and a person or entity
who objects to that gTLD are resolved in accordance with this New gTLD Dispute
Resolution Procedure (the “Procedure”).
(c) Dispute resolution proceedings shall be administered by a Dispute Resolution Service
Provider (“DRSP”) in accordance with this Procedure and the applicable DRSP Rules
that are identified in Article 4(b).
(d) By applying for a new gTLD, an applicant accepts the applicability of this Procedure
and the applicable DRSP’s Rules that are identified in Article 4(b); by filing an
objection to a new gTLD, an objector accepts the applicability of this Procedure and
the applicable DRSP’s Rules that are identified in Article 4(b).  The parties cannot
derogate from this Procedure without the express approval of ICANN and from the
applicable DRSP Rules without the express approval of the relevant DRSP.
Article 2.  Definitions
(a) The “Applicant” or “Respondent” is an entity that has applied to ICANN for a new gTLD
and that will be the party responding to the Objection.
(b) The “Objector” is one or more persons or entities who have filed an objection against a
new gTLD for which an application has been submitted.
(c) The “Panel” is the panel of Experts, comprising one or three “Experts,” that has been
constituted by a DRSP in accordance with this Procedure and the applicable DRSP
Rules that are identified in Article 4(b).
(d) The “Expert Determination” is the decision upon the merits of the Objection that is
rendered by a Panel in a proceeding conducted under this Procedure and the
applicable DRSP Rules that are identified in Article 4(b).
(e) The grounds upon which an objection to a new gTLD may be filed are set out in full in
Module 3 of the Applicant Guidebook.  Such grounds are identified in this Procedure,
and are based upon the Final Report on the Introduction of New Generic Top-Level
Domains, dated 7 August 2007, issued by the ICANN Generic Names Supporting
Organization (GNSO), as follows:
(i) “String Confusion Objection” refers to the objection that the string comprising
the potential gTLD is confusingly similar to an existing top-level domain or
another string applied for in the same round of applications.
(ii) “Existing Legal Rights Objection” refers to the objection that the string
comprising the potential new gTLD infringes the existing legal rights of others Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-3
that are recognized or enforceable under generally accepted and
internationally recognized principles of law.
(iii) “Limited Public Interest Objection” refers to the objection that the string
comprising the potential new gTLD is contrary to generally accepted legal
norms relating to morality and public order that are recognized under
principles of international law.
(iv) “Community Objection” refers to the objection that there is substantial
opposition to the application from a significant portion of the community to
which the string may be explicitly or implicitly targeted.
(f) “DRSP Rules” are the rules of procedure of a particular DRSP that have been identified
as being applicable to objection proceedings under this Procedure.
Article 3. Dispute Resolution Service Providers
The various categories of disputes shall be administered by the following DRSPs:
(a) String Confusion Objections shall be administered by the International Centre for
Dispute Resolution.
(b) Existing Legal Rights Objections shall be administered by the Arbitration and Mediation
Center of the World Intellectual Property Organization.
(c) Limited Public Interest Objections shall be administered by the International Centre for
Expertise of the International Chamber of Commerce.
(d) Community Objections shall be administered by the International Centre for Expertise
of the International Chamber of Commerce.
Article 4. Applicable Rules
(a) All proceedings before the Panel shall be governed by this Procedure and by the DRSP
Rules that apply to a particular category of objection.  The outcome of the
proceedings shall be deemed an Expert Determination, and the members of the
Panel shall act as experts.
(b) The applicable DRSP Rules are the following:
(i) For a String Confusion Objection, the applicable DRSP Rules are the ICDR
Supplementary Procedures for ICANN’s New gTLD Program.
(ii) For an Existing Legal Rights Objection, the applicable DRSP Rules are the WIPO
Rules for New gTLD Dispute Resolution.
(iii) For a Limited Public Interest Objection, the applicable DRSP Rules are the Rules
for Expertise of the International Chamber of Commerce (ICC), as
supplemented by the ICC as needed.
(iv) For a Community Objection, the applicable DRSP Rules are the Rules for
Expertise of the International Chamber of Commerce (ICC), as supplemented
by the ICC as needed.
(c) In the event of any discrepancy between this Procedure and the applicable DRSP
Rules, this Procedure shall prevail.Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-4
(d) The place of the proceedings, if relevant, shall be the location of the DRSP that is
administering the proceedings.
(e) In all cases, the Panel shall ensure that the parties are treated with equality, and that
each party is given a reasonable opportunity to present its position.
Article 5. Language
(a) The language of all submissions and proceedings under this Procedure shall be English.
(b) Parties may submit supporting evidence in its original language, provided and subject
to the authority of the Panel to determine otherwise, that such evidence is
accompanied by a certified or otherwise official English translation of all relevant text.
Article 6. Communications and Time Limits
(a) All communications by the Parties with the DRSPs and Panels must be submitted
electronically.  A Party that wishes to make a submission that is not available in
electronic form (e.g., evidentiary models) shall request leave from the Panel to do so,
and the Panel, in its sole discretion, shall determine whether to accept the
non-electronic submission.
(b) The DRSP, Panel, Applicant, and Objector shall provide copies to one another of all
correspondence (apart from confidential correspondence between the Panel and
the DRSP and among the Panel) regarding the proceedings.
(c) For the purpose of determining the date of commencement of a time limit, a notice or
other communication shall be deemed to have been received on the day that it is
transmitted in accordance with paragraphs (a) and (b) of this Article.
(d) For the purpose of determining compliance with a time limit, a notice or other
communication shall be deemed to have been sent, made or transmitted if it is
dispatched in accordance with paragraphs (a) and (b) of this Article prior to or on the
day of the expiration of the time limit.
(e) For the purpose of calculating a period of time under this Procedure, such period shall
begin to run on the day following the day when a notice or other communication is
received.
(f) Unless otherwise stated, all time periods provided in the Procedure are calculated on
the basis of calendar days
Article 7. Filing of the Objection
(a) A person wishing to object to a new gTLD for which an application has been
submitted may file an objection (“Objection”).  Any Objection to a proposed new
gTLD must be filed before the published closing date for the Objection Filing period.
(b) The Objection must be filed with the appropriate DRSP, using a model form made
available by that DRSP, with copies to ICANN and the Applicant.
(c) The electronic addresses for filing Objections (the specific addresses shall be made
available once they are created by providers):
(i) A String Confusion Objection must be filed at: [●].Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-5
(ii) An Existing Legal Rights Objection must be filed at: [●].
(iii) A Limited Public Interest Objection must be filed at: [●].
(iv) A Community Objection must be filed at: [●].
(d) All Objections must be filed separately:
(i) An Objector who wishes to object to an application on more than one ground
must file separate objections with the appropriate DRSP(s).
(ii) An Objector who wishes to object to more than one gTLD must file separate
objections to each gTLD with the appropriate DRSP(s).
(e) If an Objection is filed with the wrong DRSP, that DRSP shall promptly notify the
Objector of the error and that DRSP shall not process the incorrectly filed Objection.
The Objector may then cure the error by filing its Objection with the correct DRSP
within seven (7) days of receipt of the error notice, failing which the Objection shall be
disregarded.  If the Objection is filed with the correct DRSP within seven (7) days of
receipt of the error notice but after the lapse of the time for submitting an Objection
stipulation by Article 7(a) of this Procedure, it shall be deemed to be within this time
limit.
Article 8. Content of the Objection
(a) The Objection shall contain, inter alia, the following information:
(i) The names and contact information (address, telephone number, email
address, etc.) of the Objector;
(ii) A statement of the Objector’s basis for standing; and
(iii) A description of the basis for the Objection, including:
(aa) A statement of the ground upon which the Objection is being filed, as
stated in Article 2(e) of this Procedure;
(bb) An explanation of the validity of the Objection and why the objection
should be upheld.
(b) The substantive portion of the Objection shall be limited to 5,000 words or 20 pages,
whichever is less, excluding attachments.  The Objector shall also describe and
provide copies of any supporting or official documents upon which the Objection is
based.
(c) At the same time as the Objection is filed, the Objector shall pay a filing fee in the
amount set in accordance with the applicable DRSP Rules and include evidence of
such payment in the Objection.  In the event that the filing fee is not paid within ten (10)
days of the receipt of the Objection by the DRSP, the Objection shall be dismissed
without prejudice.
Article 9. Administrative Review of the Objection
(a) The DRSP shall conduct an administrative review of the Objection for the purpose of
verifying compliance with Articles 5-8 of this Procedure and the applicable DRSP Rules,
and inform the Objector, the Applicant and ICANN of the result of its review within Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-6
fourteen (14) days of its receipt of the Objection.  The DRSP may extend this time limit
for reasons explained in the notification of such extension.
(b) If the DRSP finds that the Objection complies with Articles 5-8 of this Procedure and the
applicable DRSP Rules, the DRSP shall confirm that the Objection shall be registered for
processing.
(c) If the DRSP finds that the Objection does not comply with Articles 5-8 of this Procedure
and the applicable DRSP Rules, the DRSP shall have the discretion to request that any
administrative deficiencies in the Objection be corrected within five (5) days.  If the
deficiencies in the Objection are cured within the specified period but after the lapse
of the time limit for submitting an Objection stipulated by Article 7(a) of this Procedure,
the Objection shall be deemed to be within this time limit.
(d) If the DRSP finds that the Objection does not comply with Articles 5-8 of this Procedure
and the applicable DRSP Rules, and the deficiencies in the Objection are not
corrected within the period specified in Article 9(c), the DRSP shall dismiss the
Objection and close the proceedings, without prejudice to the Objector’s submission
of a new Objection that complies with this Procedure, provided that the Objection is
filed within the deadline for filing such Objections.  The DRSP’s review of the Objection
shall not interrupt the running of the time limit for submitting an Objection stipulated by
Article 7(a) of this Procedure.
(e)  Immediately upon registering an Objection for processing, pursuant to Article 9(b), the
DRSP shall post the following information about the Objection on its website: (i) the
proposed string to which the Objection is directed; (ii) the names of the Objector and
the Applicant; (ii) the grounds for the Objection; and (iv) the dates of the DRSP’s
receipt of the Objection.
Article 10. ICANN’s Dispute Announcement
(a) Within thirty (30) days of the deadline for filing Objections in relation to gTLD
applications in a given round, ICANN shall publish a document on its website
identifying all of the admissible Objections that have been filed (the “Dispute
Announcement”).  ICANN shall also directly inform each DRSP of the posting of the
Dispute Announcement.
(b) ICANN shall monitor the progress of all proceedings under this Procedure and shall
take steps, where appropriate, to coordinate with any DRSP in relation to individual
applications for which objections are pending before more than one DRSP.
Article 11.  Response to the Objection
(a) Upon receipt of the Dispute Announcement, each DRSP shall promptly send a notice
to: (i) each Applicant for a new gTLD to which one or more admissible Objections
have been filed with that DRSP; and (ii) the respective Objector(s).
(b) The Applicant shall file a response to each Objection (the “Response”).  The Response
shall be filed within thirty (30) days of the transmission of the notice by the DRSP
pursuant to Article 11(a).
(c) The Response must be filed with the appropriate DRSP, using a model form made
available by that DRSP, with copies to ICANN and the Objector.Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-7
(d) The Response shall contain, inter alia, the following information:
(i) The names and contact information (address, telephone number, email
address, etc.) of the Applicant; and
(ii) A point-by-point response to the statements made in the Objection.
(e) The substantive portion of the Response shall be limited to 5,000 words or 20 pages,
whichever is less, excluding attachments.  The Applicant shall also describe and
provide copies of any supporting or official documents upon which the Response is
based.
(f) At the same time as the Response is filed, the Applicant shall pay a filing fee in the
amount set and published by the relevant DRSP (which shall be the same as the filing
fee paid by the Objector) and include evidence of such payment in the Response.  In
the event that the filing fee is not paid within ten (10) days of the receipt of the
Response by the DRSP, the Applicant shall be deemed to be in default, any Response
disregarded and the Objection shall be deemed successful.
(g) If the DRSP finds that the Response does not comply with Articles 11(c) and (d)(1) of
this Procedure and the applicable DRSP Rules, the DRSP shall have the discretion to
request that any administrative deficiencies in the Response be corrected within five
(5) days.  If the administrative deficiencies in the Response are cured within the
specified period but after the lapse of the time limit for submitting a Response pursuant
to this Procedure, the Response shall be deemed to be within this time limit.
(g) If the Applicant fails to file a Response to the Objection within the 30-day time limit, the
Applicant shall be deemed to be in default and the Objection shall be deemed
successful.  No fees paid by the Applicant will be refunded in case of default.
Article 12. Consolidation of Objections
(a) The DRSP is encouraged, whenever possible and practicable, and as may be further
stipulated in the applicable DRSP Rules, to consolidate Objections, for example, when
more than one Objector has filed an Objection to the same gTLD on the same
grounds.  The DRSP shall endeavor to decide upon consolidation prior to issuing its
notice pursuant to Article 11(a) and, where appropriate, shall inform the parties of the
consolidation in that notice.
(b) If the DRSP itself has not decided to consolidate two or more Objections, any
Applicant or Objector may propose the consolidation of Objections within seven (7)
days of the notice given by the DRSP pursuant to Article 11(a).  If, following such a
proposal, the DRSP decides to consolidate certain Objections, which decision must be
made within 14 days of the notice given by the DRSP pursuant to Article 11(a), the
deadline for the Applicant’s Response in the consolidated proceeding shall be thirty
(30) days from the Applicant’s receipt of the DRSP’s notice of consolidation.
(c) In deciding whether to consolidate Objections, the DRSP shall weigh the benefits (in
terms of time, cost, consistency of decisions, etc.) that may result from the
consolidation against the possible prejudice or inconvenience that the consolidation
may cause.  The DRSP’s determination on consolidation shall be final and not subject
to appeal.
(d) Objections based upon different grounds, as summarized in Article 2(e), shall not be
consolidated.Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-8
Article 13. The Panel
(a) The DRSP shall select and appoint the Panel of Expert(s) within thirty (30) days after
receiving the Response.
(b) Number and specific qualifications of Expert(s):
(i) There shall be one Expert in proceedings involving a String Confusion
Objection.
(ii) There shall be one Expert or, if all of the Parties so agree, three Experts with
relevant experience in intellectual property rights disputes in proceedings
involving an Existing Legal Rights Objection.
(iii) There shall be three Experts recognized as eminent jurists of international
reputation, one of whom shall be designated as the Chair.  The Chair shall be
of a nationality different from the nationalities of the Applicant and of the
Objector, in proceedings involving a Limited Public Interest Objection.
(iv) There shall be one Expert in proceedings involving a Community Objection.
(c) All Experts acting under this Procedure shall be impartial and independent of the
parties.  The applicable DRSP Rules stipulate the manner by which each Expert shall
confirm and maintain their impartiality and independence.
(d) The applicable DRSP Rules stipulate the procedures for challenging an Expert and
replacing an Expert.
(e) Unless required by a court of law or authorized in writing by the parties, an Expert shall
not act in any capacity whatsoever, in any pending or future proceedings, whether
judicial, arbitral or otherwise, relating to the matter referred to expert determination
under this Procedure.
Article 14. Costs
(a) Each DRSP shall determine the costs for the proceedings that it administers under this
Procedure in accordance with the applicable DRSP Rules.  Such costs shall cover the
fees and expenses of the members of the Panel, as well as the administrative fees of
the DRSP (the “Costs”).
(b) Within ten (10) days of constituting the Panel, the DRSP shall estimate the total Costs
and request the Objector and the Applicant/Respondent each to pay in advance the
full amount of the Costs to the DRSP.  Each party shall make its advance payment of
Costs within ten (10) days of receiving the DRSP’s request for payment and submit to
the DRSP evidence of such payment.  The respective filing fees paid by the Parties shall
be credited against the amounts due for this advance payment of Costs.
(c) The DRSP may revise its estimate of the total Costs and request additional advance
payments from the parties during the proceedings.
(d) Failure to make an advance payment of Costs:
(i) If the Objector fails to make the advance payment of Costs, its Objection shall
be dismissed and no fees that it has paid shall be refunded.Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-9
(ii) If the Applicant fails to make the advance payment of Costs, the Objection will
be deemed to have been sustained and no fees that the Applicant has paid
shall be refunded.
(e) Upon the termination of the proceedings, after the Panel has rendered its Expert
Determination, the DRSP shall refund to the prevailing party, as determined by the
Panel, its advance payment(s) of Costs.
Article 15.  Representation and Assistance
(a) The parties may be represented or assisted by persons of their choice.
(b) Each party or party representative shall communicate the name, contact information
and function of such persons to the DRSP and the other party (or parties in case of
consolidation).
Article 16.  Negotiation and Mediation
(a) The parties are encouraged, but not required, to participate in negotiations and/or
mediation at any time throughout the dispute resolution process aimed at settling their
dispute amicably.
(b) Each DRSP shall be able to propose, if requested by the parties, a person who could
assist the parties as mediator.
(c) A person who acts as mediator for the parties shall not serve as an Expert in a dispute
between the parties under this Procedure or any other proceeding under this
Procedure involving the same gTLD.
(d) The conduct of negotiations or mediation shall not, ipso facto, be the basis for a
suspension of the dispute resolution proceedings or the extension of any deadline
under this Procedure.  Upon the joint request of the parties, the DRSP or (after it has
been constituted) the Panel may grant the extension of a deadline or the suspension
of the proceedings.  Absent exceptional circumstances, such extension or suspension
shall not exceed thirty (30) days and shall not delay the administration of any other
Objection.
(e) If, during negotiations and/or mediation, the parties agree on a settlement of the
matter referred to the DRSP under this Procedure, the parties shall inform the DRSP,
which shall terminate the proceedings, subject to the parties’ payment obligation
under this Procedure having been satisfied, and inform ICANN and the parties
accordingly.
Article 17. Additional Written Submissions
(a) The Panel may decide whether the parties shall submit any written statements in
addition to the Objection and the Response, and it shall fix time limits for such
submissions.
(b) The time limits fixed by the Panel for additional written submissions shall not exceed
thirty (30) days, unless the Panel, having consulted the DRSP, determines that
exceptional circumstances justify a longer time limit.Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-10
Article 18. Evidence
In order to achieve the goal of resolving disputes over new gTLDs rapidly and at reasonable
cost, procedures for the production of documents shall be limited.  In exceptional cases, the
Panel may require a party to provide additional evidence.
Article 19. Hearings
(a) Disputes under this Procedure and the applicable DRSP Rules will usually be resolved
without a hearing.
(b) The Panel may decide, on its own initiative or at the request of a party, to hold a
hearing only in extraordinary circumstances.
(c) In the event that the Panel decides to hold a hearing:
(i) The Panel shall decide how and where the hearing shall be conducted.
(ii) In order to expedite the proceedings and minimize costs, the hearing shall be
conducted by videoconference if possible.
(iii) The hearing shall be limited to one day, unless the Panel decides, in
exceptional circumstances, that more than one day is required for the hearing.
(iv) The Panel shall decide whether the hearing will be open to the public or
conducted in private.
Article 20. Standards
(a) For each category of Objection identified in Article 2(e), the Panel shall apply the
standards that have been defined by ICANN.
(b) In addition, the Panel may refer to and base its findings upon the statements and
documents submitted and any rules or principles that it determines to be applicable.
(c) The Objector bears the burden of proving that its Objection should be sustained in
accordance with the applicable standards.
Article 21. The Expert Determination
(a) The DRSP and the Panel shall make reasonable efforts to ensure that the Expert
Determination is rendered within forty-five (45) days of the constitution of the Panel.  In
specific circumstances such as consolidated cases and in consultation with the DRSP,
if significant additional documentation is requested by the Panel, a brief extension
may be allowed.
(b) The Panel shall submit its Expert Determination in draft form to the DRSP’s scrutiny as to
form before it is signed, unless such scrutiny is specifically excluded by the applicable
DRSP Rules.  The modifications proposed by the DRSP to the Panel, if any, shall address
only the form of the Expert Determination.  The signed Expert Determination shall be
communicated to the DRSP, which in turn will communicate that Expert Determination
to the Parties and ICANN.
(c) When the Panel comprises three Experts, the Expert Determination shall be made by a
majority of the Experts.  Attachment to Module 3
New gTLD Dispute Resolution Procedure
Applicant Guidebook | version 2011-09-19  P-11
(d) The Expert Determination shall be in writing, shall identify the prevailing party and shall
state the reasons upon which it is based.  The remedies available to an Applicant or an
Objector pursuant to any proceeding before a Panel shall be limited to the success or
dismissal of an Objection and to the refund by the DRSP to the prevailing party, as
determined by the Panel in its Expert Determination, of its advance payment(s) of
Costs pursuant to Article 14(e) of this Procedure and any relevant provisions of the
applicable DRSP Rules.
(e) The Expert Determination shall state the date when it is made, and it shall be signed by
the Expert(s).  If any Expert fails to sign the Expert Determination, it shall be
accompanied by a statement of the reason for the absence of such signature.
(f) In addition to providing electronic copies of its Expert Determination, the Panel shall
provide a signed hard copy of the Expert Determination to the DRSP, unless the DRSP
Rules provide for otherwise.
(g) Unless the Panel decides otherwise, the Expert Determination shall be published in full
on the DRSP’s website.
Article 22. Exclusion of Liability
In addition to any exclusion of liability stipulated by the applicable DRSP Rules, neither the
Expert(s), nor the DRSP and its employees, nor ICANN and its Board members, employees and
consultants shall be liable to any person for any act or omission in connection with any
proceeding conducted under this Procedure.
Article 23.  Modification of the Procedure
(a) ICANN may from time to time, in accordance with its Bylaws, modify this Procedure.
(b) The version of this Procedure that is applicable to a dispute resolution proceeding is
the version that was in effect on the day when the relevant application for a new gTLD
is submitted.1
See Article 19 of the gTLD Dispute Resolution Procedures.
2
See Article 14(b) of the gTLD Dispute Resolution Procedures.
3
See Article 14(c) of the gTLD Dispute Resolution Procedures.
   
International Centre for Dispute Resolution (ICDR)
Fees & Costs Schedule for String Confusion Objections
(Fee Schedule)
May 20, 2010
Administrative Filing Fees (non-refundable)
 
• US $2750 Filing Fee; per party; per objection.
This amount is due on all objections filed.
• US $1250
1
 Case Service Fee; per party; per objection.
This additional amount only becomes due if any type of hearing is conducted in
accordance with Article 19 of the gTLD Dispute Resolution Procedures.
 
Neutral Panel Compensation (limited to one arbitrator)
 
• US $6000
2
 per objector/applicant.
This is collected for all cases to be heard on documents only and includes all
arbitrator expenses.
• US $3000
3
 per party.
This is billed if any type of hearing is conducted.
o Same amount billed for each additional day of hearing beyond one day.
o Includes all travel time of the neutral.
o Does not include travel expenses which will be billed separatelyICDR - DRAFT Page 1 5/26/2010
International Centre for Dispute Resolution (ICDR)
Supplementary Procedures for String Confusion Objections
(DRSP Rules)
May 20, 2010
Impartiality and Independence of Experts
Article 1
1. Arbitrators, who shall be referred to as “Experts”, acting under the GTLD
DISPUTE RESOLUTION PROCEDURES and these Rules shall be impartial and
independent. Prior to accepting appointment, a prospective Expert shall
disclose to the DRSP any circumstance  likely to give rise to justifiable
doubts as to the Expert’s impartiality or independence. If, at any stage
during the proceedings, new circumstances arise that may give rise to
such doubts, an Expert shall promptly disclose such circumstances to the
parties and to the DRSP. Upon receipt of such information from an Expert
or a party, the DRSP shall communicate it to the other parties and to the
panel.
2. No party or anyone acting on its behalf shall have any  ex parte
communication relating to the case with any Expert.
Challenge of Experts
Article 2
1. A party may challenge any Expert whenever circumstances exist that give
rise to justifiable doubts as to the Expert’s impartiality or independence. A
party wishing to challenge an Expert shall send notice of the challenge to
the DRSP within 10 days after being  notified of the appointment of the
Expert or within 10 days after the  circumstances giving rise to the
challenge become known to that party.
2. The challenge shall state in writing the reasons for the challenge.
3. Upon receipt of such a challenge, the DRSP shall notify the other parties
of the challenge. Upon review of  the challenge the DRSP in its sole
discretion shall make the decision on the challenge and advise the parties
of its decision The challenged arbitrator may also withdraw from office
upon notice of the challenge. ICDR - DRAFT Page 2 5/26/2010
Replacement of an Expert
Article 3
If an Expert withdraws after a challenge, or the DRSP sustains the
challenge, or the DRSP determines  that there are sufficient reasons to
accept the resignation of an Expert, or an Expert dies, a substitute Expert
shall be appointed pursuant to the provisions of Article 13 of the  gTLD
Dispute Resolution Procedures.  
Waiver of Rules
Article 4
A party who knows that any provision of the Rules or requirement under
the Rules has not been complied with, but proceeds with the arbitration
without promptly stating an objection in writing thereto, shall be deemed
to have waived the right to object.
Confidentiality
Article 5
Confidential information disclosed during the proceedings by the parties or
by witnesses shall not be divulged by an Expert or by the DRSP.
Interpretation of Rules
Article 6
The tribunal shall interpret and apply these Rules insofar as they relate to
its powers and duties.
Exclusion of Liability
Article 7 ICDR - DRAFT Page 3 5/26/2010
1. Neither the International Centre for Dispute Resolution (ICDR), the
American Arbitration Association (AAA), nor any Expert in a proceeding
under the  GTLD Dispute Resolution Procedures and/or these Rules is a
necessary or proper party in judicial proceedings relating to the Objection
proceeding.
2. Parties to an Objection proceeding under the  GTLD Dispute Resolution
Procedures and/or these Rules shall  be deemed to have consented that
neither the ICDR, the AAA, nor any Expert shall be liable to any party in
any action for damages or injunctive relief for any act or omission in
connection with any Objection proceeding under the  GTLD Dispute
Resolution Procedures and/or these Rules. World Intellectual Property Organization Schedule of Fees and Costs:  
New gTLD Pre-Delegation Legal Rights Objection Procedure
(All amounts are in United States dollars)
(This Schedule of Fees and Costs may be amended by WIPO in accordance with the WIPO
Rules for New gTLD Dispute Resolution.)
DRSP Fee
1
DRSP Fee
Single-Expert Panel  2,000
Three-Expert Panel  3,000
Panel Fee
2
Base Panel Fee for Single Objection to Single Application Dispute
Single-Expert Panel  8,000
Three-Expert Panel  20,000
(Presiding Expert:  10,000;  Co-Expert:  5,000)
Panel Fee for Multiple Objections to Single Application:
3
 
60% of Regular Base Fee (to be paid per Objection filed)
Single-Expert Panel  4,800
Three-Expert Panel  12,000
(Presiding Expert:  6,000;  Co-Expert:  3,000)
Panel Fee for Multiple Objections filed by Same Objector to Multiple Applications:  
80% of Regular Base Fee (to be paid per Objection filed)
3
Single-Expert Panel  6,400
Three-Expert Panel  16,000
(Presiding Expert:  8,000;  Co-Expert:  4,000)
                                               
1
  See Articles 8(c) and 11(f) of the New gTLD Dispute Resolution Procedure.
2
  See Article 14 of the New gTLD Dispute Resolution Procedure.
3
  See Article 12 of the New gTLD Dispute Resolution Procedure. World Intellectual Property Organization Schedule of Fees and Costs:
New gTLD Pre-Delegation Legal Rights Objection Procedure
All Other Scenarios
3
In all other scenarios, the DRSP shall determine the applicable fees in consultation with the
Panel, taking into account the base fees stipulated above and the circumstances of the
consolidated objections and applications.  
Additional Advance Payments
Depending on the circumstances of the case, additional advance payments may be required to
be made.  In determining whether additional advance payments shall be required, the DRSP, in
consultation with the Panel, may consider the following non-exclusive factors:  the number of
Applications and/or Objections to the TLD, the number of parties, the complexity of the dispute,
the anticipated time required for rendering an Expert Determination, and the possible need for
hearings, phone or video conferences, or additional pleading rounds.   World Intellectual Property Organization
Rules for New gTLD Dispute Resolution for Existing Legal Rights Objections
(“WIPO Rules for New gTLD Dispute Resolution”)
(In effect as of June 20, 2011)
1. Scope of WIPO Rules for New gTLD Dispute Resolution in Relation to Procedure
(a) Set out below are the applicable WIPO Rules for New gTLD Dispute Resolution for Existing
Legal Rights Objections as referred to in Article 4 of the New gTLD Dispute Resolution
Procedure (“Procedure”) as approved by the Internet Corporation for Assigned Names and
Numbers (“ICANN”) on June 20, 2011.  The WIPO Rules for New gTLD Dispute Resolution are
to be read and used in connection with the Procedure which provides the basic framework for
the four categories of objections (as referred to in Articles 2 and 4 of the Procedure) arising from
Applications under ICANN’s New gTLD Program.
(b) The version of the WIPO Rules for New gTLD Dispute Resolution applicable to a proceeding
conducted under the Procedure is the version in effect on the day when the relevant Application
for a new gTLD is submitted (as referred to in Article 23(b) of the Procedure).
 
2. Definitions
Terms defined in the Procedure shall have the same meaning in the WIPO Rules for New gTLD
Dispute Resolution.  Words used in the singular shall include the plural and vice versa as the
context may require.
3. Communications
(a) Subject to Article 6 of the Procedure, except where otherwise agreed beforehand with the
WIPO Arbitration and Mediation Center (“Center”), and subject to the discretion of any
appointed Panel, any submission to the Center or to the Panel shall be made by electronic mail
(email) using arbiter.mail@wipo.int.
(b) In the event a party wishes to submit a hard copy or other non-electronic submission prior to
Panel appointment, it shall first request leave to do so from the Center;  the Center shall, in its
sole discretion, then determine whether to accept the non-electronic submission.  After Panel
appointment, parties are referred to Article 6(a) of the Procedure.  
  World Intellectual Property Organization Rules for New gTLD Dispute Resolution
4. Submission of Objection and Response
(a) In accordance with Articles 7 and 8 of the Procedure, the Objector shall transmit its
Objection using the Objection Model Form set out in Annex A hereto and posted on the Center’s
website and shall comply with the Center’s Filing Guidelines set out in Annex B hereto and
posted on the Center’s website.
(b) In accordance with Article 11 of the Procedure, the Applicant shall transmit its Response
using the Response Model Form set out in Annex C hereto and posted on the Center’s website
and shall comply with the Center’s Filing Guidelines set out in Annex B hereto and posted on
the Center’s website.
 
5. Center Review of Objections
(a) In accordance with Article 9 of the Procedure if an Objection is dismissed due to the
Objector’s failure to remedy an administrative deficiency, there shall be no refund of any DRSP
Fee paid by the Objector pursuant to Article 14 of the Procedure and Paragraph 10 of the WIPO
Rules for New gTLD Dispute Resolution.    
(b) If an Objector submits a new Objection within ten (10) calendar days of closure of a
proceeding as provided in Article 9(d) of the Procedure and Paragraph 5(a) of the WIPO Rules
for New gTLD Dispute Resolution to remedy an administratively deficient Objection, such new
Objection may be accompanied by a request for a DRSP Fee waiver, in whole or in part, for the
Center’s consideration in its sole discretion.
 
6. Appointment of Case Manager
(a) The Center shall advise the parties of the name and contact details of the Case Manager
who shall be responsible for all administrative matters relating to the dispute and
communications to the Panel.
(b) The Case Manager may provide administrative assistance to the parties or Panel, but shall
have no authority to decide matters of a substantive nature concerning the dispute.
 
7. Consolidation
(a) In accordance with Article 12 of the Procedure, the Center may, where possible and
practicable, and in its sole discretion, decide to consolidate Objections by appointing the same
Panel to decide multiple Objections sharing certain commonalities.  In the event of
consolidation, the Panel shall render individual Expert Determinations for each Objection.  
(b) A party may submit a consolidation request pursuant to Article 12(b) of the Procedure, or
may oppose any consolidation request submitted.  Any such opposition to a consolidation
request shall be provided within seven (7) calendar days of the consolidation request.  Any
consolidation request or opposition thereto shall be limited to 1,500 words in length.  
(c) In the case of consolidated Objections, the applicable reduced Panel fees are specified in
Annex D hereto and posted on the Center’s website.   World Intellectual Property Organization Rules for New gTLD Dispute Resolution
(d) Pursuant to Article 12 of the Procedure, in weighing the benefits that may result from
consolidation against the possible prejudice or inconvenience that consolidation may cause, the
Center in reaching its decision concerning consolidation, may take into account, inter alia, the
following non-exclusive factors:
(i) Whether the Objections concern the same or similar TLD(s);
(ii) Whether the same Objector files Objections concerning multiple TLD applications;
(iii) Whether in any consolidation request, or opposition thereto, the Objector or
Applicant relies on single or multiple mark(s);
(iv) The scope of evidence relied on by an Objector or Applicant in any Objection or
application;
(v) Any other arguments raised in any consolidation request, or opposition thereto;  
(vi) Expert availability to accept appointment.
(e) The Center’s decision on any consolidation of multiple Objections for Expert Determination
by the same Panel is of an administrative nature and shall be final.  The Center shall not be
required to state reasons for its decision.  
8. Panel Appointment Procedures
(a) The Center will maintain and publish on its website a publicly-available List of Experts.
(b) Pursuant to Article 13(b)(ii) of the Procedure, there shall be a Single-Expert Panel unless all
the Parties agree to the appointment of a Three-Expert Panel.  
 
(c) In the event of a Single-Expert Panel, the Center shall in its sole discretion appoint an Expert
from its List of Experts.
(d) In the event all the Parties agree to the appointment of a Three-Expert Panel, any such
agreement shall be communicated to the Center within five (5) calendar days of the Center’s
receipt of the Response filed in accordance with Article 11 of the Procedure and Paragraph 4(b)
of the WIPO Rules for New gTLD Dispute Resolution.
(i)      If Objections are not consolidated, and if the parties have communicated their
agreement on the appointment of a Three-Expert Panel, within five (5) days of
such communication each party shall separately submit to the Center
(notwithstanding Article 6(b) of the Procedure) the names of three (3) candidates
from the Center’s List of Experts, in the order of their respective preference, for
appointment by the Center as a Co-Expert.  In the event none of a party’s three (3)
candidates is available for appointment as a Co-Expert, the Center shall appoint
the Co-Expert in its sole discretion. World Intellectual Property Organization Rules for New gTLD Dispute Resolution
(ii) In the event of consolidation in accordance with Paragraph 7 of the WIPO Rules
for New gTLD Dispute Resolution, the Objectors or Applicants shall, as the case
may be, jointly submit the names of the three (3) candidates from the Center’s List
of Experts in order of preference (i.e., one list on behalf of all Objector(s) and one
list on behalf of all Applicant(s)).  If the Objectors or Applicants as the case may be
do not jointly agree on and submit the names of three (3) candidates within five (5)
calendar days of the parties’ communication to the Center on their agreement to
the appointment of a Three-Expert Panel, the Center shall in its sole discretion
appoint the Co-Experts.  
(iii)    The third Expert, who shall be the Presiding Expert, shall absent exceptional
circumstances be appointed by the Center from a list of five (5) candidates
submitted by the Center to the parties.  The Center’s selection of a Presiding
Expert shall be made in a manner that seeks to reasonably balance the
preferences of each party as communicated to the Center within five (5) calendar
days of the Center’s communication of the list of candidates to the parties.  
(iv)    Where any party fails to indicate its order of preference for the Presiding Expert to
the Center, the Center shall nevertheless proceed to appoint the Presiding Expert
in its sole discretion, taking into account any preferences of any other party.
9. Expert Impartiality and Independence
(a) In accordance with Article 13(c) of the Procedure, any prospective Expert shall, before
accepting appointment, disclose to the Center and parties any circumstance that might give rise
to justifiable doubt as to the Expert’s impartiality or independence, or confirm in writing that no
such circumstance exist by submitting to the Center a Declaration of Impartiality and
Independence using the form set out in Annex E hereto and posted on the Center’s website.
(b) If at any stage during a proceeding conducted under the Procedure, circumstances arise
that might give rise to justifiable doubt as to an Expert’s impartiality or independence, the Expert
shall promptly disclose such circumstances to the parties and the Center.  
(c) A party may challenge an Expert if circumstances exist which give rise to justifiable doubt as
to the Expert’s impartiality or independence.  A party may challenge an Expert whom it has
appointed or in whose appointment it concurred, only for reasons of which it becomes aware
after the appointment has been made.
 
(i)     A party challenging an Expert shall send notice to the Center and the other party,
stating the reasons for the challenge, within five (5) calendar days after being
notified of that Expert’s appointment or becoming aware of circumstances that it
considers give rise to justifiable doubt as to that Expert’s impartiality or
independence.
(ii)    The decision on the challenge shall be made by the Center in its sole discretion.
Such a decision is of an administrative nature and shall be final. The Center shall
not be required to state reasons for its decision.  In the event of an Expert’s
removal, the Center shall appoint a new Expert in accordance with the Procedure
and these WIPO Rules for New gTLD Dispute Resolution. World Intellectual Property Organization Rules for New gTLD Dispute Resolution
10. Fees
(a) The applicable fees for the Procedure for Existing Legal Rights Objections are specified in
Annex D hereto and posted on the Center’s website.  
(b) After the Expert Determination has been rendered or a proceeding conducted under the
Procedure has been terminated, the Center shall provide an accounting to the parties of the
payments received and, in consultation with any Panel, return any unexpended balance of the
Panel Fee to the parties.  
11. Confidentiality
(a) A party invoking the confidentiality of any information it wishes or is required to submit in any
Existing Legal Rights Objection proceeding conducted under the Procedure, shall submit the
request for confidentiality to the Center for the Panel’s consideration, stating the reasons for
which it considers the information to be confidential.  If the Panel decides that the information is
to be treated as confidential, it shall decide under which conditions and to whom the confidential
information may in part or in whole be disclosed and shall require any person to whom the
confidential information is to be disclosed to sign an appropriate confidentiality undertaking.
(b) Further to Article 6(b) of the Procedure, except in exceptional circumstances as decided by
the Panel and in consultation with the parties and the Center, no party or anyone acting on its
behalf shall have any ex parte communication with the Panel.
12. Mediation
Further to Article 16 of the Procedure, prior to the Panel rendering its Expert Determination in a
proceeding conducted under the Procedure, the parties may inform the Center that they wish to
participate in mediation to attempt to resolve the dispute and may request the Center to
administer the mediation.  In such event, unless both parties agree otherwise, the WIPO
Mediation Rules shall apply mutatis mutandis.  On request from the parties, and absent
exceptional circumstances, the Center’s mediation administration fee shall be waived.  
13. Effect of Court Proceedings
(a) The Objector and Applicant shall include in any Objection or Response relevant information
regarding any other legal proceedings concerning the TLD.  In the event that a party initiates
any legal proceedings during the pendency of a proceeding conducted under the Procedure, it
shall promptly notify the Center.
 
(b) In the event of any legal proceedings initiated prior to or during a proceeding conducted
under the Procedure, the Panel shall have the discretion to decide whether to suspend or
terminate such proceeding under the Procedure, or to proceed to an Expert Determination. World Intellectual Property Organization Rules for New gTLD Dispute Resolution
14. Termination
(a) If, before the Panel renders an Expert Determination, it becomes unnecessary or impossible
to continue a proceeding conducted under the Procedure for any reason, the Panel may in its
discretion terminate the proceeding.  
(b) If, prior to Panel appointment, it becomes unnecessary or impossible to continue a
proceeding conducted under the Procedure for any reason, the Center in consultation with the
parties and ICANN, may in its discretion terminate the proceeding.  
15. Amendments
Subject to the Procedure, the Center may amend these WIPO Rules for New gTLD Dispute
Resolution in its sole discretion.
 
16. Exclusion of Liability
Except in respect of deliberate wrongdoing, an Expert, the World Intellectual Property
Organization, and the Center shall not be liable to any party or ICANN for any act or omission in
connection with any proceeding conducted under the Procedure and the WIPO Rules for New
gTLD Dispute Resolution. gTLD Applicant
Guidebook
(v. 2011-09-19)
Module 4
19 September 2011Applicant Guidebook | version 2011-09-19
4-1
Module 4
String Contention Procedures
This module describes situations in which contention over
applied-for gTLD strings occurs, and the methods available
to applicants for resolving such contention cases.
4.1 String Contention
String contention occurs when either:
1. Two or more applicants for an identical gTLD string
successfully complete all previous stages of the
evaluation and dispute resolution processes; or
2. Two or more applicants for similar gTLD strings
successfully complete all previous stages of the
evaluation and dispute resolution processes, and the
similarity of the strings is identified as creating a
probability of user confusion if more than one of the
strings is delegated.
ICANN will not approve applications for proposed gTLD
strings that are identical or that would result in user
confusion, called contending strings. If either situation
above occurs, such applications will proceed to
contention resolution through either community priority
evaluation, in certain cases, or through an auction. Both
processes are described in this module. A group of
applications for contending strings is referred to as a
contention set.
(In this Applicant Guidebook, “similar” means strings so
similar that they create a probability of user confusion if
more than one of the strings is delegated into the root
zone.)
4.1.1 Identification of Contention Sets
Contention sets are groups of applications containing
identical or similar applied-for gTLD strings. Contention sets
are identified during Initial Evaluation, following review of
all applied-for gTLD strings. ICANN will publish preliminary
contention sets once the String Similarity review is
completed, and will update the contention sets as
necessary during the evaluation and dispute resolution
stages.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-2
Applications for identical gTLD strings will be automatically
assigned to a contention set. For example, if Applicant A
and Applicant B both apply for .TLDSTRING, they will be
identified as being in a contention set. Such testing for
identical strings also takes into consideration the code
point variants listed in any relevant IDN table. That is, two or
more applicants whose applied-for strings or designated
variants are variant strings according to an IDN table
submitted to ICANN would be considered in direct
contention with one another. For example, if one applicant
applies for string A and another applies for string B, and
strings A and B are variant TLD strings as defined in Module
1, then the two applications are in direct contention.
The String Similarity Panel will also review the entire pool of
applied-for strings to determine whether the strings
proposed in any two or more applications are so similar
that they would create a probability of user confusion if
allowed to coexist in the DNS. The panel will make such a
determination for each pair of applied-for gTLD strings. The
outcome of the String Similarity review described in Module
2 is the identification of contention sets among
applications that have direct or indirect contention
relationships with one another.
Two strings are in direct contention if they are identical or
similar to one another. More than two applicants might be
represented in a direct contention situation: if four different
applicants applied for the same gTLD string, they would all
be in direct contention with one another.
Two strings are in indirect contention if they are both in
direct contention with a third string, but not with one
another. The example that follows explains direct and
indirect contention in greater detail.
In Figure 4-1, Strings A and B are an example of direct
contention. Strings C and G are an example of indirect
contention. C and G both contend with B, but not with one
another. The figure as a whole is one contention set. A
contention set consists of all applications that are linked by
string contention to one another, directly or indirectly.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-3
Figure 4-1 – This diagram represents one contention set,
featuring both directly and indirectly contending strings.
While preliminary contention sets are determined during
Initial Evaluation, the final configuration of the contention
sets can only be established once the evaluation and
dispute resolution process stages have concluded. This is
because any application excluded through those
processes might modify a contention set identified earlier.
A contention set may be augmented, split into two sets, or
eliminated altogether as a result of an Extended Evaluation
or dispute resolution proceeding. The composition of a
contention set may also be modified as some applications
may be voluntarily withdrawn throughout the process.
Refer to Figure 4-2: In contention set 1, applications D and
G are eliminated. Application A is the only remaining
application, so there is no contention left to resolve.
In contention set 2, all applications successfully complete
Extended Evaluation and Dispute Resolution, so the original
contention set remains to be resolved.
In contention set 3, application F is eliminated. Since
application F was in direct contention with E and J, but E
and J are not in contention with one other, the original
contention set splits into two sets: one containing E and K in
direct contention, and one containing I and J. Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-4
Figure 4-2 – Resolution of string contention cannot begin
until all applicants within a contention set have
completed all applicable previous stages.
The remaining contention cases must then be resolved
through community priority evaluation or by other means,
depending on the circumstances. In the string contention
resolution stage, ICANN addresses each contention set to
achieve an unambiguous resolution.
As described elsewhere in this guidebook, cases of
contention might be resolved by community priority
evaluation or an agreement among the parties. Absent
that, the last-resort contention resolution mechanism will be
an auction.
4.1.2  Impact of String Confusion Dispute Resolution
Proceedings on Contention Sets
If an applicant files a string confusion objection against
another application (refer to Module 3), and the panel
finds that user confusion is probable (that is, finds in favor of
the objector), the two applications will be placed in direct
contention with each other. Thus, the outcome of a
dispute resolution proceeding based on a string confusion
objection would be a new contention set structure for the
relevant applications, augmenting the original contention
set.  Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-5
If an applicant files a string confusion objection against
another application, and the panel finds that string
confusion does not exist (that is, finds in favor of the
responding applicant), the two applications will not be
considered in direct contention with one another.
A dispute resolution outcome in the case of a string
confusion objection filed by another applicant will not
result in removal of an application from a previously
established contention set.
4.1.3 Self-Resolution of String Contention
Applicants that are identified as being in contention are
encouraged to reach a settlement or agreement among
themselves that resolves the contention. This may occur at
any stage of the process, once ICANN publicly posts the
applications received and the preliminary contention sets
on its website.
Applicants may resolve string contention in a manner
whereby one or more applicants withdraw their
applications. An applicant may not resolve string
contention by selecting a new string or by replacing itself
with a joint venture. It is understood that applicants may
seek to establish joint ventures in their efforts to resolve
string contention. However, material changes in
applications (for example, combinations of applicants to
resolve contention) will require re-evaluation. This might
require additional fees or evaluation in a subsequent
application round. Applicants are encouraged to resolve
contention by combining in a way that does not materially
affect the remaining application. Accordingly, new joint
ventures must take place in a manner that does not
materially change the application, to avoid being subject
to re-evaluation.
4.1.4  Possible Contention Resolution Outcomes
An application that has successfully completed all previous
stages and is no longer part of a contention set due to
changes in the composition of the contention set (as
described in subsection 4.1.1) or self-resolution by
applicants in the contention set (as described in subsection
4.1.3)  may proceed to the next stage.
An application that prevails in a contention resolution
procedure, either community priority evaluation or auction,
may proceed to the next stage.  Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-6
In some cases, an applicant who is not the outright winner
of a string contention resolution process can still proceed.
This situation is explained in the following paragraphs.
If the strings within a given contention set are all identical,
the applications are in direct contention with each other
and there can only be one winner that proceeds to the
next step.
However, where there are both direct and indirect
contention situations within a set, more than one string may
survive the resolution.
For example, consider a case where string A is in
contention with B, and B is in contention with C, but C is not
in contention with A. If A wins the contention resolution
procedure, B is eliminated but C can proceed since C is
not in direct contention with the winner and both strings
can coexist in the DNS without risk for confusion.
4.2 Community Priority Evaluation
Community priority evaluation will only occur if a
community-based applicant selects this option.
Community priority evaluation can begin once all
applications in the contention set have completed all
previous stages of the process.
The community priority evaluation is an independent
analysis. Scores received in the applicant reviews are not
carried forward to the community priority evaluation. Each
application participating in the community priority
evaluation begins with a score of zero.
4.2.1 Eligibility for Community Priority Evaluation
As described in subsection 1.2.3 of Module 1, all applicants
are required to identify whether their application type is:
• Community-based; or
• Standard.
Applicants designating their applications as communitybased are also asked to respond to a set of questions in the
application form to provide relevant information if a
community priority evaluation occurs.
Only community-based applicants are eligible to
participate in a community priority evaluation.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-7
At the start of the contention resolution stage, all
community-based applicants within remaining contention
sets will be notified of the opportunity to opt for a
community priority evaluation via submission of a deposit
by a specified date. Only those applications for which a
deposit has been received by the deadline will be scored
in the community priority evaluation. Following the
evaluation, the deposit will be refunded to applicants that
score 14 or higher.
Before the community priority evaluation begins, the
applicants who have elected to participate may be asked
to provide additional information relevant to the
community priority evaluation.
4.2.2 Community Priority Evaluation Procedure
Community priority evaluations for each eligible contention
set will be performed by a community priority panel
appointed by ICANN to review these applications. The
panel’s role is to determine whether any of the communitybased applications fulfills the community priority criteria.
Standard applicants within the contention set, if any, will
not participate in the community priority evaluation.
If a single community-based application is found to meet
the community priority criteria (see subsection 4.2.3 below),
that applicant will be declared to prevail in the community
priority evaluation and may proceed. If more than one
community-based application is found to meet the criteria,
the remaining contention between them will be resolved
as follows:
• In the case where the applications are in indirect
contention with one another (see subsection 4.1.1),
they will both be allowed to proceed to the next
stage. In this case, applications that are in direct
contention with any of these community-based
applications will be eliminated.
• In the case where the applications are in direct
contention with one another, these applicants will
proceed to an auction. If all parties agree and
present a joint request, ICANN may postpone the
auction for a three-month period while the parties
attempt to reach a settlement before proceeding
to auction. This is a one-time option; ICANN will
grant no more than one such request for each set
of contending applications.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-8
If none of the community-based applications are found to
meet the criteria, then all of the parties in the contention
set (both standard and community-based applicants) will
proceed to an auction.
Results of each community priority evaluation will be
posted when completed.
Applicants who are eliminated as a result of a community
priority evaluation are eligible for a partial refund of the
gTLD evaluation fee (see Module 1).
4.2.3 Community Priority Evaluation Criteria
The Community Priority Panel will review and score the one
or more community-based applications having elected the
community priority evaluation against four criteria as listed
below.
The scoring process is conceived to identify qualified
community-based applications, while preventing both
“false positives” (awarding undue priority to an application
that refers to a “community” construed merely to get a
sought-after generic word as a gTLD string) and “false
negatives” (not awarding priority to a qualified community
application). This calls for a holistic approach, taking
multiple criteria into account, as reflected in the process.
The scoring will be performed by a panel and be based on
information provided in the application plus other relevant
information available (such as public information regarding
the community represented). The panel may also perform
independent research, if deemed necessary to reach
informed scoring decisions.      
It should be noted that a qualified community application
eliminates all directly contending standard applications,
regardless of how well qualified the latter may be. This is a
fundamental reason for very stringent requirements for
qualification of a community-based application, as
embodied in the criteria below. Accordingly, a finding by
the panel that an application does not meet the scoring
threshold to prevail in a community priority evaluation is not
necessarily an indication the community itself is in some
way inadequate or invalid.
The sequence of the criteria reflects the order in which they
will be assessed by the panel. The utmost care has been
taken to avoid any "double-counting" - any negative
aspect found in assessing an application for one criterion Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-9
should only be counted there and should not affect the
assessment for other criteria.  
An application must score at least 14 points to prevail in a
community priority evaluation. The outcome will be
determined according to the procedure described in
subsection 4.2.2.
Criterion #1:  Community Establishment (0-4 points)
A maximum of 4 points is possible on the Community
Establishment criterion:
4 3 2 1 0
Community Establishment
High                                                       Low
As measured by:
A. Delineation (2)
2 1 0
Clearly
delineated,
organized, and
pre-existing
community.
Clearly
delineated and
pre-existing
community, but
not fulfilling the
requirements
for a score of
2.
Insufficient
delineation and
pre-existence for
a score of 1.
B. Extension (2)
2 1 0
Community of
considerable
size and
longevity.
Community of
either
considerable
size or
longevity, but
not fulfilling the
requirements
for a score of
2.
Community of
neither
considerable size
nor longevity.
This section relates to the community as explicitly identified
and defined according to statements in the application. Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-10
(The implicit reach of the applied-for string is not
considered here, but taken into account when scoring
Criterion #2, “Nexus between Proposed String and
Community.”)
Criterion 1 Definitions
 “Community” - Usage of the expression
“community” has evolved considerably from its
Latin origin – “communitas” meaning “fellowship” –
while still implying more of cohesion than a mere
commonality of interest. Notably, as “community” is
used throughout the application, there should be:
(a) an awareness and recognition of a community
among its members; (b) some understanding of the
community’s existence prior to September 2007
(when the new gTLD policy recommendations were
completed); and (c) extended tenure or
longevity—non-transience—into the future.
 "Delineation" relates to the membership of a
community, where a clear and straight-forward
membership definition scores high, while an
unclear, dispersed or unbound definition scores low.
 "Pre-existing" means that a community has been
active as such since before the new gTLD policy
recommendations were completed in September
2007.
 "Organized" implies that there is at least one entity
mainly dedicated to the community, with
documented evidence of community activities.
 “Extension” relates to the dimensions of the
community, regarding its number of members,
geographical reach, and foreseeable activity
lifetime, as further explained in the following.
 "Size" relates both to the number of members and
the geographical reach of the community, and will
be scored depending on the context rather than
on absolute numbers - a geographic location
community may count millions of members in a
limited location, a language community may have
a million members with some spread over the
globe, a community of service providers may have
"only" some hundred members although well
spread over the globe, just to mention some Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-11
examples - all these can be regarded as of
"considerable size."
 "Longevity" means that the pursuits of a community
are of a lasting, non-transient nature.
Criterion 1 Guidelines
With respect to “Delineation” and “Extension,” it should be
noted that a community can consist of legal entities (for
example, an association of suppliers of a particular
service), of individuals (for example, a language
community) or of a logical alliance of communities (for
example, an international federation of national
communities of a similar nature). All are viable as such,
provided the requisite awareness and recognition of the
community is at hand among the members. Otherwise the
application would be seen as not relating to a real
community and score 0 on both “Delineation” and
“Extension.”
With respect to “Delineation,” if an application satisfactorily
demonstrates all three relevant parameters (delineation,
pre-existing and organized), then it scores a 2.
With respect to “Extension,” if an application satisfactorily
demonstrates both community size and longevity, it scores
a 2.
Criterion #2:  Nexus between Proposed String and
Community (0-4 points)
A maximum of 4 points is possible on the Nexus criterion:
4 3 2 1 0
Nexus between String & Community
High                                                       Low
As measured by:
A. Nexus (3)
3 2 0
The string
matches the
name of the
community or
String identifies
the community,
but does not
qualify for a
String nexus
does not fulfill the
requirements for Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-12
3 2 0
is a well known
short-form or
abbreviation of
the community
name.
score of 3. a score of 2.
B. Uniqueness (1)
1 0
String has no
other
significant
meaning
beyond
identifying the
community
described in
the application.
String does not
fulfill the
requirement for a
score of 1.
This section evaluates the relevance of the string to the
specific community that it claims to represent.
Criterion 2 Definitions
 "Name" of the community means the established
name by which the community is commonly known
by others. It may be, but does not need to be, the
name of an organization dedicated to the
community.
 “Identify” means that the applied for string closely
describes the community or the community
members, without over-reaching substantially
beyond the community.
Criterion 2 Guidelines
With respect to “Nexus,” for a score of 3, the essential
aspect is that the applied-for string is commonly known by
others as the identification / name of the community.
With respect to “Nexus,” for a score of 2, the applied-for
string should closely describe the community or the
community members, without over-reaching substantially
beyond the community. As an example, a string could
qualify for a score of 2 if it is a noun that the typical
community member would naturally be called in the
context. If the string appears excessively broad (such as, for Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-13
example, a globally well-known but local tennis club
applying for “.TENNIS”) then it would not qualify for a 2.
With respect to “Uniqueness,” "significant meaning" relates
to the public in general, with consideration of the
community language context added.
"Uniqueness" will be scored both with regard to the
community context and from a general point of view. For
example, a string for a particular geographic location
community may seem unique from a general perspective,
but would not score a 1 for uniqueness if it carries another
significant meaning in the common language used in the
relevant community location. The phrasing "...beyond
identifying the community" in the score of 1 for "uniqueness"
implies a requirement that the string does identify the
community, i.e. scores 2 or 3 for "Nexus," in order to be
eligible for a score of 1 for "Uniqueness."
It should be noted that "Uniqueness" is only about the
meaning of the string - since the evaluation takes place to
resolve contention there will obviously be other
applications, community-based and/or standard, with
identical or confusingly similar strings in the contention set
to resolve, so the string will clearly not be "unique" in the
sense of "alone."    
Criterion #3:  Registration Policies (0-4 points)
A maximum of 4 points is possible on the Registration
Policies criterion:
4 3 2 1 0
Registration Policies
High                                                       Low
As measured by:
A. Eligibility (1)
1 0
Eligibility
restricted to
community
members.
Largely
unrestricted
approach to
eligibility.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-14
B. Name selection (1)
1 0
Policies
include name
selection rules
consistent with
the articulated
communitybased purpose
of the appliedfor gTLD.
Policies do not
fulfill the
requirements for
a score of 1.
C. Content and use (1)
1 0
Policies
include rules
for content and
use consistent
with the
articulated
communitybased purpose
of the appliedfor gTLD.
Policies do not
fulfill the
requirements for
a score of 1.
D. Enforcement (1)
1 0
Policies
include specific
enforcement
measures (e.g.
investigation
practices,
penalties,
takedown
procedures)
constituting a
coherent set
with
appropriate
appeal
mechanisms.
Policies do not
fulfill the
requirements for
a score of 1.
This section evaluates the applicant’s registration policies
as indicated in the application. Registration policies are the
conditions that the future registry will set for prospective Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-15
registrants, i.e. those desiring to register second-level
domain names under the registry.
Criterion 3 Definitions
• "Eligibility" means the qualifications that entities or
individuals must have in order to be allowed as
registrants by the registry.
• "Name selection" means the conditions that must
be fulfilled for any second-level domain name to
be deemed acceptable by the registry.
• "Content and use" means the restrictions stipulated
by the registry as to the content provided in and
the use of any second-level domain name in the
registry.
• "Enforcement" means the tools and provisions set
out by the registry to prevent and remedy any
breaches of the conditions by registrants.
Criterion 3 Guidelines
With respect to “Eligibility,” the limitation to community
"members" can invoke a formal membership but can also
be satisfied in other ways, depending on the structure and
orientation of the community at hand. For example, for a
geographic location community TLD, a limitation to
members of the community can be achieved by requiring
that the registrant's physical address is within the
boundaries of the location.
With respect to “Name selection,” “Content and use,” and
“Enforcement,” scoring of applications against these subcriteria will be done from a holistic perspective, with due
regard for the particularities of the community explicitly
addressed. For example, an application proposing a TLD
for a language community may feature strict rules
imposing this language for name selection as well as for
content and use, scoring 1 on both B and C above. It
could nevertheless include forbearance in the
enforcement measures for tutorial sites assisting those
wishing to learn the language and still score 1 on D. More
restrictions do not automatically result in a higher score. The
restrictions and corresponding enforcement mechanisms
proposed by the applicant should show an alignment with
the community-based purpose of the TLD and Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-16
demonstrate continuing accountability to the community
named in the application.
Criterion #4:  Community Endorsement (0-4 points)
4 3 2 1 0
Community Endorsement
High                                                       Low
As measured by:
A. Support (2)
2 1 0
Applicant is, or
has
documented
support from,
the recognized
community
institution(s)/
member
organization(s)
or has
otherwise
documented
authority to
represent the
community.
Documented
support from at
least one
group with
relevance, but
insufficient
support for a
score of 2.
Insufficient proof
of support for a
score of 1.
B. Opposition (2)
2 1 0
No opposition
of relevance.
Relevant
opposition from
one group of
non-negligible
size.
Relevant
opposition from
two or more
groups of nonnegligible size.
This section evaluates community support and/or
opposition to the application. Support and opposition will
be scored in relation to the communities explicitly
addressed as stated in the application, with due regard for
the communities implicitly addressed by the string. Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-17
Criterion 4 Definitions
 "Recognized" means the
institution(s)/organization(s) that, through
membership or otherwise, are clearly recognized by
the community members as representative of the
community.
 "Relevance" and "relevant" refer to the communities
explicitly and implicitly addressed. This means that
opposition from communities not identified in the
application but with an association to the appliedfor string would be considered relevant.
Criterion 4 Guidelines
With respect to “Support,” it follows that documented
support from, for example, the only national association
relevant to a particular community on a national level
would score a 2 if the string is clearly oriented to that
national level, but only a 1 if the string implicitly addresses
similar communities in other nations.
Also with respect to “Support,” the plurals in brackets for a
score of 2, relate to cases of multiple
institutions/organizations. In such cases there must be
documented support from institutions/organizations
representing a majority of the overall community
addressed in order to score 2.
The applicant will score a 1 for “Support” if it does not have
support from the majority of the recognized community
institutions/member organizations, or does not provide full
documentation that it has authority to represent the
community with its application. A 0 will be scored on
“Support” if the applicant fails to provide documentation
showing support from recognized community
institutions/community member organizations, or does not
provide documentation showing that it has the authority to
represent the community. It should be noted, however,
that documented support from groups or communities that
may be seen as implicitly addressed but have completely
different orientations compared to the applicant
community will not be required for a score of 2 regarding
support.
To be taken into account as relevant support, such
documentation must contain a description of the process
and rationale used in arriving at the expression of support. Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-18
Consideration of support is not based merely on the
number of comments or expressions of support received.
When scoring “Opposition,” previous objections to the
application as well as public comments during the same
application round will be taken into account and assessed
in this context. There will be no presumption that such
objections or comments would prevent a score of 2 or lead
to any particular score for “Opposition.” To be taken into
account as relevant opposition, such objections or
comments must be of a reasoned nature. Sources of
opposition that are clearly spurious, unsubstantiated, made
for a purpose incompatible with competition objectives, or
filed for the purpose of obstruction will not be considered
relevant.
4.3 Auction:  Mechanism of Last Resort
It is expected that most cases of contention will be
resolved by the community priority evaluation, or through
voluntary agreement among the involved applicants.
Auction is a tie-breaker method for resolving string
contention among the applications within a contention
set, if the contention has not been resolved by other
means.
An auction will not take place to resolve contention in the
case where the contending applications are for
geographic names (as defined in Module 2). In this case,
the applications will be suspended pending resolution by
the applicants.  
An auction will take place, where contention has not
already been resolved, in the case where an application
for a geographic name is in a contention set with
applications for similar strings that have not been identified
as geographic names.
In practice, ICANN expects that most contention cases will
be resolved through other means before reaching the
auction stage. However, there is a possibility that significant
funding will accrue to ICANN as a result of one or more
auctions. 1
                                                         
1
The purpose of an auction is to resolve contention in a clear, objective manner. It is planned that costs of the new gTLD program
will offset by fees, so any funds coming from a last resort contention resolution mechanism such as auctions would result (after
paying for the auction process) in additional funding. Any proceeds from auctions will be reserved and earmarked until the uses of Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-19
4.3.1  Auction Procedures
An auction of two or more applications within a contention
set is conducted as follows. The auctioneer successively
increases the prices associated with applications within the
contention set, and the respective applicants indicate their
willingness to pay these prices. As the prices rise, applicants
will successively choose to exit from the auction. When a
sufficient number of applications have been eliminated so
that no direct contentions remain (i.e., the remaining
applications are no longer in contention with one another
and all the relevant strings can be delegated as TLDs), the
auction will be deemed to conclude. At the auction’s
conclusion, the applicants with remaining applications will
pay the resulting prices and proceed toward delegation.
This procedure is referred to as an “ascending-clock
auction.”
This section provides applicants an informal introduction to
the practicalities of participation in an ascending-clock
auction. It is intended only as a general introduction and is
only preliminary. The detailed set of Auction Rules will be
available prior to the commencement of any auction
proceedings. If any conflict arises between this module
and the auction rules, the auction rules will prevail.
For simplicity, this section will describe the situation where a
contention set consists of two or more applications for
identical strings.
All auctions will be conducted over the Internet, with
participants placing their bids remotely using a web-based
                                                                                                                                                                           
funds are determined. Funds must be used in a manner that supports directly ICANN’s Mission and Core Values and also allows
ICANN to maintain its not for profit status.
Possible uses of auction funds include formation of a foundation with a clear mission and a transparent way to allocate funds to
projects that are of interest to the greater Internet community, such as grants to support new gTLD applications or registry operators
from communities in subsequent gTLD rounds, the creation of an ICANN-administered/community-based fund for specific projects
for the benefit of the Internet community, the creation of a registry continuity fund for the protection of registrants (ensuring that
funds would be in place to support the operation of a gTLD registry until a successor could be found), or establishment of a security
fund to expand use of secure protocols, conduct research, and support standards development organizations in accordance with
ICANN's security and stability mission.
The amount of funding resulting from auctions, if any, will not be known until all relevant applications have completed this step.
Thus, a detailed mechanism for allocation of these funds is not being created at present. However, a process can be preestablished to enable community consultation in the event that such funds are collected. This process will include, at a minimum,
publication of data on any funds collected, and public comment on any proposed models.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-20
software system designed especially for auction. The
auction software system will be compatible with current
versions of most prevalent browsers, and will not require the
local installation of any additional software.
Auction participants (“bidders”) will receive instructions for
access to the online auction site. Access to the site will be
password-protected and bids will be encrypted through
SSL. If a bidder temporarily loses connection to the Internet,
that bidder may be permitted to submit its bids in a given
auction round by fax, according to procedures described
in the auction rules. The auctions will generally be
conducted to conclude quickly, ideally in a single day.
The auction will be carried out in a series of auction rounds,
as illustrated in Figure 4-3. The sequence of events is as
follows:
1. For each auction round, the auctioneer will announce
in advance: (1) the start-of-round price, (2) the end-ofround price, and (3) the starting and ending times of
the auction round. In the first auction round, the startof-round price for all bidders in the auction will be USD
0. In later auction rounds, the start-of-round price will be
its end-of-round price from the previous auction round.
Figure 4-3 – Sequence of events during an ascending-clock auction.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-21
2.    During each auction round, bidders will be required to
submit a bid or bids representing their willingness to pay
within the range of intermediate prices between the
start-of-round and end-of-round prices. In this way a
bidder indicates its willingness to stay in the auction at
all prices through and including the end-of-auction
round price, or its wish to exit the auction at a price less
than the end-of-auction round price, called the exit
bid.
3. Exit is irrevocable. If a bidder exited the auction in a
previous auction round, the bidder is not permitted to
re-enter in the current auction round.
4. Bidders may submit their bid or bids at any time during
the auction round.
5. Only bids that comply with all aspects of the auction
rules will be considered valid. If more than one valid bid
is submitted by a given bidder within the time limit of
the auction round, the auctioneer will treat the last
valid submitted bid as the actual bid.
6. At the end of each auction round, bids become the
bidders’ legally-binding offers to secure the relevant
gTLD strings at prices up to the respective bid amounts,
subject to closure of the auction in accordance with
the auction rules. In later auction rounds, bids may be
used to exit from the auction at subsequent higher
prices.
7. After each auction round, the auctioneer will disclose
the aggregate number of bidders remaining in the
auction at the end-of-round prices for the auction
round, and will announce the prices and times for the
next auction round.
• Each bid should consist of a single price associated
with the application, and such price must be
greater than or equal to the start-of-round price.
• If the bid amount is strictly less than the end-ofround price, then the bid is treated as an exit bid at
the specified amount, and it signifies the bidder’s
binding commitment to pay up to the bid amount if
its application is approved.
• If the bid amount is greater than or equal to the
end-of-round price, then the bid signifies that the Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-22
bidder wishes to remain in the auction at all prices
in the current auction round, and it signifies the
bidder’s binding commitment to pay up to the endof-round price if its application is approved.
Following such bid, the application cannot be
eliminated within the current auction round.
• To the extent that the bid amount exceeds the
end-of-round price, then the bid is also treated as a
proxy bid to be carried forward to the next auction
round. The bidder will be permitted to change the
proxy bid amount in the next auction round, and
the amount of the proxy bid will not constrain the
bidder’s ability to submit any valid bid amount in
the next auction round.
• No bidder is permitted to submit a bid for any
application for which an exit bid was received in a
prior auction round. That is, once an application
has exited the auction, it may not return.
• If no valid bid is submitted within a given auction
round for an application that remains in the
auction, then the bid amount is taken to be the
amount of the proxy bid, if any, carried forward
from the previous auction round or, if none, the bid
is taken to be an exit bid at the start-of-round price
for the current auction round.
8. This process continues, with the auctioneer increasing
the price range for each given TLD string in each
auction round, until there is one remaining bidder at
the end-of-round price. After an auction round in which
this condition is satisfied, the auction concludes and
the auctioneer determines the clearing price. The last
remaining application is deemed the successful
application, and the associated bidder is obligated to
pay the clearing price.
Figure 4-4 illustrates how an auction for five contending
applications might progress.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-23
Figure 4-4 – Example of an auction for five mutually-contending
applications.
• Before the first auction round, the auctioneer
announces the end-of-round price P1.
• During Auction round 1, a bid is submitted for each
application. In Figure 4-4, all five bidders submit bids
of at least P1. Since the aggregate demand
exceeds one, the auction proceeds to Auction
round 2. The auctioneer discloses that five
contending applications remained at P1 and
announces the end-of-round price P2.
• During Auction round 2, a bid is submitted for each
application. In Figure 4-4, all five bidders submit bids
of at least P2. The auctioneer discloses that five
contending applications remained at P2 and
announces the end-of-round price P3.
• During Auction round 3, one of the bidders submits
an exit bid at slightly below P3, while the other four
bidders submit bids of at least P3. The auctioneer
discloses that four contending applications
remained at P3 and announces the end-of-round
price P4.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-24
• During Auction round 4, one of the bidders submits
an exit bid midway between P3 and P4, while the
other three remaining bidders submit bids of at least
P4. The auctioneer discloses that three contending
applications remained at P4 and announces the
end-of-auction round price P5.
• During Auction round 5, one of the bidders submits
an exit bid at slightly above P4, and one of the
bidders submits an exit bid at Pc midway between
P4 and P5. The final bidder submits a bid greater
than Pc. Since the aggregate demand at P5 does
not exceed one, the auction concludes in Auction
round 5. The application associated with the
highest bid in Auction round 5 is deemed the
successful application. The clearing price is Pc, as
this is the lowest price at which aggregate demand
can be met.
To the extent possible, auctions to resolve multiple string
contention situations will be conducted simultaneously.
4.3.1.1 Currency
For bids to be comparable, all bids in the auction will be
submitted in any integer (whole) number of US dollars.
4.3.1.2 Fees
A bidding deposit will be required of applicants
participating in the auction, in an amount to be
determined. The bidding deposit must be transmitted by
wire transfer to a specified bank account specified by
ICANN or its auction provider at a major international bank,
to be received in advance of the auction date. The
amount of the deposit will determine a bidding limit for
each bidder: the bidding deposit will equal 10% of the
bidding limit; and the bidder will not be permitted to submit
any bid in excess of its bidding limit.
In order to avoid the need for bidders to pre-commit to a
particular bidding limit, bidders may be given the option of
making a specified deposit that will provide them with
unlimited bidding authority for a given application. The
amount of the deposit required for unlimited bidding
authority will depend on the particular contention set and
will be based on an assessment of the possible final prices
within the auction.  Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-25
All deposits from nondefaulting losing bidders will be
returned following the close of the auction.
4.3.2 Winning Bid Payments
Any applicant that participates in an auction will be
required to sign a bidder agreement that acknowledges its
rights and responsibilities in the auction, including that its
bids are legally binding commitments to pay the amount
bid if it wins (i.e., if its application is approved), and to enter
into the prescribed registry agreement with ICANN—
together with a specified penalty for defaulting on
payment of its winning bid or failing to enter into the
required registry agreement.
The winning bidder in any auction will be required to pay
the full amount of the final price within 20 business days of
the end of the auction. Payment is to be made by wire
transfer to the same international bank account as the
bidding deposit, and the applicant’s bidding deposit will
be credited toward the final price.
In the event that a bidder anticipates that it would require
a longer payment period than 20 business days due to
verifiable government-imposed currency restrictions, the
bidder may advise ICANN well in advance of the auction
and ICANN will consider applying a longer payment period
to all bidders within the same contention set.
Any winning bidder for whom the full amount of the final
price is not received within 20 business days of the end of
an auction is subject to being declared in default. At their
sole discretion, ICANN and its auction provider may delay
the declaration of default for a brief period, but only if they
are convinced that receipt of full payment is imminent.
Any winning bidder for whom the full amount of the final
price is received within 20 business days of the end of an
auction retains the obligation to execute the required
registry agreement within 90 days of the end of auction.
Such winning bidder who does not execute the agreement
within 90 days of the end of the auction is subject to being
declared in default. At their sole discretion, ICANN and its
auction provider may delay the declaration of default for
a brief period, but only if they are convinced that
execution of the registry agreement is imminent.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-26
4.3.3 Post-Default Procedures
Once declared in default, any winning bidder is subject to
immediate forfeiture of its position in the auction and
assessment of default penalties. After a winning bidder is
declared in default, the remaining bidders will receive an
offer to have their applications accepted, one at a time, in
descending order of their exit bids. In this way, the next
bidder would be declared the winner subject to payment
of its last bid price. The same default procedures and
penalties are in place for any runner-up bidder receiving
such an offer.
Each bidder that is offered the relevant gTLD will be given
a specified period—typically, four business days—to
respond as to whether it wants the gTLD. A bidder who
responds in the affirmative will have 20 business days to
submit its full payment. A bidder who declines such an offer
cannot revert on that statement, has no further obligations
in this context and will not be considered in default.
The penalty for defaulting on a winning bid will equal 10%
of the defaulting bid.2
  Default penalties will be charged
against any defaulting applicant’s bidding deposit before
the associated bidding deposit is returned.
4.4  Contention Resolution and Contract
Execution
An applicant that has been declared the winner of a
contention resolution process will proceed by entering into
the contract execution step. (Refer to section 5.1 of
Module 5.)
If a winner of the contention resolution procedure has not
executed a contract within 90 days of the decision, ICANN
has the right to deny that application and extend an offer
to the runner-up applicant, if any, to proceed with its
application. For example, in an auction, another applicant
who would be considered the runner-up applicant might
proceed toward delegation. This offer is at ICANN’s option
only. The runner-up applicant in a contention resolution
process has no automatic right to an applied-for gTLD
                                                         
2
If bidders were given the option of making a specified deposit that provided them with unlimited bidding authority for a given
application and if the winning bidder utilized this option, then the penalty for defaulting on a winning bid will be the lesser of the
following: (1) 10% of the defaulting bid, or (2) the specified deposit amount that provided the bidder with unlimited bidding authority.Module 4
String Contention
Applicant Guidebook | version 2011-09-19
4-27
string if the first place winner does not execute a contract
within a specified time. If the winning applicant can
demonstrate that it is working diligently and in good faith
toward successful completion of the steps necessary for
entry into the registry agreement, ICANN may extend the
90-day period at its discretion. Runner-up applicants have
no claim of priority over the winning application, even after
what might be an extended period of negotiation.DRAFT - New gTLD Program - String Contention
Initial Evaluation (IE)
String Review
Transition to
Delegation
String Contention
IE + EE
+ Dispute Res
Application/
Admin Check
No
Applicant submits
application in TLD
Application System
(TAS).
IE, Extended Evaluation (EE), and Dispute
Resolution continue. Some applications may not
pass certain elements of the review process,
which may alter the contention sets.
Is the applied-for gTLD in
a contention set?
Applicant enters
Transition to
Delegation phase
ICANN publishes list of all
complete applications.
Applicant elects whether to designate
application as community-based.
Have one or more
community-based
applicant(s) elected
community priority?
No
Does one clear
winner emerge?
Yes
No
Yes
Yes
ICANN runs algorithm
for all applied-for gTLDs
against all other
applied-for gTLDs.
String Similarity Panel
performs analysis, using
algorithm results, to group
similar and identical
strings into contention
sets.
Community
priority
evaluation
Applicants with
contending strings
participate in auction:
One or more parties
proceed to
subsequent stage
Applicants are encouraged
to self-resolve string
contention anytime prior to
the contention resolution
process.
ICANN communicates the
results of the String
Similarity review, including
contention sets.
Applicant begins
application process.gTLD Applicant
Guidebook
(v. 2011-09-19)
Module 5
19 September 2011Applicant Guidebook | version 2011-09-19
5-1
Module 5
Transition to Delegation
This module describes the final steps required of an
applicant for completion of the process, including
execution of a registry agreement with ICANN and
preparing for delegation of the new gTLD into the root
zone.
5.1 Registry Agreement
All applicants that have successfully completed the
evaluation process—including, if necessary, the dispute
resolution and string contention processes—are required to
enter into a registry agreement with ICANN before
proceeding to delegation.
After the close of each stage in the process, ICANN will
send a notification to those successful applicants that are
eligible for execution of a registry agreement at that time.
To proceed, applicants will be asked to provide specified
information for purposes of executing the registry
agreement:
1. Documentation of the applicant’s continued
operations instrument (see Specification 8 to the
agreement).
2. Confirmation of contact information and signatory
to the agreement.
3. Notice of any material changes requested to the
terms of the agreement.
4. The applicant must report: (i) any ownership
interest it holds in any registrar or reseller of
registered names, (ii) if known, any ownership
interest that a registrar or reseller of registered
names holds in the applicant, and (iii) if the
applicant controls, is controlled by, or is under
common control with any registrar or reseller of
registered names. ICANN retains the right to refer
an application to a competition authority prior to
entry into the registry agreement if it is determined
that the registry-registrar cross-ownership Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-2
arrangements might raise competition issues. For
this purpose "control" (including the terms
“controlled by” and “under common control with”)
means the possession, directly or indirectly, of the
power to direct or cause the direction of the
management or policies of a person or entity,
whether through the ownership of securities, as
trustee or executor, by serving as a member of a
board of directors or equivalent governing body, by
contract, by credit arrangement or otherwise.
To ensure that an applicant continues to be a going
concern in good legal standing, ICANN reserves the right
to ask the applicant to submit additional updated
documentation and information before entering into the
registry agreement.
ICANN will begin processing registry agreements one
month after the date of the notification to successful
applicants. Requests will be handled in the order the
complete information is received.
Generally, the process will include formal approval of the
agreement without requiring additional Board review, so
long as:  the application passed all evaluation criteria;
there are no material changes in circumstances; and there
are no material changes to the base agreement. There
may be other cases where the Board requests review of an
application.
Eligible applicants are expected to have executed the
registry agreement within nine (9) months of the
notification date. Failure to do so may result in loss of
eligibility, at ICANN’s discretion. An applicant may request
an extension of this time period for up to an additional nine
(9) months if it can demonstrate, to ICANN’s reasonable
satisfaction, that it is working diligently and in good faith
toward successfully completing the steps necessary for
entry into the registry agreement.
The registry agreement can be reviewed in the
attachment to this module. Certain provisions in the
agreement are labeled as applicable to governmental
and intergovernmental entities only. Private entities, even if
supported by a government or IGO, would not ordinarily
be eligible for these special provisions.
All successful applicants are expected to enter into the
agreement substantially as written. Applicants may request Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-3
and negotiate terms by exception; however, this extends
the time involved in executing the agreement. In the event
that material changes to the agreement are requested,
these must first be approved by the ICANN Board of
Directors before execution of the agreement.
ICANN’s Board of Directors has ultimate responsibility for
the New gTLD Program. The Board reserves the right to
individually consider an application for a new gTLD to
determine whether approval would be in the best interest
of the Internet community. Under exceptional
circumstances, the Board may individually consider a gTLD
application. For example, the Board might individually
consider an application as a result of GAC Advice on New
gTLDs or of the use of an ICANN accountability
mechanism.
5.2 Pre-Delegation Testing
Each applicant will be required to complete predelegation technical testing as a prerequisite to
delegation into the root zone. This pre-delegation test must
be completed within the time period specified in the
registry agreement.
The purpose of the pre-delegation technical test is to verify
that the applicant has met its commitment to establish
registry operations in accordance with the technical and
operational criteria described in Module 2.
The test is also intended to indicate that the applicant can
operate the gTLD in a stable and secure manner. All
applicants will be tested on a pass/fail basis according to
the requirements that follow.
The test elements cover both the DNS server operational
infrastructure and registry system operations. In many cases
the applicant will perform the test elements as instructed
and provide documentation of the results to ICANN to
demonstrate satisfactory performance. At ICANN’s
discretion, aspects of the applicant’s self-certification
documentation can be audited either on-site at the
services delivery point of the registry or elsewhere as
determined by ICANN.
5.2.1  Testing Procedures
The applicant may initiate the pre-delegation test by
submitting to ICANN the Pre-Delegation form and Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-4
accompanying documents containing all of the following
information:
• All name server names and IPv4/IPv6 addresses to
be used in serving the new TLD data;
• If using anycast, the list of names and IPv4/IPv6
unicast addresses allowing the identification of
each individual server in the anycast sets;
• If IDN is supported, the complete IDN tables used in
the registry system;
• A test zone for the new TLD must be signed at test
time and the valid key-set to be used at the time of
testing must be provided to ICANN in the
documentation, as well as the TLD DNSSEC Policy
Statement (DPS);
• The executed agreement between the selected
escrow agent and the applicant; and
• Self-certification documentation as described
below for each test item.
ICANN will review the material submitted and in some
cases perform tests in addition to those conducted by the
applicant. After testing, ICANN will assemble a report with
the outcome of the tests and provide that report to the
applicant.
Any clarification request, additional information request, or
other request generated in the process will be highlighted
and listed in the report sent to the applicant.
ICANN may request the applicant to complete load tests
considering an aggregated load where a single entity is
performing registry services for multiple TLDs.
Once an applicant has met all of the pre-delegation
testing requirements, it is eligible to request delegation of its
applied-for gTLD.
If an applicant does not complete the pre-delegation
steps within the time period specified in the registry
agreement, ICANN reserves the right to terminate the
registry agreement.Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-5
5.2.2   Test Elements:  DNS Infrastructure
The first set of test elements concerns the DNS infrastructure
of the new gTLD. In all tests of the DNS infrastructure, all
requirements are independent of whether IPv4 or IPv6 is
used. All tests shall be done both over IPv4 and IPv6, with
reports providing results according to both protocols.
UDP Support -- The DNS infrastructure to which these tests
apply comprises the complete set of servers and network
infrastructure to be used by the chosen providers to deliver
DNS service for the new gTLD to the Internet. The
documentation provided by the applicant must include
the results from a system performance test indicating
available network and server capacity and an estimate of
expected capacity during normal operation to ensure
stable service as well as to adequately address Distributed
Denial of Service (DDoS) attacks.
Self-certification documentation shall include data on load
capacity, latency and network reachability.
Load capacity shall be reported using a table, and a
corresponding graph, showing percentage of queries
responded against an increasing number of queries per
second generated from local (to the servers) traffic
generators. The table shall include at least 20 data points
and loads of UDP-based queries that will cause up to 10%
query loss against a randomly selected subset of servers
within the applicant’s DNS infrastructure. Responses must
either contain zone data or be NXDOMAIN or NODATA
responses to be considered valid.
Query latency shall be reported in milliseconds as
measured by DNS probes located just outside the border
routers of the physical network hosting the name servers,
from a network topology point of view.
Reachability will be documented by providing information
on the transit and peering arrangements for the DNS server
locations, listing the AS numbers of the transit providers or
peers at each point of presence and available bandwidth
at those points of presence.
TCP support -- TCP transport service for DNS queries and
responses must be enabled and provisioned for expected
load. ICANN will review the capacity self-certification
documentation provided by the applicant and will perform Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-6
TCP reachability and transaction capability tests across a
randomly selected subset of the name servers within the
applicant’s DNS infrastructure. In case of use of anycast,
each individual server in each anycast set will be tested.
Self-certification documentation shall include data on load
capacity, latency and external network reachability.
Load capacity shall be reported using a table, and a
corresponding graph, showing percentage of queries that
generated a valid (zone data, NODATA, or NXDOMAIN)
response against an increasing number of queries per
second generated from local (to the name servers) traffic
generators. The table shall include at least 20 data points
and loads that will cause up to 10% query loss (either due
to connection timeout or connection reset) against a
randomly selected subset of servers within the applicant’s
DNS infrastructure.
Query latency will be reported in milliseconds as measured
by DNS probes located just outside the border routers of
the physical network hosting the name servers, from a
network topology point of view.
Reachability will be documented by providing records of
TCP-based DNS queries from nodes external to the network
hosting the servers. These locations may be the same as
those used for measuring latency above.
DNSSEC support -- Applicant must demonstrate support for
EDNS(0) in its server infrastructure, the ability to return
correct DNSSEC-related resource records such as DNSKEY,
RRSIG, and NSEC/NSEC3 for the signed zone, and the
ability to accept and publish DS resource records from
second-level domain administrators. In particular, the
applicant must demonstrate its ability to support the full life
cycle of KSK and ZSK keys. ICANN will review the selfcertification materials as well as test the reachability,
response sizes, and DNS transaction capacity for DNS
queries using the EDNS(0) protocol extension with the
“DNSSEC OK” bit set for a randomly selected subset of all
name servers within the applicant’s DNS infrastructure. In
case of use of anycast, each individual server in each
anycast set will be tested.
Load capacity, query latency, and reachability shall be
documented as for UDP and TCP above.Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-7
5.2.3   Test Elements:  Registry Systems
As documented in the registry agreement, registries must
provide support for EPP within their Shared Registration
System, and provide Whois service both via port 43 and a
web interface, in addition to support for the DNS. This
section details the requirements for testing these registry
systems.
System performance -- The registry system must scale to
meet the performance requirements described in
Specification 10 of the registry agreement and ICANN will
require self-certification of compliance. ICANN will review
the self-certification documentation provided by the
applicant to verify adherence to these minimum
requirements.
Whois support -- Applicant must provision Whois services for
the anticipated load. ICANN will verify that Whois data is
accessible over IPv4 and IPv6 via both TCP port 43 and via
a web interface and review self-certification
documentation regarding Whois transaction capacity.
Response format according to Specification 4 of the
registry agreement and access to Whois (both port 43 and
via web) will be tested by ICANN remotely from various
points on the Internet over both IPv4 and IPv6.
Self-certification documents shall describe the maximum
number of queries per second successfully handled by
both the port 43 servers as well as the web interface,
together with an applicant-provided load expectation.
Additionally, a description of deployed control functions to
detect and mitigate data mining of the Whois database
shall be documented.
EPP Support -- As part of a shared registration service,
applicant must provision EPP services for the anticipated
load. ICANN will verify conformance to appropriate RFCs
(including EPP extensions for DNSSEC). ICANN will also
review self-certification documentation regarding EPP
transaction capacity.
Documentation shall provide a maximum Transaction per
Second rate for the EPP interface with 10 data points
corresponding to registry database sizes from 0 (empty) to Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-8
the expected size after one year of operation, as
determined by applicant.
Documentation shall also describe measures taken to
handle load during initial registry operations, such as a
land-rush period.
IPv6 support -- The ability of the registry to support registrars
adding, changing, and removing IPv6 DNS records
supplied by registrants will be tested by ICANN. If the
registry supports EPP access via IPv6, this will be tested by
ICANN remotely from various points on the Internet.
DNSSEC support -- ICANN will review the ability of the
registry to support registrars adding, changing, and
removing DNSSEC-related resource records as well as the
registry’s overall key management procedures. In
particular, the applicant must demonstrate its ability to
support the full life cycle of key changes for child domains.
Inter-operation of the applicant’s secure communication
channels with the IANA for trust anchor material exchange
will be verified.
The practice and policy document (also known as the
DNSSEC Policy Statement or DPS), describing key material
storage, access and usage for its own keys is also reviewed
as part of this step.
IDN support -- ICANN will verify the complete IDN table(s)
used in the registry system. The table(s) must comply with
the guidelines in http://iana.org/procedures/idnrepository.html.
Requirements related to IDN for Whois are being
developed. After these requirements are developed,
prospective registries will be expected to comply with
published IDN-related Whois requirements as part of predelegation testing.
Escrow deposit -- The applicant-provided samples of data
deposit that include both a full and an incremental deposit
showing correct type and formatting of content will be
reviewed. Special attention will be given to the agreement
with the escrow provider to ensure that escrowed data
can be released within 24 hours should it be necessary.
ICANN may, at its option, ask an independent third party to
demonstrate the reconstitutability of the registry from Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-9
escrowed data. ICANN may elect to test the data release
process with the escrow agent.
5.3 Delegation Process
Upon notice of successful completion of the ICANN predelegation testing, applicants may initiate the process for
delegation of the new gTLD into the root zone database.
This will include provision of additional information and
completion of additional technical steps required for
delegation. Information about the delegation process is
available at http://iana.org/domains/root/.
5.4 Ongoing Operations
An applicant that is successfully delegated a gTLD will
become a “Registry Operator.” In being delegated the
role of operating part of the Internet’s domain name
system, the applicant will be assuming a number of
significant responsibilities. ICANN will hold all new gTLD
operators accountable for the performance of their
obligations under the registry agreement, and it is
important that all applicants understand these
responsibilities.
5.4.1   What is Expected of a Registry Operator
The registry agreement defines the obligations of gTLD
registry operators. A breach of the registry operator’s
obligations may result in ICANN compliance actions up to
and including termination of the registry agreement.
Prospective applicants are encouraged to review the
following brief description of some of these responsibilities.
Note that this is a non-exhaustive list provided to potential
applicants as an introduction to the responsibilities of a
registry operator. For the complete and authoritative text,
please refer to the registry agreement.
A registry operator is obligated to:
Operate the TLD in a stable and secure manner. The registry
operator is responsible for the entire technical operation of
the TLD. As noted in RFC 15911
:
                                                         
1
See http://www.rfc-editor.org/rfc/rfc1591.txtModule 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-10
“The designated manager must do a satisfactory job of
operating the DNS service for the domain. That is, the
actual management of the assigning of domain names,
delegating subdomains and operating nameservers must
be done with technical competence. This includes keeping
the central IR2
(in the case of top-level domains) or other
higher-level domain manager advised of the status of the
domain, responding to requests in a timely manner, and
operating the database with accuracy, robustness, and
resilience.”
The registry operator is required to comply with relevant
technical standards in the form of RFCs and other
guidelines. Additionally, the registry operator must meet
performance specifications in areas such as system
downtime and system response times (see Specifications 6
and 10 of the registry agreement).
Comply with consensus policies and temporary policies.
gTLD registry operators are required to comply with
consensus policies. Consensus policies may relate to a
range of topics such as issues affecting interoperability of
the DNS, registry functional and performance
specifications, database security and stability, or resolution
of disputes over registration of domain names.
To be adopted as a consensus policy, a policy must be
developed by the Generic Names Supporting Organization
(GNSO)3
following the process in Annex A of the ICANN
Bylaws.4
  The policy development process involves
deliberation and collaboration by the various stakeholder
groups participating in the process, with multiple
opportunities for input and comment by the public, and
can take significant time.
Examples of existing consensus policies are the InterRegistrar Transfer Policy (governing transfers of domain
names between registrars), and the Registry Services
Evaluation Policy (establishing a review of proposed new
registry services for security and stability or competition
concerns), although there are several more, as found at
http://www.icann.org/en/general/consensus-policies.htm.
                                                         
2
IR is a historical reference to “Internet Registry,” a function now performed by ICANN.
3
http://gnso.icann.org
4
http://www.icann.org/en/general/bylaws.htm#AnnexAModule 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-11
gTLD registry operators are obligated to comply with both
existing consensus policies and those that are developed in
the future. Once a consensus policy has been formally
adopted, ICANN will provide gTLD registry operators with
notice of the requirement to implement the new policy
and the effective date.
In addition, the ICANN Board may, when required by
circumstances, establish a temporary policy necessary to
maintain the stability or security of registry services or the
DNS. In such a case, all gTLD registry operators will be
required to comply with the temporary policy for the
designated period of time.
For more information, see Specification 1 of the registry
agreement.
Implement start-up rights protection measures. The registry
operator must implement, at a minimum, a Sunrise period
and a Trademark Claims service during the start-up phases
for registration in the TLD, as provided in the registry
agreement. These mechanisms will be supported by the
established Trademark Clearinghouse as indicated by
ICANN.
The Sunrise period allows eligible rightsholders an early
opportunity to register names in the TLD.
The Trademark Claims service provides notice to potential
registrants of existing trademark rights, as well as notice to
rightsholders of relevant names registered. Registry
operators may continue offering the Trademark Claims
service after the relevant start-up phases have concluded.
For more information, see Specification 7 of the registry
agreement and the Trademark Clearinghouse model
accompanying this module.
Implement post-launch rights protection measures. The
registry operator is required to implement decisions made
under the Uniform Rapid Suspension (URS) procedure,
including suspension of specific domain names within the
registry. The registry operator is also required to comply with
and implement decisions made according to the
Trademark Post-Delegation Dispute Resolution Policy
(PDDRP).
The required measures are described fully in the URS and
PDDRP procedures accompanying this module. Registry Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-12
operators may introduce additional rights protection
measures relevant to the particular gTLD.
Implement measures for protection of country and territory
names in the new gTLD. All new gTLD registry operators are
required to provide certain minimum protections for
country and territory names, including an initial reservation
requirement and establishment of applicable rules and
procedures for release of these names. The rules for release
can be developed or agreed to by governments, the
GAC, and/or approved by ICANN after a community
discussion. Registry operators are encouraged to
implement measures for protection of geographical names
in addition to those required by the agreement, according
to the needs and interests of each gTLD’s particular
circumstances. (See Specification 5 of the registry
agreement).
Pay recurring fees to ICANN. In addition to supporting
expenditures made to accomplish the objectives set out in
ICANN’s mission statement, these funds enable the support
required for new gTLDs, including:  contractual
compliance, registry liaison, increased registrar
accreditations, and other registry support activities. The
fees include both a fixed component (USD 25,000 annually)
and, where the TLD exceeds a transaction volume, a
variable fee based on transaction volume. See Article 6 of
the registry agreement.
Regularly deposit data into escrow. This serves an important
role in registrant protection and continuity for certain
instances where the registry or one aspect of the registry
operations experiences a system failure or loss of data.
(See Specification 2 of the registry agreement.)
Deliver monthly reports in a timely manner. A registry
operator must submit a report to ICANN on a monthly basis.
The report includes registrar transactions for the month and
is used by ICANN for calculation of registrar fees. (See
Specification 3 of the registry agreement.)
Provide Whois service. A registry operator must provide a
publicly available Whois service for registered domain
names in the TLD. (See Specification 4 of the registry
agreement.)
Maintain partnerships with ICANN-accredited registrars. A
registry operator creates a Registry-Registrar Agreement Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-13
(RRA) to define requirements for its registrars. This must
include certain terms that are specified in the Registry
Agreement, and may include additional terms specific to
the TLD. A registry operator must provide non-discriminatory
access to its registry services to all ICANN-accredited
registrars with whom it has entered into an RRA, and who
are in compliance with the requirements. This includes
providing advance notice of pricing changes to all
registrars, in compliance with the time frames specified in
the agreement. (See Article 2 of the registry agreement.)
Maintain an abuse point of contact. A registry operator
must maintain and publish on its website a single point of
contact responsible for addressing matters requiring
expedited attention and providing a timely response to
abuse complaints concerning all names registered in the
TLD through all registrars of record, including those involving
a reseller. A registry operator must also take reasonable
steps to investigate and respond to any reports from law
enforcement, governmental and quasi-governmental
agencies of illegal conduct in connection with the use of
the TLD. (See Article 2 and Specification 6 of the registry
agreement.)
Cooperate with contractual compliance audits. To
maintain a level playing field and a consistent operating
environment, ICANN staff performs periodic audits to assess
contractual compliance and address any resulting
problems. A registry operator must provide documents and
information requested by ICANN that are necessary to
perform such audits. (See Article 2 of the registry
agreement.)
Maintain a Continued Operations Instrument. A registry
operator must, at the time of the agreement, have in
place a continued operations instrument sufficient to fund
basic registry operations for a period of three (3) years. This
requirement remains in place for five (5) years after
delegation of the TLD, after which time the registry
operator is no longer required to maintain the continued
operations instrument. (See Specification 8 to the registry
agreement.)
Maintain community-based policies and procedures. If the
registry operator designated its application as communitybased at the time of the application, the registry operator
has requirements in its registry agreement to maintain the
community-based policies and procedures it specified in its Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-14
application. The registry operator is bound by the Registry
Restrictions Dispute Resolution Procedure with respect to
disputes regarding execution of its community-based
policies and procedures. (See Article 2 to the registry
agreement.)
Have continuity and transition plans in place. This includes
performing failover testing on a regular basis. In the event
that a transition to a new registry operator becomes
necessary, the registry operator is expected to cooperate
by consulting with ICANN on the appropriate successor,
providing the data required to enable a smooth transition,
and complying with the applicable registry transition
procedures. (See Articles 2 and 4 of the registry
agreement.)
Make TLD zone files available via a standardized process.
This includes provision of access to the registry’s zone file to
credentialed users, according to established access, file,
and format standards. The registry operator will enter into a
standardized form of agreement with zone file users and
will accept credential information for users via a
clearinghouse. (See Specification 4 of the registry
agreement.)
Implement DNSSEC.  The registry operator is required to sign
the TLD zone files implementing Domain Name System
Security Extensions (DNSSEC) in accordance with the
relevant technical standards. The registry must accept
public key material from registrars for domain names
registered in the TLD, and publish a DNSSEC Policy
Statement describing key material storage, access, and
usage for the registry’s keys. (See Specification 6 of the
registry agreement.)
5.4.2   What is Expected of ICANN
ICANN will continue to provide support for gTLD registry
operators as they launch and maintain registry operations.
ICANN’s gTLD registry liaison function provides a point of
contact for gTLD registry operators for assistance on a
continuing basis.
ICANN’s contractual compliance function will perform
audits on a regular basis to ensure that gTLD registry
operators remain in compliance with agreement
obligations, as well as investigate any complaints from the
community regarding the registry operator’s adherence to
its contractual obligations. See Module 5
Transition to Delegation
Applicant Guidebook | version 2011-09-19
5-15
http://www.icann.org/en/compliance/ for more
information on current contractual compliance activities.
ICANN’s Bylaws require ICANN to act in an open and
transparent manner, and to provide equitable treatment
among registry operators. ICANN is responsible for
maintaining the security and stability of the global Internet,
and looks forward to a constructive and cooperative
relationship with future gTLD registry operators in
furtherance of this goal.  No
Includes:
- Material changes in
circumstances
- Continued
Operations
instrument
- Designated
contracting parties
Board reviews
changes to base
agreement
End
Applicant
remedies issues
Pre-Delegation Testing – 1 to 12 months
Applicant requests
initiation of the
IANA delegation
process through
TAS
Meet process level
authorization?
ICANN and
applicant execute
registry agreement
Applicant and
ICANN
negotiate and
agree on
contract
Applicant Doc Prep 1 Month
ICANN
perform predelegation
process
Pass?
Applicant requests
initiation of predelegation process
through TAS
Contracting – 1 day to 9 months
Approve?
Applicant
prepares
documentation
for contracting
Yes
No – Material change
to contract requested
ICANN provides notice
of eligibility to applicant
Yes
O No
ther, trigger
for Board review
Board reviews
application
Yes
Draft – New gTLD Program - Transition to Delegation
(Timeframes are estimates only)DRAFT NEW GTLD REGISTRY AGREEMENT
 
New gTLD Agreement
This document contains the registry agreement associated with the Applicant
Guidebook for New gTLDs.
Successful gTLD applicants would enter into this form of registry agreement with ICANN
prior to delegation of the new gTLD.  (Note: ICANN reserves the right to make reasonable
updates and changes to this proposed agreement during the course of the application
process, including as the possible result of new policies that might be adopted during the
course of the application process).  DRAFT NEW GTLD REGISTRY AGREEMENT
 
REGISTRY AGREEMENT
This REGISTRY AGREEMENT (this “Agreement”) is entered into as of ___________ (the
“Effective Date”) between Internet Corporation for Assigned Names and Numbers, a California nonprofit
public benefit corporation (“ICANN”), and __________, a _____________ (“Registry Operator”).
ARTICLE 1.
DELEGATION AND OPERATION
OF TOP–LEVEL DOMAIN; REPRESENTATIONS AND WARRANTIES
1.1 Domain and Designation.  The Top-Level Domain to which this Agreement applies is
____ (the “TLD”).  Upon the Effective Date and until the end of the Term (as defined in Section 4.1),
ICANN designates Registry Operator as the registry operator for the TLD, subject to the requirements and
necessary approvals for delegation of the TLD and entry into the root-zone.    
1.2 Technical Feasibility of String.  While ICANN has encouraged and will continue to
encourage universal acceptance of all top-level domain strings across the Internet, certain top-level
domain strings may encounter difficulty in acceptance by ISPs and webhosters and/or validation by web
applications.  Registry Operator shall be responsible for ensuring to its satisfaction the technical
feasibility of the TLD string prior to entering into this Agreement.
1.3 Representations and Warranties.
(a) Registry Operator represents and warrants to ICANN as follows:
(i) all material information provided and statements made in the registry
TLD application, and statements made in writing during the negotiation of this
Agreement, were true and correct in all material respects at the time made, and such
information or statements continue to be true and correct in all material respects as of the
Effective Date except as otherwise previously disclosed in writing by Registry Operator
to ICANN;
(ii) Registry Operator is duly organized, validly existing and in good
standing under the laws of the jurisdiction set forth in the preamble hereto, and Registry
Operator has all requisite power and authority and obtained all necessary approvals to
enter into and duly execute and deliver this Agreement; and
(iii) Registry Operator has delivered to ICANN a duly executed instrument
that secures the funds required to perform registry functions for the TLD in the event of
the termination or expiration of this Agreement (the “Continued Operations Instrument”),
and such instrument is a binding obligation of the parties thereto, enforceable against the
parties thereto in accordance with its terms.
(b) ICANN represents and warrants to Registry Operator that ICANN is a nonprofit
public benefit corporation duly organized, validly existing and in good standing under the laws of the
State of California, United States of America.  ICANN has all requisite power and authority and obtained
all necessary corporate approvals to enter into and duly execute and deliver this Agreement. DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
ARTICLE 2.
COVENANTS OF REGISTRY OPERATOR
Registry Operator covenants and agrees with ICANN as follows:
2.1 Approved Services; Additional Services.  Registry Operator shall be entitled to provide
the Registry Services described in clauses (a) and (b) of the first paragraph of Section 2.1 in the
specification at [see specification 6] (“Specification 6”) and such other Registry Services set forth on
Exhibit A (collectively, the “Approved Services”).  If Registry Operator desires to provide any Registry
Service that is not an Approved Service or is a modification to an Approved Service (each, an “Additional
Service”), Registry Operator shall submit a request for approval of such Additional Service pursuant to
the Registry Services Evaluation Policy at http://www.icann.org/en/registries/rsep/rsep.html, as such
policy may be amended from time to time in accordance with the bylaws of ICANN (as amended from
time to time, the “ICANN Bylaws”) applicable to Consensus Policies (the “RSEP”).  Registry Operator
may offer Additional Services only with the written approval of ICANN, and, upon any such approval,
such Additional Services shall be deemed Registry Services under this Agreement.  In its reasonable
discretion, ICANN may require an amendment to this Agreement reflecting the provision of any
Additional Service which is approved pursuant to the RSEP, which amendment shall be in a form
reasonably acceptable to the parties.
2.2 Compliance with Consensus Policies and Temporary Policies.  Registry Operator
shall comply with and implement all Consensus Policies and Temporary Policies found at
<http://www.icann.org/general/consensus-policies.htm>, as of the Effective Date and as may in the future
be developed and adopted in accordance with the ICANN Bylaws, provided such future Consensus
Polices and Temporary Policies are adopted in accordance with the procedure and relate to those topics
and subject to those limitations set forth at [see specification 1]* (“Specification 1”).
2.3 Data Escrow.  Registry Operator shall comply with the registry data escrow procedures
posted at [see specification 2]*.
2.4 Monthly Reporting.  Within twenty (20) calendar days following the end of each
calendar month, Registry Operator shall deliver to ICANN reports in the format posted in the
specification at [see specification 3]*.
2.5 Publication of Registration Data.  Registry Operator shall provide public access to
registration data in accordance with the specification posted at [see specification 4]* (“Specification 4”).
2.6 Reserved Names.  Except to the extent that ICANN otherwise expressly authorizes in
writing, Registry Operator shall comply with the restrictions on registration of character strings set forth
at [see specification 5]* (“Specification 5”).  Registry Operator may establish policies concerning the
reservation or blocking of additional character strings within the TLD at its discretion. If Registry
Operator is the registrant for any domain names in the Registry TLD (other than the Second-Level
Reservations for Registry Operations from Specification 5), such registrations must be through an
ICANN accredited registrar. Any such registrations will be considered Transactions (as defined in Section
6.1) for purposes of calculating the Registry-Level Transaction Fee to be paid to ICANN by Registry
Operator pursuant to Section 6.1.
2.7 Registry Interoperability and Continuity. Registry Operator shall comply with the
Registry Interoperability and Continuity Specifications as set forth in Specification 6. DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
2.8 Protection of Legal Rights of Third Parties.  Registry Operator must specify, and
comply with, a process and procedures for launch of the TLD and initial registration-related and ongoing
protection of the legal rights of third parties as set forth in the specification at [see specification 7]*
(“Specification 7”).  Registry Operator may, at its election, implement additional protections of the legal
rights of third parties.  Any changes or modifications to the process and procedures required by
Specification 7 following the Effective Date must be approved in advance by ICANN in writing.
Registry Operator must comply with all remedies imposed by ICANN pursuant to Section 2 of
Specification 7, subject to Registry Operator’s right to challenge such remedies as set forth in the
applicable procedure described therein.  Registry Operator shall take reasonable steps to investigate and
respond to any reports from law enforcement and governmental and quasi-governmental agencies of
illegal conduct in connection with the use of the TLD. In responding to such reports, Registry Operator
will not be required to take any action in contravention of applicable law.
2.9 Registrars.
(a) Registry Operator must use only ICANN accredited registrars in registering
domain names.  Registry Operator must provide non-discriminatory access to Registry Services to all
ICANN accredited registrars that enter into and are in compliance with the registry-registrar agreement
for the TLD; provided, that Registry Operator may establish non-discriminatory criteria for qualification
to register names in the TLD that are reasonably related to the proper functioning of the TLD.  Registry
Operator must use a uniform non-discriminatory agreement with all registrars authorized to register
names in the TLD.  Such agreement may be revised by Registry Operator from time to time; provided,
however, that any such revisions must be approved in advance by ICANN.  
(b) If Registry Operator (i) becomes an Affiliate or reseller of an ICANN accredited
registrar, or (ii) subcontracts the provision of any Registry Services to an ICANN accredited registrar,
registrar reseller or any of their respective Affiliates, then, in either such case of (i) or (ii) above, Registry
Operator will give ICANN prompt notice of the contract, transaction or other arrangement that resulted in
such affiliation, reseller relationship or subcontract, as applicable, including, if requested by ICANN,
copies of any contract relating thereto; provided, that ICANN will not disclose such contracts to any third
party other than relevant competition authorities. ICANN reserves the right, but not the obligation, to
refer any such contract, transaction or other arrangement to relevant competition authorities in the event
that ICANN determines that such contract, transaction or other arrangement might raise competition
issues.
(c) For the purposes of this Agreement:  (i) “Affiliate” means a person or entity that,
directly or indirectly, through one or more intermediaries, controls, is controlled by, or is under common
control with, the person or entity specified, and (ii) “control” (including the terms “controlled by” and
“under common control with”) means the possession, directly or indirectly, of the power to direct or cause
the direction of the management or policies of a person or entity, whether through the ownership of
securities, as trustee or executor, by serving as an employee or a member of a board of directors or
equivalent governing body, by contract, by credit arrangement or otherwise.
2.10 Pricing for Registry Services.  
(a) With respect to initial domain name registrations, Registry Operator shall provide
each ICANN accredited registrar that has executed the registry-registrar agreement for the TLD advance
written notice of any price increase (including as a result of the elimination of any refunds, rebates,
discounts, product tying or other programs which had the effect of reducing the price charged to
registrars, unless such refunds, rebates, discounts, product tying or other programs are of a limited DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
duration that is clearly and conspicuously disclosed to the registrar when offered) of no less than thirty
(30) calendar days.  Registry Operator shall offer registrars the option to obtain initial domain name
registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years.
(b) With respect to renewal of domain name registrations, Registry Operator shall
provide each ICANN accredited registrar that has executed the registry-registrar agreement for the TLD
advance written notice of any price increase (including as a result of the elimination of any refunds,
rebates, discounts, product tying, Qualified Marketing Programs or other programs which had the effect
of reducing the price charged to registrars) of no less than one hundred eighty (180) calendar days.
Notwithstanding the foregoing sentence, with respect to renewal of domain name registrations: (i)
Registry Operator need only provide thirty (30) calendar days notice of any price increase if the resulting
price is less than or equal to (A) for the period beginning on the Effective Date and ending twelve (12)
months following the Effective Date, the initial price charged for registrations in the TLD, or (B) for
subsequent periods, a price for which Registry Operator provided a notice pursuant to the first sentence of
this Section 2.10(b) within the twelve (12) month period preceding the effective date of the proposed
price increase; and (ii) Registry Operator need not provide notice of any price increase for the imposition
of the Variable Registry-Level Fee set forth in Section 6.3.  Registry Operator shall offer registrars the
option to obtain domain name registration renewals at the current price (i.e. the price in place prior to any
noticed increase) for periods of one to ten years at the discretion of the registrar, but no greater than ten
years.
(c)  In addition, Registry Operator must have uniform pricing for renewals of
domain name registrations (“Renewal Pricing”).  For the purposes of determining Renewal Pricing, the
price for each domain registration renewal must be identical to the price of all other domain name
registration renewals in place at the time of such renewal, and such price must take into account universal
application of any refunds, rebates, discounts, product tying or other programs in place at the time of
renewal. The foregoing requirements of this Section 2.10(c) shall not apply for (i) purposes of
determining Renewal Pricing if the registrar has provided Registry Operator with documentation that
demonstrates that the applicable registrant expressly agreed in its registration agreement with registrar to
higher Renewal Pricing at the time of the initial registration of the domain name following clear and
conspicuous disclosure of such Renewal Pricing to such registrant, and (ii) discounted Renewal Pricing
pursuant to a Qualified Marketing Program (as defined below).  The parties acknowledge that the purpose
of this Section 2.10(c) is to prohibit abusive and/or discriminatory Renewal Pricing practices imposed by
Registry Operator without the written consent of the applicable registrant at the time of the initial
registration of the domain and this Section 2.10(c) will be interpreted broadly to prohibit such practices.
For purposes of this Section 2.10(c), a “Qualified Marketing Program” is a marketing program pursuant
to which Registry Operator offers discounted Renewal Pricing, provided that each of the following
criteria is satisfied:  (i) the program and related discounts are offered for a period of time not to exceed
one hundred eighty (180) calendar days (with consecutive substantially similar programs aggregated for
purposes of determining the number of calendar days of the program), (ii) all ICANN accredited registrars
are provided the same opportunity to qualify for such discounted Renewal Pricing; and (iii) the intent or
effect of the program is not to exclude any particular class(es) of registrations (e.g., registrations held by
large corporations) or increase the renewal price of any particular class(es) of registrations.  Nothing in
this Section 2.10(c) shall limit Registry Operator’s obligations pursuant to Section 2.10(b).
(d) Registry Operator shall provide public query-based DNS lookup service for the
TLD (that is, operate the Registry TLD zone servers) at its sole expense.
2.11 Contractual and Operational Compliance Audits.   DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
(a) ICANN may from time to time (not to exceed twice per calendar year) conduct,
or engage a third party to conduct, contractual compliance audits to assess compliance by Registry
Operator with its representations and warranties contained in Article 1 of this Agreement and its
covenants contained in Article 2 of this Agreement.  Such audits shall be tailored to achieve the purpose
of assessing compliance, and ICANN will (a) give reasonable advance notice of any such audit, which
notice shall specify in reasonable detail the categories of documents, data and other information requested
by ICANN, and (b) use commercially reasonable efforts to conduct such audit in such a manner as to not
unreasonably disrupt the operations of Registry Operator.  As part of such audit and upon request by
ICANN, Registry Operator shall timely provide all responsive documents, data and any other information
necessary to demonstrate Registry Operator’s compliance with this Agreement.  Upon no less than five
(5) business days notice (unless otherwise agreed to by Registry Operator), ICANN may, as part of any
contractual compliance audit, conduct site visits during regular business hours to assess compliance by
Registry Operator with its representations and warranties contained in Article 1 of this Agreement and its
covenants contained in Article 2 of this Agreement.  
(b) Any audit conducted pursuant to Section 2.11(a) will be at ICANN’s expense,
unless (i) Registry Operator (A) controls, is controlled by, is under common control or is otherwise
Affiliated with, any ICANN accredited registrar or registrar reseller or any of their respective Affiliates,
or (B) has subcontracted the provision of Registry Services to an ICANN accredited registrar or registrar
reseller or any of their respective Affiliates, and, in either case of (A) or (B) above, the audit relates to
Registry Operator’s compliance with Section 2.14, in which case Registry Operator shall reimburse
ICANN for all reasonable costs and expenses associated with the portion of the audit related to Registry
Operator’s compliance with Section 2.14, or (ii) the audit is related to a discrepancy in the fees paid by
Registry Operator hereunder in excess of 5% to ICANN’s detriment, in which case Registry Operator
shall reimburse ICANN for all reasonable costs and expenses associated with the entirety of such audit.
In either such case of (i) or (ii) above, such reimbursement will be paid together with the next RegistryLevel Fee payment due following the date of transmittal of the cost statement for such audit.  
(c) Notwithstanding Section 2.11(a), if Registry Operator is found not to be in
compliance with its representations and warranties contained in Article 1 of this Agreement or its
covenants contained in Article 2 of this Agreement in two consecutive audits conducted pursuant to this
Section 2.11, ICANN may increase the number of such audits to one per calendar quarter.  
(d) Registry Operator will give ICANN immediate notice of the commencement of
any of the proceedings referenced in Section 4.3(d) or the occurrence of any of the matters specified in
Section 4.3(f).
2.12 Continued Operations Instrument.  Registry Operator shall comply with the terms and
conditions relating to the Continued Operations Instrument set forth in the specification at [see
specification 8].
2.13 Emergency Transition.  Registry Operator agrees that in the event that any of the
registry functions set forth in Section 6 of Specification 10 fails for a period longer than the emergency
threshold for such function set forth in Section 6 of Specification 10, ICANN may designate an
emergency interim registry operator of the registry for the TLD (an “Emergency Operator”) in accordance
with ICANN's registry transition process (available at ____________) (as the same may be amended from
time to time, the “Registry Transition Process”) until such time as Registry Operator has demonstrated to
ICANN’s reasonable satisfaction that it can resume operation of the registry for the TLD without the
reoccurrence of such failure.  Following such demonstration, Registry Operator may transition back into
operation of the registry for the TLD pursuant to the procedures set out in the Registry Transition Process, DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
provided that Registry Operator pays all reasonable costs incurred (i) by ICANN as a result of the
designation of the Emergency Operator and (ii) by the Emergency Operator in connection with the
operation of the registry for the TLD, which costs shall be documented in reasonable detail in records that
shall be made available to Registry Operator.  In the event ICANN designates an Emergency Operator
pursuant to this Section 2.13 and the Registry Transition Process, Registry Operator shall provide ICANN
or any such Emergency Operator with all data (including the data escrowed in accordance with Section
2.3) regarding operations of the registry for the TLD necessary to maintain operations and registry
functions that may be reasonably requested by ICANN or such Emergency Operator.  Registry Operator
agrees that ICANN may make any changes it deems necessary to the IANA database for DNS and
WHOIS records with respect to the TLD in the event that an Emergency Operator is designated pursuant
to this Section 2.13.  In addition, in the event of such failure, ICANN shall retain and may enforce its
rights under the Continued Operations Instrument and Alternative Instrument, as applicable.
2.14 Registry Code of Conduct.  In connection with the operation of the registry for the
TLD, Registry Operator shall comply with the Registry Code of Conduct as set forth in the specification
at [see specification 9].
2.15 Cooperation with Economic Studies.  If ICANN initiates or commissions an economic
study on the impact or functioning of new generic top-level domains on the Internet, the DNS or related
matters, Registry Operator shall reasonably cooperate with such study, including by delivering to ICANN
or its designee conducting such study all data reasonably necessary for the purposes of such study
requested by ICANN or its designee, provided, that Registry Operator may withhold any internal analyses
or evaluations prepared by Registry Operator with respect to such data.  Any data delivered to ICANN or
its designee pursuant to this Section 2.15 shall be fully aggregated and anonymized by ICANN or its
designee prior to any disclosure of such data to any third party.
2.16 Registry Performance Specifications.  Registry Performance Specifications for
operation of the TLD will be as set forth in the specification at [see specification 10]*.  Registry Operator
shall comply with such Performance Specifications and, for a period of at least one year, shall keep
technical and operational records sufficient to evidence compliance with such specifications for each
calendar year during the Term.
2.17 Personal Data.  Registry Operator shall (i) notify each ICANN-accredited registrar that
is a party to the registry-registrar agreement for the TLD of the purposes for which data about any
identified or identifiable natural person (“Personal Data”) submitted to Registry Operator by such
registrar is collected and used under this Agreement or otherwise and the intended recipients (or
categories of recipients) of such Personal Data, and (ii) require such registrar to obtain the consent of each
registrant in the TLD for such collection and use of Personal Data. Registry Operator shall take
reasonable steps to protect Personal Data collected from such registrar from loss, misuse, unauthorized
disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data
in a way that is incompatible with the notice provided to registrars.  
2.18 [Note:  For Community-Based TLDs Only] Obligations of Registry Operator to TLD
Community.  Registry Operator shall establish registration policies in conformity with the application
submitted with respect to the TLD for:  (i) naming conventions within the TLD, (ii) requirements for
registration by members of the TLD community, and (iii) use of registered domain names in conformity
with the stated purpose of the community-based TLD.  Registry Operator shall operate the TLD in a
manner that allows the TLD community to discuss and participate in the development and modification of
policies and practices for the TLD.  Registry Operator shall establish procedures for the enforcement of
registration policies for the TLD, and resolution of disputes concerning compliance with TLD registration DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
policies, and shall enforce such registration policies.  Registry Operator agrees to implement and be
bound by the Registry Restrictions Dispute Resolution Procedure as set forth at [insert applicable URL]
with respect to disputes arising pursuant to this Section 2.18.]
ARTICLE 3.
COVENANTS OF ICANN
ICANN covenants and agrees with Registry Operator as follows:
3.1 Open and Transparent.  Consistent with ICANN’s expressed mission and core values,
ICANN shall operate in an open and transparent manner.
3.2 Equitable Treatment.  ICANN shall not apply standards, policies, procedures or
practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate
treatment unless justified by substantial and reasonable cause.
3.3 TLD Nameservers.  ICANN will use commercially reasonable efforts to ensure that any
changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and
with required technical elements specified by ICANN at http://www.iana.org/domains/root/ will be
implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical
verifications.
3.4 Root-zone Information Publication.  ICANN’s publication of root-zone contact
information for the TLD will include Registry Operator and its administrative and technical contacts.
Any request to modify the contact information for the Registry Operator must be made in the format
specified from time to time by ICANN at http://www.iana.org/domains/root/.
3.5 Authoritative Root Database.  To the extent that ICANN is authorized to set policy
with regard to an authoritative root server system, ICANN shall use commercially reasonable efforts to
(a) ensure that the authoritative root will point to the top-level domain nameservers designated by
Registry Operator for the TLD, (b) maintain a stable, secure, and authoritative publicly available database
of relevant information about the TLD, in accordance with ICANN publicly available policies and
procedures, and (c) coordinate the Authoritative Root Server System so that it is operated and maintained
in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and
ICANN shall have no liability in the event that any third party (including any governmental entity or
internet service provider) blocks or restricts access to the TLD in any jurisdiction.
ARTICLE 4.
TERM AND TERMINATION
4.1 Term.  The term of this Agreement will be ten years from the Effective Date (as such
term may be extended pursuant to Section 4.2, the “Term”).
4.2 Renewal.  
(a) This Agreement will be renewed for successive periods of ten years upon the
expiration of the initial Term set forth in Section 4.1 and each successive Term, unless: DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
(i) Following notice by ICANN to Registry Operator of a fundamental and
material breach of Registry Operator’s covenants set forth in Article 2 or breach of its
payment obligations under Article 6 of this Agreement, which notice shall include with
specificity the details of the alleged breach, and such breach has not been cured within
thirty (30) calendar days of such notice, (A) an arbitrator or court has finally determined
that Registry Operator has been in fundamental and material breach of such covenant(s)
or in breach of its payment obligations, and (B) Registry Operator has failed to comply
with such determination and cure such breach within ten (10) calendar days or such other
time period as may be determined by the arbitrator or court; or
(ii) During the then current Term, Registry Operator shall have been found
by an arbitrator (pursuant to Section 5.2 of this Agreement) on at least three (3) separate
occasions to have been in fundamental and material breach (whether or not cured) of
Registry Operator’s covenants set forth in Article 2 or breach of its payment obligations
under Article 6 of this Agreement.
(b) Upon the occurrence of the events set forth in Section 4.2(a) (i) or (ii), the
Agreement shall terminate at the expiration of the then current Term.
4.3 Termination by ICANN.
(a) ICANN may, upon notice to Registry Operator, terminate this Agreement if:  (i)
Registry Operator fails to cure (A) any fundamental and material breach of Registry Operator’s
representations and warranties set forth in Article 1 or covenants set forth in Article 2, or (B) any breach
of Registry Operator’s payment obligations set forth in Article 6 of this Agreement, each within thirty
(30) calendar days after ICANN gives Registry Operator notice of such breach, which notice will include
with specificity the details of the alleged breach, (ii) an arbitrator or court has finally determined that
Registry Operator is in fundamental and material breach of such covenant(s) or in breach of its payment
obligations, and (iii) Registry Operator fails to comply with such determination and cure such breach
within ten (10) calendar days or such other time period as may be determined by the arbitrator or court.
(b) ICANN may, upon notice to Registry Operator, terminate this Agreement if
Registry Operator fails to complete all testing and procedures (identified by ICANN in writing to Registry
Operator prior to the date hereof) for delegation of the TLD into the root zone within twelve (12) months
of the Effective Date.  Registry Operator may request an extension for up to additional twelve (12)
months for delegation if it can demonstrate, to ICANN’s reasonable satisfaction, that Registry Operator is
working diligently and in good faith toward successfully completing the steps necessary for delegation of
the TLD.  Any fees paid by Registry Operator to ICANN prior to such termination date shall be retained
by ICANN in full.
(c) ICANN may, upon notice to Registry Operator, terminate this Agreement if (i)
Registry Operator fails to cure a material breach of Registry Operator’s obligations set forth in Section
2.12 of this Agreement within thirty (30) calendar days of delivery of notice of such breach by ICANN, or
if the Continued Operations Instrument is not in effect for greater than sixty (60) consecutive calendar
days at any time following the Effective Date, (ii) an arbitrator or court has finally determined that
Registry Operator is in material breach of such covenant, and (iii) Registry Operator fails to cure such
breach within ten (10) calendar days or such other time period as may be determined by the arbitrator or
court. DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
(d) ICANN may, upon notice to Registry Operator, terminate this Agreement if (i)
Registry Operator makes an assignment for the benefit of creditors or similar act, (ii) attachment,
garnishment or similar proceedings are commenced against Registry Operator, which proceedings are a
material threat to Registry Operator’s ability to operate the registry for the TLD, and are not dismissed
within sixty (60) days of their commencement, (iii) a trustee, receiver, liquidator or equivalent is
appointed in place of Registry Operator or maintains control over any of Registry Operator’s property,
(iv) execution is levied upon any property of Registry Operator, (v) proceedings are instituted by or
against Registry Operator under any bankruptcy, insolvency, reorganization or other laws relating to the
relief of debtors and such proceedings are not dismissed within thirty (30) days of their commencement,
or (vi) Registry Operator files for protection under the United States Bankruptcy Code, 11 U.S.C. Section
101 et seq., or a foreign equivalent or liquidates, dissolves or otherwise discontinues its operations or the
operation of the TLD.
(e) ICANN may, upon thirty (30) calendar days’ notice to Registry Operator,
terminate this Agreement pursuant to Section 2 of Specification 7, subject to Registry Operator’s right to
challenge such termination as set forth in the applicable procedure described therein.
(f) ICANN may, upon notice to Registry Operator, terminate this Agreement if (i)
Registry Operator knowingly employs any officer that is convicted of a misdemeanor related to financial
activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or
breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the
substantive equivalent of any of the foregoing and such officer is not terminated within thirty (30)
calendar days of Registry Operator’s knowledge of the foregoing, or (ii) any member of Registry
Operator’s board of directors or similar governing body is convicted of a misdemeanor related to financial
activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or
breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the
substantive equivalent of any of the foregoing and such member is not removed from Registry Operator’s
board of directors or similar governing body within thirty (30) calendar days of Registry Operator’s
knowledge of the foregoing.
(g) [Applicable to intergovernmental organizations or governmental entities only.]
ICANN may terminate this Agreement pursuant to Section 7.14.
4.4 Termination by Registry Operator.
(a) Registry Operator may terminate this Agreement upon notice to ICANN if, (i)
ICANN fails to cure any fundamental and material breach of ICANN’s covenants set forth in Article 3,
within thirty (30) calendar days after Registry Operator gives ICANN notice of such breach, which notice
will include with specificity the details of the alleged breach, (ii) an arbitrator or court has finally
determined that ICANN is in fundamental and material breach of such covenants, and (iii) ICANN fails to
comply with such determination and cure such breach within ten (10) calendar days or such other time
period as may be determined by the arbitrator or court.
(b) Registry Operator may terminate this Agreement for any reason upon one
hundred eighty (180) calendar day advance notice to ICANN.
4.5 Transition of Registry upon Termination of Agreement.  Upon expiration of the Term
pursuant to Section 4.1 or Section 4.2 or any termination of this Agreement pursuant to Section 4.3 or
Section 4.4, Registry Operator shall provide ICANN or any successor registry operator that may be
designated by ICANN for the TLD in accordance with this Section 4.5 with all data (including the data DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
escrowed in accordance with Section 2.3) regarding operations of the registry for the TLD necessary to
maintain operations and registry functions that may be reasonably requested by ICANN or such successor
registry operator.  After consultation with Registry Operator, ICANN shall determine whether or not to
transition operation of the TLD to a successor registry operator in its sole discretion and in conformance
with the Registry Transition Process; provided, however, that if Registry Operator demonstrates to
ICANN’s reasonable satisfaction that (i) all domain name registrations in the TLD are registered to, and
maintained by, Registry Operator for its own exclusive use, (ii) Registry Operator does not sell, distribute
or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of
Registry Operator, and (iii) transitioning operation of the TLD is not necessary to protect the public
interest, then ICANN may not transition operation of the TLD to a successor registry operator upon the
expiration or termination of this Agreement without the consent of Registry Operator (which shall not be
unreasonably withheld, conditioned or delayed).  For the avoidance of doubt, the foregoing sentence shall
not prohibit ICANN from delegating the TLD pursuant to a future application process for the delegation
of top-level domains, subject to any processes and objection procedures instituted by ICANN in
connection with such application process intended to protect the rights of third parties.  Registry Operator
agrees that ICANN may make any changes it deems necessary to the IANA database for DNS and
WHOIS records with respect to the TLD in the event of a transition of the TLD pursuant to this Section
4.5.  In addition, ICANN or its designee shall retain and may enforce its rights under the Continued
Operations Instrument and Alternative Instrument, as applicable, regardless of the reason for termination
or expiration of this Agreement.
[Alternative Section 4.5 Transition of Registry upon Termination of Agreement text for
intergovernmental organizations or governmental entities or other special circumstances:
“Transition of Registry upon Termination of Agreement.  Upon expiration of the Term
pursuant to Section 4.1 or Section 4.2 or any termination of this Agreement pursuant to Section 4.3 or
Section 4.4, in connection with ICANN’s designation of a successor registry operator for the TLD,
Registry Operator and ICANN agree to consult each other and work cooperatively to facilitate and
implement the transition of the TLD in accordance with this Section 4.5.  After consultation with Registry
Operator, ICANN shall determine whether or not to transition operation of the TLD to a successor
registry operator in its sole discretion and in conformance with the Registry Transition Process.  In the
event ICANN determines to transition operation of the TLD to a successor registry operator, upon
Registry Operator’s consent (which shall not be unreasonably withheld, conditioned or delayed), Registry
Operator shall provide ICANN or such successor registry operator for the TLD with any data regarding
operations of the TLD necessary to maintain operations and registry functions that may be reasonably
requested by ICANN or such successor registry operator in addition to data escrowed in accordance with
Section 2.3 hereof.  In the event that Registry Operator does not consent to provide such data, any registry
data related to the TLD shall be returned to Registry Operator, unless otherwise agreed upon by the
parties. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA
database for DNS and WHOIS records with respect to the TLD in the event of a transition of the TLD
pursuant to this Section 4.5.  In addition, ICANN or its designee shall retain and may enforce its rights
under the Continued Operations Instrument and Alternative Instrument, as applicable, regardless of the
reason for termination or expiration of this Agreement.”]
4.6 Effect of Termination.  Upon any expiration of the Term or termination of this
Agreement, the obligations and rights of the parties hereto shall cease, provided that such expiration or
termination of this Agreement shall not relieve the parties of any obligation or breach of this Agreement
accruing prior to such expiration or termination, including, without limitation, all accrued payment
obligations arising under Article 6.  In addition, Article 5,  Article 7, Section 2.12, Section 4.5, and this DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
Section 4.6 shall survive the expiration or termination of this Agreement.  For the avoidance of doubt, the
rights of Registry Operator to operate the registry for the TLD shall immediately cease upon any
expiration of the Term or termination of this Agreement.
ARTICLE 5.
DISPUTE RESOLUTION
5.1 Cooperative Engagement.  Before either party may initiate arbitration pursuant to
Section 5.2 below, ICANN and Registry Operator, following initiation of communications by either party,
must attempt to resolve the dispute by engaging in good faith discussion over a period of at least fifteen
(15) calendar days.
5.2 Arbitration.  Disputes arising under or in connection with this Agreement, including
requests for specific performance, will be resolved through binding arbitration conducted pursuant to the
rules of the International Court of Arbitration of the International Chamber of Commerce.  The arbitration
will be conducted in the English language and will occur in Los Angeles County, California.  Any
arbitration will be in front of a single arbitrator, unless (i) ICANN is seeking punitive or exemplary
damages, or operational sanctions, or (ii) the parties agree in writing to a greater number of arbitrators.  In
either case of clauses (i) or (ii) in the preceding sentence, the arbitration will be in front of three
arbitrators with each party selecting one arbitrator and the two selected arbitrators selecting the third
arbitrator.  In order to expedite the arbitration and limit its cost, the arbitrator(s) shall establish page limits
for the parties’ filings in conjunction with the arbitration, and should the arbitrator(s) determine that a
hearing is necessary, the hearing shall be limited to one (1) calendar day, provided that in any arbitration
in which ICANN is seeking punitive or exemplary damages, or operational sanctions, the hearing may be
extended for one (1) additional calendar day if agreed upon by the parties or ordered by the arbitrator(s)
based on the arbitrator(s) independent determination or the reasonable request of one of the parties
thereto.  The prevailing party in the arbitration will have the right to recover its costs and reasonable
attorneys’ fees, which the arbitrator(s) shall include in the awards.  In the event the arbitrators determine
that Registry Operator has been repeatedly and willfully in fundamental and material breach of its
obligations set forth in Article 2, Article 6 or Section 5.4 of this Agreement, ICANN may request the
arbitrators award punitive or exemplary damages, or operational sanctions (including without limitation
an order temporarily restricting Registry Operator’s right to sell new registrations).  In any litigation
involving ICANN concerning this Agreement, jurisdiction and exclusive venue for such litigation will be
in a court located in Los Angeles County, California; however, the parties will also have the right to
enforce a judgment of such a court in any court of competent jurisdiction.
[Alternative Section 5.2 Arbitration text for intergovernmental organizations or governmental
entities or other special circumstances:
“Arbitration.  Disputes arising under or in connection with this Agreement, including requests
for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of
the International Court of Arbitration of the International Chamber of Commerce.  The arbitration will be
conducted in the English language and will occur in Geneva, Switzerland, unless another location is
mutually agreed upon by Registry Operator and ICANN.  Any arbitration will be in front of a single
arbitrator, unless (i) ICANN is seeking punitive or exemplary damages, or operational sanctions, or (ii)
the parties agree in writing to a greater number of arbitrators.  In either case of clauses (i) or (ii) in the
preceding sentence, the arbitration will be in front of three arbitrators with each party selecting one
arbitrator and the two selected arbitrators selecting the third arbitrator.  In order to expedite the arbitration
and limit its cost, the arbitrator(s) shall establish page limits for the parties’ filings in conjunction with the DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
arbitration, and should the arbitrator(s) determine that a hearing is necessary, the hearing shall be limited
to one (1) calendar day, provided that in any arbitration in which ICANN is seeking punitive or
exemplary damages, or operational sanctions, the hearing may be extended for one (1) additional calendar
day if agreed upon by the parties or ordered by the arbitrator(s) based on the arbitrator(s) independent
determination or the reasonable request of one of the parties thereto.  The prevailing party in the
arbitration will have the right to recover its costs and reasonable attorneys’ fees, which the arbitrator(s)
shall include in the awards.  In the event the arbitrators determine that Registry Operator has been
repeatedly and willfully in fundamental and material breach of its obligations set forth in Article 2,
Article 6 or Section 5.4 of this Agreement, ICANN may request the arbitrators award punitive or
exemplary damages, or operational sanctions (including without limitation an order temporarily
restricting Registry Operator’s right to sell new registrations). In any litigation involving ICANN
concerning this Agreement, jurisdiction and exclusive venue for such litigation will be in a court located
in Geneva, Switzerland, unless an another location is mutually agreed upon by Registry Operator and
ICANN; however, the parties will also have the right to enforce a judgment of such a court in any court of
competent jurisdiction.”]
5.3 Limitation of Liability.  ICANN’s aggregate monetary liability for violations of this
Agreement will not exceed an amount equal to the Registry-Level Fees paid by Registry Operator to
ICANN within the preceding twelve-month period pursuant to this Agreement (excluding the Variable
Registry-Level Fee set forth in Section 6.3, if any).  Registry Operator’s aggregate monetary liability to
ICANN for breaches of this Agreement will be limited to an amount equal to the fees paid to ICANN
during the preceding twelve-month period (excluding the Variable Registry-Level Fee set forth in Section
6.3, if any), and punitive and exemplary damages, if any, awarded in accordance with Section 5.2.  In no
event shall either party be liable for special, punitive, exemplary or consequential damages arising out of
or in connection with this Agreement or the performance or nonperformance of obligations undertaken in
this Agreement, except as provided in Section 5.2. Except as otherwise provided in this Agreement,
neither party makes any warranty, express or implied, with respect to the services rendered by itself, its
servants or agents, or the results obtained from their work, including, without limitation, any implied
warranty of merchantability, non-infringement or fitness for a particular purpose.
5.4 Specific Performance.  Registry Operator and ICANN agree that irreparable damage
could occur if any of the provisions of this Agreement was not performed in accordance with its specific
terms. Accordingly, the parties agree that they each shall be entitled to seek from the arbitrator specific
performance of the terms of this Agreement (in addition to any other remedy to which each party is
entitled).
ARTICLE 6.
FEES
6.1 Registry-Level Fees.  Registry Operator shall pay ICANN a Registry-Level Fee equal to
(i) the Registry Fixed Fee of US$6,250 per calendar quarter and (ii) the Registry-Level Transaction Fee.
The Registry-Level Transaction Fee will be equal to the number of annual increments of an initial or
renewal domain name registration (at one or more levels, and including renewals associated with transfers
from one ICANN-accredited registrar to another, each a “Transaction”), during the applicable calendar
quarter multiplied by US$0.25; provided, however that the Registry-Level Transaction Fee shall not apply
until and unless more than 50,000 Transactions have occurred  in the TLD during any calendar quarter or
any four calendar quarter period (the “Transaction Threshold”) and shall apply to each Transaction that
occurred during each quarter in which the Transaction Threshold has been met, but shall not apply to each
quarter in which the Transaction Threshold has not been met.  Registry Operator shall pay the Registry-DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
Level Fees on a quarterly basis by the 20th day following the end of each calendar quarter (i.e., on April
20, July 20, October 20 and January 20 for the calendar quarters ending March 31, June 30, September 30
and December 31) of the year to an account designated by ICANN.
6.2 Cost Recovery for RSTEP.  Requests by Registry Operator for the approval of
Additional Services pursuant to Section 2.1 may be referred by ICANN to the Registry Services
Technical Evaluation Panel ("RSTEP") pursuant to that process at
http://www.icann.org/en/registries/rsep/. In the event that such requests are referred to RSTEP, Registry
Operator shall remit to ICANN the invoiced cost of the RSTEP review within ten (10) business days of
receipt of a copy of the RSTEP invoice from ICANN, unless ICANN determines, in its sole and absolute
discretion, to pay all or any portion of the invoiced cost of such RSTEP review.
6.3 Variable Registry-Level Fee.
(a) If the ICANN accredited registrars (as a group) do not approve pursuant to the
terms of their registrar accreditation agreements with ICANN the variable accreditation fees established
by the ICANN Board of Directors for any ICANN fiscal year, upon delivery of notice from ICANN,
Registry Operator shall pay to ICANN a Variable Registry-Level Fee, which shall be paid on a fiscal
quarter basis, and shall accrue as of the beginning of the first fiscal quarter of such ICANN fiscal year.
The fee will be calculated and invoiced by ICANN on a quarterly basis, and shall be paid by Registry
Operator within sixty (60) calendar days with respect to the first quarter of such ICANN fiscal year and
within twenty (20) calendar days with respect to each remaining quarter of such ICANN fiscal year, of
receipt of the invoiced amount by ICANN.  The Registry Operator may invoice and collect the Variable
Registry-Level Fees from the registrars who are party to a registry-registrar agreement with Registry
Operator (which agreement may specifically provide for the reimbursement of Variable Registry-Level
Fees paid by Registry Operator pursuant to this Section 6.3); provided, that the fees shall be invoiced to
all ICANN accredited registrars if invoiced to any.  The Variable Registry-Level Fee, if collectible by
ICANN, shall be an obligation of Registry Operator and shall be due and payable as provided in this
Section 6.3 irrespective of Registry Operator’s ability to seek and obtain reimbursement of such fee from
registrars.  In the event ICANN later collects variable accreditation fees for which Registry Operator has
paid ICANN a Variable Registry-Level Fee, ICANN shall reimburse the Registry Operator an appropriate
amount of the Variable Registry-Level Fee, as reasonably determined by ICANN.  If the ICANN
accredited registrars (as a group) do approve pursuant to the terms of their registrar accreditation
agreements with ICANN the variable accreditation fees established by the ICANN Board of Directors for
a fiscal year, ICANN shall not be entitled to a Variable-Level Fee hereunder for such fiscal year,
irrespective of whether the ICANN accredited registrars comply with their payment obligations to
ICANN during such fiscal year.
(b) The amount of the Variable Registry-Level Fee will be specified for each
registrar, and may include both a per-registrar component and a transactional component. The perregistrar component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with
the budget adopted by the ICANN Board of Directors for each ICANN fiscal year.  The transactional
component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the
budget adopted by the ICANN Board of Directors for each ICANN fiscal year but shall not exceed
US$0.25 per domain name registration (including renewals associated with transfers from one ICANNaccredited registrar to another) per year.
6.4 Adjustments to Fees.  Notwithstanding any of the fee limitations set forth in this Article
6, commencing upon the expiration of the first year of this Agreement, and upon the expiration of each
year thereafter during the Term, the then current fees set forth in Section 6.1 and Section 6.3 may be DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
adjusted, at ICANN’s discretion, by a percentage equal to the percentage change, if any, in (i) the
Consumer Price Index for All Urban Consumers, U.S. City Average (1982-1984 = 100) published by the
United States Department of Labor, Bureau of Labor Statistics, or any successor index (the “CPI”) for the
month which is one (1) month prior to the commencement of the applicable year, over (ii) the CPI
published for the month which is one (1) month prior to the commencement of the immediately prior
year.  In the event of any such increase, ICANN shall provide notice to Registry Operator specifying the
amount of such adjustment.  Any fee adjustment under this Section 6.4 shall be effective as of the first
day of the year in which the above calculation is made.
6.5 Additional Fee on Late Payments.  For any payments thirty (30) calendar days or more
overdue under this Agreement, Registry Operator shall pay an additional fee on late payments at the rate
of 1.5% per month or, if less, the maximum rate permitted by applicable law.
ARTICLE 7.
MISCELLANEOUS
7.1 Indemnification of ICANN.
(a) Registry Operator shall indemnify and defend ICANN and its directors, officers,
employees, and agents (collectively, “Indemnitees”) from and against any and all third-party claims,
damages, liabilities, costs, and expenses, including reasonable legal fees and expenses, arising out of or
relating to intellectual property ownership rights with respect to the TLD, the delegation of the TLD to
Registry Operator, Registry Operator’s operation of the registry for the TLD or Registry Operator’s
provision of Registry Services, provided that Registry Operator shall not be obligated to indemnify or
defend any Indemnitee to the extent the claim, damage, liability, cost or expense arose: (i) due to the
actions or omissions of ICANN, its subcontractors, panelists or evaluators specifically related to and
occurring during the registry TLD application process (other than actions or omissions requested by or for
the benefit of Registry Operator), or (ii)  due to a breach by ICANN of any obligation contained in this
Agreement or any willful misconduct by ICANN.  This Section shall not be deemed to require Registry
Operator to reimburse or otherwise indemnify ICANN for costs associated with the negotiation or
execution of this Agreement, or with monitoring or management of the parties’ respective obligations
hereunder.  Further, this Section shall not apply to any request for attorney’s fees in connection with any
litigation or arbitration between or among the parties, which shall be governed by Article 5 or otherwise
awarded by a court or arbitrator.
[Alternative Section 7.1(a) text for intergovernmental organizations or governmental entities:
“Registry Operator shall use its best efforts to cooperate with ICANN in order to ensure that
ICANN does not incur any costs associated with claims, damages, liabilities, costs and expenses,
including reasonable legal fees and expenses, arising out of or relating to intellectual property ownership
rights with respect to the TLD, the delegation of the TLD to Registry Operator, Registry Operator’s
operation of the registry for the TLD or Registry Operator’s provision of Registry Services, provided that
Registry Operator shall not be obligated to provide such cooperation to the extent the claim, damage,
liability, cost or expense arose due to a breach by ICANN of any of its obligations contained in this
Agreement or any willful misconduct by ICANN.  This Section shall not be deemed to require Registry
Operator to reimburse or otherwise indemnify ICANN for costs associated with the negotiation or
execution of this Agreement, or with monitoring or management of the parties’ respective obligations
hereunder.  Further, this Section shall not apply to any request for attorney’s fees in connection with any DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
litigation or arbitration between or among the parties, which shall be governed by Article 5 or otherwise
awarded by a court or arbitrator.”]
(b) For any claims by ICANN for indemnification whereby multiple registry
operators (including Registry Operator) have engaged in the same actions or omissions that gave rise to
the claim, Registry Operator’s aggregate liability to indemnify ICANN with respect to such claim shall be
limited to a percentage of ICANN’s total claim, calculated by dividing the number of total domain names
under registration with Registry Operator within the TLD (which names under registration shall be
calculated consistently with Article 6 hereof for any applicable quarter) by the total number of domain
names under registration within all top level domains for which the registry operators thereof are
engaging in the same acts or omissions giving rise to such claim.  For the purposes of reducing Registry
Operator’s liability under Section 7.1(a) pursuant to this Section 7.1(b), Registry Operator shall have the
burden of identifying the other registry operators that are engaged in the same actions or omissions that
gave rise to the claim, and demonstrating, to ICANN’s reasonable satisfaction, such other registry
operators’ culpability for such actions or omissions.  For the avoidance of doubt, in the event that a
registry operator is engaged in the same acts or omissions giving rise to the claims, but such registry
operator(s) do not have the same or similar indemnification obligations to ICANN as set forth in Section
7.1(a) above, the number of domains under management by such registry operator(s) shall nonetheless be
included in the calculation in the preceding sentence. [Note: This Section 7.1(b) is inapplicable to
intergovernmental organizations or governmental entities.]
7.2 Indemnification Procedures.  If any third-party claim is commenced that is indemnified
under Section 7.1 above, ICANN shall provide notice thereof to Registry Operator as promptly as
practicable.  Registry Operator shall be entitled, if it so elects, in a notice promptly delivered to ICANN,
to immediately take control of the defense and investigation of such claim and to employ and engage
attorneys reasonably acceptable to ICANN to handle and defend the same, at Registry Operator’s sole
cost and expense, provided that in all events ICANN will be entitled to control at its sole cost and expense
the litigation of issues concerning the validity or interpretation of ICANN’s policies, Bylaws or conduct.
ICANN shall cooperate, at Registry Operator’s cost and expense, in all reasonable respects with Registry
Operator and its attorneys in the investigation, trial, and defense of such claim and any appeal arising
therefrom, and may, at its own cost and expense, participate, through its attorneys or otherwise, in such
investigation, trial and defense of such claim and any appeal arising therefrom.  No settlement of a claim
that involves a remedy affecting ICANN other than the payment of money in an amount that is fully
indemnified by Registry Operator will be entered into without the consent of ICANN.  If Registry
Operator does not assume full control over the defense of a claim subject to such defense in accordance
with this Section 7.2, ICANN will have the right to defend the claim in such manner as it may deem
appropriate, at the cost and expense of Registry Operator and Registry Operator shall cooperate in such
defense. [Note: This Section 7.2 is inapplicable to intergovernmental organizations or governmental
entities.]
7.3 Defined Terms.  For purposes of this Agreement, unless such definitions are amended
pursuant to a Consensus Policy at a future date, in which case the following definitions shall be deemed
amended and restated in their entirety as set forth in such Consensus Policy, Security and Stability shall
be defined as follows:
(a) For the purposes of this Agreement, an effect on “Security” shall mean (1) the
unauthorized disclosure, alteration, insertion or destruction of registry data, or (2) the unauthorized access
to or disclosure of information or resources on the Internet by systems operating in accordance with all
applicable standards.DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
(b) For purposes of this Agreement, an effect on “Stability” shall refer to (1) lack of
compliance with applicable relevant standards that are authoritative and published by a well-established
and recognized Internet standards body, such as the relevant Standards-Track or Best Current Practice
Requests for Comments (“RFCs”) sponsored by the Internet Engineering Task Force; or (2) the creation
of a condition that adversely affects the throughput, response time, consistency or coherence of responses
to Internet servers or end systems operating in accordance with applicable relevant standards that are
authoritative and published by a well-established and recognized Internet standards body, such as the
relevant Standards-Track or Best Current Practice RFCs, and relying on Registry Operator's delegated
information or provisioning of services.
7.4 No Offset.  All payments due under this Agreement will be made in a timely manner
throughout the Term and notwithstanding the pendency of any dispute (monetary or otherwise) between
Registry Operator and ICANN.
7.5 Change in Control; Assignment and Subcontracting.  Neither party may assign this
Agreement without the prior written approval of the other party, which approval will not be unreasonably
withheld.  Notwithstanding the foregoing, ICANN may assign this Agreement in conjunction with a
reorganization or re-incorporation of ICANN to another nonprofit corporation or similar entity organized
in the same legal jurisdiction in which ICANN is currently organized for the same or substantially the
same purposes.  For purposes of this Section 7.5, a direct or indirect change of control of Registry
Operator or any material subcontracting arrangement with respect to the operation of the registry for the
TLD shall be deemed an assignment.  ICANN shall be deemed to have reasonably withheld its consent to
any such a direct or indirect change of control or subcontracting arrangement in the event that ICANN
reasonably determines that the person or entity acquiring control of Registry Operator or entering into
such subcontracting arrangement (or the ultimate parent entity of such acquiring or subcontracting entity)
does not meet the ICANN-adopted registry operator criteria or qualifications then in effect.  In addition,
without limiting the foregoing, Registry Operator must provide no less than thirty (30) calendar days
advance notice to ICANN of any material subcontracting arrangements, and any agreement to subcontract
portions of the operations of the TLD must mandate compliance with all covenants, obligations and
agreements by Registry Operator hereunder, and Registry Operator shall continue to be bound by such
covenants, obligations and agreements.  Without limiting the foregoing, Registry Operator must also
provide no less than thirty (30) calendar days advance notice to ICANN prior to the consummation of any
transaction anticipated to result in a direct or indirect change of control of Registry Operator.  Such
change of control notification shall include a statement that affirms that the ultimate parent entity of the
party acquiring such control meets the ICANN-adopted specification or policy on registry operator
criteria then in effect, and affirms that Registry Operator is in compliance with its obligations under this
Agreement.  Within thirty (30) calendar days of such notification, ICANN may request additional
information from Registry Operator establishing compliance with this Agreement, in which case Registry
Operator must supply the requested information within fifteen (15) calendar days.  If ICANN fails to
expressly provide or withhold its consent to any direct or indirect change of control of Registry Operator
or any material subcontracting arrangement within thirty (30) (or, if ICANN has requested additional
information from Registry Operator as set forth above, sixty (60)) calendar days of the receipt of written
notice of such transaction from Registry Operator, ICANN shall be deemed to have consented to such
transaction.  In connection with any such transaction, Registry Operator shall comply with the Registry
Transition Process.
7.6 Amendments and Waivers.  
(a) If ICANN determines that an amendment to this Agreement (including to the
Specifications referred to herein) and all other registry agreements between ICANN and the Applicable DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
Registry Operators (the “Applicable Registry Agreements”) is desirable (each, a “Special Amendment”),
ICANN may submit a Special Amendment for approval by the Applicable Registry Operators pursuant to
the process set forth in this Section 7.6, provided that a Special Amendment is not a Restricted
Amendment (as defined below).  Prior to submitting a Special Amendment for such approval, ICANN
shall first consult in good faith with the Working Group (as defined below) regarding the form and
substance of a Special Amendment.  The duration of such consultation shall be reasonably determined by
ICANN based on the substance of the Special Amendment.  Following such consultation, ICANN may
propose the adoption of a Special Amendment by publicly posting such amendment on its website for no
less than thirty (30) calendar days (the “Posting Period”) and providing notice of such amendment by
ICANN to the Applicable Registry Operators in accordance with Section 7.8.  ICANN will consider the
public comments submitted on a Special Amendment during the Posting Period (including comments
submitted by the Applicable Registry Operators).
(b) If, within two (2) calendar years of the expiration of the Posting Period (the
“Approval Period”), (i) the ICANN Board of Directors approves a Special Amendment (which may be in
a form different than submitted for public comment) and (ii) such Special Amendment receives Registry
Operator Approval (as defined below), such Special Amendment shall be deemed approved (an
“Approved Amendment”) by the Applicable Registry Operators (the last date on which such approvals
are obtained is herein referred to as the “Amendment Approval Date”) and shall be effective and deemed
an amendment to this Agreement upon sixty (60) calendar days notice from ICANN to Registry Operator
(the “Amendment Effective Date”).  In the event that a Special Amendment is not approved by the
ICANN Board of Directors or does not receive Registry Operator Approval within the Approval Period,
the Special Amendment will have no effect.  The procedure used by ICANN to obtain Registry Operator
Approval shall be designed to document the written approval of the Applicable Registry Operators, which
may be in electronic form.
(c) During the thirty (30) calendar day period following the Amendment Approval
Date, Registry Operator (so long as it did not vote in favor of the Approved Amendment) may apply in
writing to ICANN for an exemption from the Approved Amendment (each such request submitted by
Registry Operator hereunder, an “Exemption Request”).  Each Exemption Request will set forth the basis
for such request and provide detailed support for an exemption from the Approved Amendment.  An
Exemption Request may also include a detailed description and support for any alternatives to, or a
variation of, the Approved Amendment proposed by such Registry Operator.  An Exemption Request
may only be granted upon a clear and convincing showing by Registry Operator that compliance with the
Approved Amendment conflicts with applicable laws or would have a material adverse effect on the longterm financial condition or results of operations of Registry Operator.  No Exemption Request will be
granted if ICANN determines, in its reasonable discretion, that granting such Exemption Request would
be materially harmful to registrants or result in the denial of a direct benefit to registrants.  Within ninety
(90) calendar days of ICANN’s receipt of an Exemption Request, ICANN shall either approve (which
approval may be conditioned or consist of alternatives to or a variation of the Approved Amendment) or
deny the Exemption Request in writing, during which time the Approved Amendment will not amend this
Agreement; provided, that any such conditions, alternatives or variations shall be effective and, to the
extent applicable, will amend this Agreement as of the Amendment Effective Date.  If the Exemption
Request is approved by ICANN, the Approved Amendment will not amend this Agreement.  If such
Exemption Request is denied by ICANN, the Approved Amendment will amend this Agreement as of the
Amendment Effective Date (or, if such date has passed, such Approved Amendment shall be deemed
effective immediately on the date of such denial), provided that Registry Operator may, within thirty (30)
calendar days following receipt of ICANN’s determination, appeal ICANN’s decision to deny the
Exemption Request pursuant to the dispute resolution procedures set forth in Article 5.  The Approved DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
Amendment will be deemed not to have amended this Agreement during the pendency of the dispute
resolution process.  For avoidance of doubt, only Exemption Requests submitted by Registry Operator
that are approved by ICANN pursuant to this Section 7.6(c) or through an arbitration decision pursuant to
Article 5 shall exempt Registry Operator from any Approved Amendment, and no exemption request
granted to any other Applicable Registry Operator (whether by ICANN or through arbitration) shall have
any effect under this Agreement or exempt Registry Operator from any Approved Amendment.
(d) Except as set forth in this Section 7.6, no amendment, supplement or
modification of this Agreement or any provision hereof shall be binding unless executed in writing by
both parties, and nothing in this Section 7.6 shall restrict ICANN and Registry Operator from entering
into bilateral amendments and modifications to this Agreement negotiated solely between the two parties.
No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by
the party waiving compliance with such provision.  No waiver of any of the provisions of this Agreement
or failure to enforce any of the provisions hereof shall be deemed or shall constitute a waiver of any other
provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly
provided.  For the avoidance of doubt, nothing in this Section 7.6 shall be deemed to limit Registry
Operator’s obligation to comply with Section 2.2.
(e) For purposes of this Section 7.6, the following terms shall have the following
meanings:
(i) “Applicable Registry Operators” means, collectively, the registry
operators of the top-level domains party to a registry agreement that contains a provision
similar to this Section 7.6, including Registry Operator.
(ii) “Registry Operator Approval” means the receipt of each of the
following:  (A) the affirmative approval of the Applicable Registry Operators whose
payments to ICANN accounted for two-thirds of the total amount of fees (converted to
U.S. dollars, if applicable) paid to ICANN by all the Applicable Registry Operators
during the immediately previous calendar year pursuant to the Applicable Registry
Agreements, and (B) the affirmative approval of a majority of the Applicable Registry
Operators at the time such approval is obtained.  For avoidance of doubt, with respect to
clause (B), each Applicable Registry Operator shall have one vote for each top-level
domain operated by such Registry Operator pursuant to an Applicable Registry
Agreement.
(iii) “Restricted Amendment” means the following:  (i) an amendment of
Specification 1, (ii) except to the extent addressed in Section 2.10 hereof, an amendment
that specifies the price charged by Registry Operator to registrars for domain name
registrations, (iii) an amendment to the definition of Registry Services as set forth in the
first paragraph of Section 2.1 of Specification 6, or (iv) an amendment to the length of the
Term.
(iv) “Working Group” means representatives of the Applicable Registry
Operators and other members of the community that ICANN appoints, from time to time,
to serve as a working group to consult on amendments to the Applicable Registry
Agreements (excluding bilateral amendments pursuant to Section 7.6(d)). DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
7.7 No Third-Party Beneficiaries.  This Agreement will not be construed to create any
obligation by either ICANN or Registry Operator to any non-party to this Agreement, including any
registrar or registered name holder.
7.8 General Notices.  Except for notices pursuant to Section 7.6, all notices to be given
under or in relation to this Agreement will be given either (i) in writing at the address of the appropriate
party as set forth below or (ii) via facsimile or electronic mail as provided below, unless that party has
given a notice of change of postal or email address, or facsimile number, as provided in this agreement.
All notices under Section 7.6 shall be given by both posting of the applicable information on ICANN’s
web site and transmission of such information to Registry Operator by electronic mail.  Any change in the
contact information for notice below will be given by the party within thirty (30) calendar days of such
change.  Notices, designations, determinations, and specifications made under this Agreement will be in
the English language.  Other than notices under Section 7.6, any notice required by this Agreement will
be deemed to have been properly given (i) if in paper form, when delivered in person or via courier
service with confirmation of receipt or (ii) if via facsimile or by electronic mail, upon confirmation of
receipt by the recipient’s facsimile machine or email server, provided that such notice via facsimile or
electronic mail shall be followed by a copy sent by regular postal mail service within two (2) business
days.  Any notice required by Section 7.6 will be deemed to have been given when electronically posted
on ICANN’s website and upon confirmation of receipt by the email server.  In the event other means of
notice become practically achievable, such as notice via a secure website, the parties will work together to
implement such notice means under this Agreement.
If to ICANN, addressed to:
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina Del Rey, California  90292
Telephone:  1-310-823-9358
Facsimile:  1-310-823-8649
Attention:  President and CEO
With a Required Copy to:  General Counsel
Email:  (As specified from time to time.)
If to Registry Operator, addressed to:
[________________]
[________________]
[________________]
Telephone:  
Facsimile:  
Attention:
With a Required Copy to:  
Email:  (As specified from time to time.)
7.9 Entire Agreement.  This Agreement (including those specifications and documents
incorporated by reference to URL locations which form a part of it) constitutes the entire agreement of the
parties hereto pertaining to the operation of the TLD and supersedes all prior agreements, understandings,
negotiations and discussions, whether oral or written, between the parties on that subject. DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
7.10 English Language Controls.  Notwithstanding any translated version of this Agreement
and/or specifications that may be provided to Registry Operator, the English language version of this
Agreement and all referenced specifications are the official versions that bind the parties hereto.  In the
event of any conflict or discrepancy between any translated version of this Agreement and the English
language version, the English language version controls.  Notices, designations, determinations, and
specifications made under this Agreement shall be in the English language.
7.11 Ownership Rights.  Nothing contained in this Agreement shall be construed as
establishing or granting to Registry Operator any property ownership rights or interests in the TLD or the
letters, words, symbols or other characters making up the TLD string.
7.12 Severability.  This Agreement shall be deemed severable; the invalidity or
unenforceability of any term or provision of this Agreement shall not affect the validity or enforceability
of the balance of this Agreement or of any other term hereof, which shall remain in full force and effect.
If any of the provisions hereof are determined to be invalid or unenforceable, the parties shall negotiate in
good faith to modify this Agreement so as to effect the original intent of the parties as closely as possible.
7.13 Court Orders.  ICANN will respect any order from a court of competent jurisdiction,
including any orders from any jurisdiction where the consent or non-objection of the government was a
requirement for the delegation of the TLD. Notwithstanding any other provision of this Agreement,
ICANN's implementation of any such order will not be a breach of this Agreement.
[Note: The following section is applicable to intergovernmental organizations or governmental entities
only.]
7.14 Special Provision Relating to Intergovernmental Organizations or Governmental
Entities.
(a) ICANN acknowledges that Registry Operator is an entity subject to public
international law, including international treaties applicable to Registry Operator (such public
international law and treaties, collectively hereinafter the “Applicable Laws”). Nothing in this Agreement
and its related specifications shall be construed or interpreted to require Registry Operator to violate
Applicable Laws or prevent compliance therewith. The Parties agree that Registry Operator’s compliance
with Applicable Laws shall not constitute a breach of this Agreement.
(b) In the event Registry Operator reasonably determines that any provision of this
Agreement and its related specifications, or any decisions or policies of ICANN referred to in this
Agreement, including but not limited to Temporary Policies and Consensus Policies (such provisions,
specifications and policies, collectively hereinafter, “ICANN Requirements”), may conflict with or
violate Applicable Law (hereinafter, a “Potential Conflict”), Registry Operator shall provide detailed
notice (a “Notice”) of such Potential Conflict to ICANN as early as possible and, in the case of a Potential
Conflict with a proposed Consensus Policy, no later than the end of any public comment period on such
proposed Consensus Policy.  In the event Registry Operator determines that there is Potential Conflict
between a proposed Applicable Law and any ICANN Requirement, Registry Operator shall provide
detailed Notice of such Potential Conflict to ICANN as early as possible and, in the case of a Potential
Conflict with a proposed Consensus Policy, no later than the end of any public comment period on such
proposed Consensus Policy.
(c) As soon as practicable following such review, the parties shall attempt to resolve
the Potential Conflict by cooperative engagement pursuant to the procedures set forth in Section 5.1.  In DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
addition, Registry Operator shall use its best efforts to eliminate or minimize any impact arising from
such Potential Conflict between Applicable Laws and any ICANN Requirement.  If, following such
cooperative engagement, Registry Operator determines that the Potential Conflict constitutes an actual
conflict between any ICANN Requirement, on the one hand, and Applicable Laws, on the other hand,
then ICANN shall waive compliance with such ICANN Requirement (provided that the parties shall
negotiate in good faith on a continuous basis thereafter to mitigate or eliminate the effects of such noncompliance on ICANN), unless ICANN reasonably and objectively determines that the failure of Registry
Operator to comply with such ICANN Requirement would constitute a threat to the Security and Stability
of Registry Services, the Internet or the DNS (hereinafter, an “ICANN Determination”).  Following
receipt of notice by Registry Operator of such ICANN Determination, Registry Operator shall be afforded
a period of ninety (90) calendar days to resolve such conflict with an Applicable Law.  If the conflict with
an Applicable Law is not resolved to ICANN’s complete satisfaction during such period, Registry
Operator shall have the option to submit, within ten (10) calendar days thereafter, the matter to binding
arbitration as defined in subsection (d) below.  If during such period, Registry Operator does not submit
the matter to arbitration pursuant to subsection (d) below, ICANN may, upon notice to Registry Operator,
terminate this Agreement with immediate effect.
(d) If Registry Operator disagrees with an ICANN Determination, Registry Operator
may submit the matter to binding arbitration pursuant to the provisions of Section 5.2, except that the sole
issue presented to the arbitrator for determination will be whether or not ICANN reasonably and
objectively reached the ICANN Determination.  For the purposes of such arbitration, ICANN shall
present evidence to the arbitrator supporting the ICANN Determination.  If the arbitrator determines that
ICANN did not reasonably and objectively reach the ICANN Determination, then ICANN shall waive
Registry Operator’s compliance with the subject ICANN Requirement.  If the arbitrators or pre-arbitral
referee, as applicable, determine that ICANN did reasonably and objectively reach the ICANN
Determination, then, upon notice to Registry Operator, ICANN may terminate this Agreement with
immediate effect.
(e) Registry Operator hereby represents and warrants that, to the best of its
knowledge as of the date of execution of this Agreement, no existing ICANN Requirement conflicts with
or violates any Applicable Law.
(f) Notwithstanding any other provision of this Section 7.14, following an ICANN
Determination and prior to a finding by an arbitrator pursuant to Section 7.14(d) above, ICANN may,
subject to prior consultations with Registry Operator, take such reasonable technical measures as it deems
necessary to ensure the Security and Stability of Registry Services, the Internet and the DNS.  These
reasonable technical measures shall be taken by ICANN on an interim basis, until the earlier of the date of
conclusion of the arbitration procedure referred to in Section 7.14(d) above or the date of complete
resolution of the conflict with an Applicable Law.  In case Registry Operator disagrees with such
technical measures taken by ICANN, Registry Operator may submit the matter to binding arbitration
pursuant to the provisions of Section 5.2 above, during which process ICANN may continue to take such
technical measures.  In the event that ICANN takes such measures, Registry Operator shall pay all costs
incurred by ICANN as a result of taking such measures.  In addition, in the event that ICANN takes such
measures, ICANN shall retain and may enforce its rights under the Continued Operations Instrument and
Alternative Instrument, as applicable.
* * * * * DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.DRAFT NEW GTLD REGISTRY AGREEMENT
* Final text will be posted on ICANN website; agreement reference to be replaced by hyperlink.
IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed by their
duly authorized representatives.
INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS
By: _____________________________
 [_____________]
 President and CEO
Date:
[Registry Operator]
By: _____________________________
 [____________]
 [____________]
Date: DRAFT NEW GTLD REGISTRY AGREEMENT
EXHIBIT A
Approved Services    NEW GTLD AGREEMENT SPECIFICATIONS
SPECIFICATION 1
CONSENSUS POLICIES AND TEMPORARY POLICIES SPECIFICATION
1. Consensus Policies.
1.1. “Consensus Policies” are those policies established (1) pursuant to the procedure set forth in
ICANN's Bylaws and due process, and (2) covering those topics listed in Section 1.2 of this
document. The Consensus Policy development process and procedure set forth in ICANN's Bylaws
may be revised from time to time in accordance with the process set forth therein.
1.2. Consensus Policies and the procedures by which they are developed shall be designed to produce,
to the extent possible, a consensus of Internet stakeholders, including the operators of gTLDs.
Consensus Policies shall relate to one or more of the following:
1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate
interoperability, security and/or stability of the Internet or Domain Name System
(“DNS”);
1.2.2. functional and performance specifications for the provision of Registry Services;
1.2.3. Security and Stability of the registry database for the TLD;
1.2.4. registry policies reasonably necessary to implement Consensus Policies relating to
registry operations or registrars;
1.2.5. resolution of disputes regarding the registration of domain names (as opposed to the use
of such domain names); or
1.2.6. restrictions on cross-ownership of registry operators and registrars or registrar resellers
and regulations and restrictions with respect to registry operations and the use of registry
and registrar data in the event that a registry operator and a registrar or registrar reseller
are affiliated.
1.3. Such categories of issues referred to in Section 1.2 shall include, without limitation:
1.3.1.  principles for allocation of registered names in the TLD (e.g., first-come/first-served,
timely renewal, holding period after expiration);
1.3.2.  prohibitions on warehousing of or speculation in domain names by registries or
registrars;
1.3.3.  reservation of registered names in the TLD that may not be registered initially or that
may not be renewed due to reasons reasonably related to (i) avoidance of confusion
among or misleading of users, (ii) intellectual property, or (iii) the technical management
of the DNS or the Internet (e.g., establishment of reservations of names from
registration); and
1.3.4.  maintenance of and access to accurate and up-to-date information concerning domain
name registrations; and procedures to avoid disruptions of domain name registrations due
to suspension or termination of operations by a registry operator or a registrar, including
procedures for allocation of responsibility for serving registered domain names in a TLD
affected by such a suspension or termination.
1.4. In addition to the other limitations on Consensus Policies, they shall not:    NEW GTLD AGREEMENT SPECIFICATIONS
1.4.1. prescribe or limit the price of Registry Services;
1.4.2.  modify the terms or conditions for the renewal or termination of the Registry Agreement;
1.4.3. modify the limitations on Temporary Policies (defined below) or Consensus Policies;
1.4.4. modify the provisions in the registry agreement regarding fees paid by Registry Operator
 to ICANN; or
1.4.5. modify ICANN’s obligations to ensure equitable treatment of registry operators and act  
 in an open and transparent manner.
2. Temporary Policies. Registry Operator shall comply with and implement all specifications or
policies established by the Board on a temporary basis, if adopted by the Board by a vote of at least
two-thirds of its members, so long as the Board reasonably determines that such modifications or
amendments are justified and that immediate temporary establishment of a specification or policy on
the subject is necessary to maintain the stability or security of Registry Services or the DNS
("Temporary Policies").
2.1. Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those
objectives. In establishing any Temporary Policy, the Board shall state the period of time for
which the Temporary Policy is adopted and shall immediately implement the Consensus Policy
development process set forth in ICANN's Bylaws.
2.1.1. ICANN shall also issue an advisory statement containing a detailed explanation of its
reasons for adopting the Temporary Policy and why the Board believes such Temporary
Policy should receive the consensus support of Internet stakeholders.
2.1.2. If the period of time for which the Temporary Policy is adopted exceeds 90 days, the Board
shall reaffirm its temporary adoption every 90 days for a total period not to exceed one
year, in order to maintain such Temporary Policy in effect until such time as it becomes a
Consensus Policy. If the one year period expires or, if during such one year period, the
Temporary Policy does not become a Consensus Policy and is not reaffirmed by the Board,
Registry Operator shall no longer be required to comply with or implement such
Temporary Policy.
3. Notice and Conflicts. Registry Operator shall be afforded a reasonable period of time following
notice of the establishment of a Consensus Policy or Temporary Policy in which to comply with such
policy or specification, taking into account any urgency involved. In the event of a conflict between
Registry Services and Consensus Policies or any Temporary Policy, the Consensus Polices or
Temporary Policy shall control, but only with respect to subject matter in conflict. NEW GTLD AGREEMENT SPECIFICATIONS
 
SPECIFICATION 2
DATA ESCROW REQUIREMENTS
Registry Operator will engage an independent entity to act as data escrow agent (“Escrow Agent”) for the
provision of data escrow services related to the Registry Agreement. The following Technical
Specifications set forth in Part A, and Legal Requirements set forth in Part B, will be included in any data
escrow agreement between Registry Operator and the Escrow Agent, under which ICANN must be
named a third-party beneficiary. In addition to the following requirements, the data escrow agreement
may contain other provisions that are not contradictory or intended to subvert the required terms provided
below.
PART A – TECHNICAL SPECIFICATIONS
1. Deposits. There will be two types of Deposits: Full and Differential. For both types, the universe
of Registry objects to be considered for data escrow are those objects necessary in order to offer
all of the approved Registry Services.
1.1 “Full Deposit” will consist of data that reflects the state of the registry as of 00:00:00 UTC on
each Sunday. Pending transactions at that time (i.e., transactions that have not been committed)
will not be reflected in the Full Deposit.
1.2 “Differential Deposit” means data that reflects all transactions that were not reflected in the last
previous Full or Differential Deposit, as the case may be. Each Differential Deposit will contain
all database transactions since the previous Deposit was completed as of 00:00:00 UTC of each
day, but Sunday. Differential Deposits must include complete Escrow Records as specified below
that were not included or changed since the most recent full or Differential Deposit (i.e., newly
added or modified domain names).
2. Schedule for Deposits. Registry Operator will submit a set of escrow files on a daily basis as
follows:
2.1 Each Sunday, a Full Deposit must be submitted to the Escrow Agent by 23:59 UTC.
2.2 The other six days of the week, the corresponding Differential Deposit must be submitted to
Escrow Agent by 23:59 UTC.
3. Escrow Format Specification.
3.1 Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will
be compiled into a file constructed as described in draft-arias-noguchi-registry-data-escrow, see
[1]. The aforementioned document describes some elements as optional; Registry Operator will
include those elements in the Deposits if they are available. Registry Operator will use the draft
version available at the time of signing the Agreement, if not already an RFC. Once the
specification is published as an RFC, Registry Operator will implement that specification, no later
than 180 days after. UTF-8 character encoding will be used.
3.2 Extensions. If a Registry Operator offers additional Registry Services that require submission of
additional data, not included above, additional “extension schemas” shall be defined in a case by
case base to represent that data. These “extension schemas” will be specified as described in [1].
Data related to the “extensions schemas” will be included in the deposit file described in section NEW GTLD AGREEMENT SPECIFICATIONS
 
3.1. ICANN and the respective Registry shall work together to agree on such new objects’ data
escrow specifications.
4. Processing of Deposit files. The use of compression is recommended in order to reduce
electronic data transfer times, and storage capacity requirements. Data encryption will be used to
ensure the privacy of registry escrow data. Files processed for compression and encryption will
be in the binary OpenPGP format as per OpenPGP Message Format - RFC 4880, see [2].
Acceptable algorithms for Public-key cryptography, Symmetric-key cryptography, Hash and
Compression are those enumerated in RFC 4880, not marked as deprecated in OpenPGP IANA
Registry, see [3], that are also royalty-free. The process to follow for a data file in original text
format is:
(1) The file should be compressed. The suggested algorithm for compression is ZIP as per RFC
4880.
(2) The compressed data will be encrypted using the escrow agent's public key. The suggested
algorithms for Public-key encryption are Elgamal and RSA as per RFC 4880. The suggested
algorithms for Symmetric-key encryption are TripleDES, AES128 and CAST5 as per RFC
4880.
(3) The file may be split as necessary if, once compressed and encrypted is larger than the file
size limit agreed with the escrow agent. Every part of a split file, or the whole file if split is
not used, will be called a processed file in this section.
(4) A digital signature file will be generated for every processed file using the Registry's private
key. The digital signature file will be in binary OpenPGP format as per RFC 4880 [2], and
will not be compressed or encrypted. The suggested algorithms for Digital signatures are
DSA and RSA as per RFC 4880.  The suggested algorithm for Hashes in Digital signatures is
SHA256.
(5) The processed files and digital signature files will then be transferred to the Escrow Agent
through secure electronic mechanisms, such as, SFTP, SCP, HTTPS file upload, etc. as
agreed between the Escrow Agent and the Registry Operator. Non-electronic delivery
through a physical medium such as CD-ROMs, DVD-ROMs, or USB storage devices may be
used if authorized by ICANN.
(6) The Escrow Agent will then validate every (processed) transferred data file using the
procedure described in section 8.
5. File Naming Conventions. Files will be named according to the following convention:
{gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:
5.1 {gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the ASCII-compatible form
(A-Label) must be used;
5.2 {YYYY-MM-DD} is replaced by the date corresponding to the time used as a timeline
watermark for the transactions; i.e. for the Full Deposit corresponding to 2009-08-02T00:00Z, the
string to be used would be “2009-08-02”;
5.3 {type} is replaced by:
(1) “full”, if the data represents a Full Deposit;
(2) “diff”, if the data represents a Differential Deposit;
(3) “thin”, if the data represents a Bulk Registration Data Access file, as specified in section 3 of
Specification 4;
5.4 {#} is replaced by the position of the file in a series of files, beginning with “1”; in case of a lone
file, this must be replaced by “1”.
5.5 {rev} is replaced by the number of revision (or resend) of the file beginning with “0”: NEW GTLD AGREEMENT SPECIFICATIONS
 
5.6 {ext} is replaced by “sig” if it is a digital signature file of the quasi-homonymous file. Otherwise
it is replaced by “ryde”.
6. Distribution of Public Keys. Each of Registry Operator and Escrow Agent will distribute its
public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email
to an email address to be specified. Each party will confirm receipt of the other party's public key
with a reply email, and the distributing party will subsequently reconfirm the authenticity of the
key transmitted via offline methods, like in person meeting, telephone, etc. In this way, public
key transmission is authenticated to a user able to send and receive mail via a mail server
operated by the distributing party. Escrow Agent, Registry and ICANN will exchange keys by the
same procedure.
7. Notification of Deposits. Along with the delivery of each Deposit, Registry Operator will deliver
to Escrow Agent and to ICANN a written statement (which may be by authenticated e-mail) that
includes a copy of the report generated upon creation of the Deposit and states that the Deposit
has been inspected by Registry Operator and is complete and accurate. Registry Operator will
include the Deposit’s "id" and "resend" attributes in its statement. The attributes are explained in
[1].
8. Verification Procedure.
(1) The signature file of each processed file is validated.
(2) If processed files are pieces of a bigger file, the latter is put together.
(3) Each file obtained in the previous step is then decrypted and uncompressed.
(4) Each data file contained in the previous step is then validated against the format defined in
[1].
(5) If [1] includes a verification process, that will be applied at this step.
If any discrepancy is found in any of the steps, the Deposit will be considered incomplete.
9. References.
[1]  Domain Name Data Escrow Specification (work in progress), http://tools.ietf.org/html/draft-ariasnoguchi-registry-data-escrow
[2]  OpenPGP Message Format, http://www.rfc-editor.org/rfc/rfc4880.txt
[3]  OpenPGP parameters, http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtmlNEW GTLD AGREEMENT SPECIFICATIONS
 
PART B – LEGAL REQUIREMENTS
1.   Escrow Agent. Prior to entering into an escrow agreement, the Registry Operator must provide
notice to ICANN as to the identity of the Escrow Agent, and provide ICANN with contact
information and a copy of the relevant escrow agreement, and all amendment thereto.  In
addition, prior to entering into an escrow agreement, Registry Operator must obtain the consent of
ICANN to (a) use the specified Escrow Agent, and (b) enter into the form of escrow agreement
provided.  ICANN must be expressly designated a third-party beneficiary of the escrow
agreement. ICANN reserves the right to withhold its consent to any Escrow Agent, escrow
agreement, or any amendment thereto, all in its sole discretion.
2.   Fees. Registry Operator must pay, or have paid on its behalf, fees to the Escrow Agent directly. If
Registry Operator fails to pay any fee by the due date(s), the Escrow Agent will give ICANN
written notice of such non-payment and ICANN may pay the past-due fee(s) within ten business
days after receipt of the written notice from Escrow Agent. Upon payment of the past-due fees by
ICANN, ICANN shall have a claim for such amount against Registry Operator, which Registry
Operator shall be required to submit to ICANN together with the next fee payment due under the
Registry Agreement.
3.   Ownership. Ownership of the Deposits during the effective term of the Registry Agreement shall
remain with Registry Operator at all times.  Thereafter, Registry Operator shall assign any such
ownership rights (including intellectual property rights, as the case may be) in such Deposits to
ICANN.  In the event that during the term of the Registry Agreement any Deposit is released
from escrow to ICANN, any intellectual property rights held by Registry Operator in the Deposits
will automatically be licensed on a non-exclusive, perpetual, irrevocable, royalty-free, paid-up
basis to ICANN or to a party designated in writing by ICANN.
4.   Integrity and Confidentiality. Escrow Agent will be required to (i) hold and maintain the
Deposits in a secure, locked, and environmentally safe facility, which is accessible only to
authorized representatives of Escrow Agent, (ii) protect the integrity and confidentiality of the
Deposits using commercially reasonable measures and (iii) keep and safeguard each Deposit for
one year. ICANN and Registry Operator will be provided the right to inspect Escrow Agent's
applicable records upon reasonable prior notice and during normal business hours.  Registry
Operator and ICANN will be provided with the right to designate a third-party auditor to audit
Escrow Agent’s compliance with the technical specifications and maintenance requirements of
this Specification 2 from time to time.
If Escrow Agent receives a subpoena or any other order from a court or other judicial tribunal
pertaining to the disclosure or release of the Deposits, Escrow Agent will promptly notify the
Registry Operator and ICANN unless prohibited by law.  After notifying the Registry Operator
and ICANN, Escrow Agent shall allow sufficient time for Registry Operator or ICANN to
challenge any such order, which shall be the responsibility of Registry Operator or ICANN;
provided, however, that Escrow Agent does not waive its rights to present its position with
respect to any such order.  Escrow Agent will cooperate with the Registry Operator or ICANN to
support efforts to quash or limit any subpoena, at such party’s expense.  Any party requesting
additional assistance shall pay Escrow Agent’s standard charges or as quoted upon submission of
a detailed request. NEW GTLD AGREEMENT SPECIFICATIONS
 
5.   Copies. Escrow Agent may be permitted to duplicate any Deposit, in order to comply with the
terms and provisions of the escrow agreement.
6.   Release of Deposits. Escrow Agent will make available for electronic download (unless
otherwise requested) to ICANN or its designee, within twenty-four hours, at the Registry
Operator’s expense, all Deposits in Escrow Agent's possession in the event that the Escrow Agent
receives a request from Registry Operator to effect such delivery to ICANN, or receives one of
the following written notices by ICANN stating that:
6.1 the Registry Agreement has expired without renewal, or been terminated; or
6.2 ICANN failed, with respect to (a) any Full Deposit or (b) five Differential Deposits within any
calendar month, to receive, within five calendar days after the Deposit's scheduled delivery date,
notification of receipt from Escrow Agent; (x) ICANN gave notice to Escrow Agent and Registry
Operator of that failure; and (y) ICANN has not, within seven calendar days after such notice,
received notice from Escrow Agent that the Deposit has been received; or
6.3 ICANN has received notification from Escrow Agent of failed verification of a Full Deposit or of
failed verification of five Differential Deposits within any calendar month and (a) ICANN gave
notice to Registry Operator of that receipt; and (b) ICANN has not, within seven calendar days
after such notice, received notice from Escrow Agent of verification of a remediated version of
such Full Deposit or Differential Deposit; or
6.4 Registry Operator has: (i) ceased to conduct its business in the ordinary course; or (ii) filed for
bankruptcy, become insolvent or anything analogous to any of the foregoing under the laws of
any jurisdiction anywhere in the world; or
6.5  Registry Operator has experienced a failure of critical registry functions and ICANN has asserted
its rights pursuant to Section 2.13 of the Registry Agreement; or
6.6 a competent court, arbitral, legislative, or government agency mandates the release of the
Deposits to ICANN.
Unless Escrow Agent has previously released the Registry Operator’s Deposits to ICANN or its
designee, Escrow Agent will deliver all Deposits to ICANN upon termination of the Registry
Agreement or the Escrow Agreement.
7. Verification of Deposits.
7.1 Within twenty-four hours after receiving each Deposit or corrected Deposit, Escrow Agent must
verify the format and completeness of each Deposit and deliver to ICANN a copy of the
verification report generated for each Deposit. Reports will be delivered electronically, as
specified from time to time by ICANN.
7.2 If Escrow Agent discovers that any Deposit fails the verification procedures, Escrow Agent must
notify, either by email, fax or phone, Registry Operator and ICANN of such nonconformity
within twenty-four hours after receiving the non-conformant Deposit. Upon notification of such
verification failure, Registry Operator must begin developing modifications, updates, corrections,
and other fixes of the Deposit necessary for the Deposit to pass the verification procedures and
deliver such fixes to Escrow Agent as promptly as possible.
8. Amendments.  Escrow Agent and Registry Operator shall amend the terms of the Escrow
Agreement to conform to this Specification 2 within ten (10) calendar days of any amendment or
modification to this Specification 2.  In the event of a conflict between this Specification 2 and
the Escrow Agreement, this Specification 2 shall control.
9. Indemnity.  Registry Operator shall indemnify and hold harmless Escrow Agent and each of its
directors, officers, agents, employees, members, and stockholders ("Escrow Agent Indemnitees") NEW GTLD AGREEMENT SPECIFICATIONS
 
absolutely and forever from and against any and all claims, actions, damages, suits, liabilities,
obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable
attorneys' fees and costs, that may be asserted by a third party against any Escrow Agent
Indemnitees in connection with the Escrow Agreement or the performance of Escrow Agent or
any Escrow Agent Indemnitees thereunder (with the exception of any claims based on the
misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents,
employees, contractors, members, and stockholders). Escrow Agent shall indemnify and hold
harmless Registry Operator and ICANN, and each of their respective directors, officers, agents,
employees, members, and stockholders ("Indemnitees") absolutely and forever from and against
any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any
other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted
by a third party against any Indemnitee in connection with the misrepresentation, negligence or
misconduct of Escrow Agent, its directors, officers, agents, employees and contractors.     NEW GTLD AGREEMENT SPECIFICATIONS
SPECIFICATION 3
FORMAT AND CONTENT FOR REGISTRY OPERATOR MONTHLY REPORTING
Registry Operator shall provide one set of monthly reports per gTLD to ____________ with the following
content. ICANN may request in the future that the reports be delivered by other means and using other
formats. ICANN will use reasonable commercial efforts to preserve the confidentiality of the information
reported until three months after the end of the month to which the reports relate.
1. Per-Registrar Transactions Report. This report shall be compiled in a comma separated-value
formatted file as specified in RFC 4180. The file shall be named “gTLD-transactions-yyyymm.csv”,
where “gTLD” is the gTLD name; in case of an IDN-TLD, the A-label shall be used; “yyyymm” is the
year and month being reported. The file shall contain the following fields per registrar:
Field #  Field Name  Description
01  registrar-name  registrar's full corporate name as registered with IANA
02  iana-id  http://www.iana.org/assignments/registrar-ids
03  total-domains  total domains under sponsorship
04  total-nameservers  total name servers registered for TLD
05  net-adds-1-yr  number of domains successfully registered with an initial
term of one year (and not deleted within the add grace
period)
06  net-adds-2-yr  number of domains successfully registered with an initial
term of two years (and not deleted within the add grace
period)
07  net-adds-3-yr  number of domains successfully registered with an initial
term of three years (and not deleted within the add grace
period)
08  net-adds-4-yr  number of domains successfully registered with an
initial term of four years (and not deleted within the
add grace period)
09  net-adds-5-yr  number of domains successfully registered with an
initial term of five years (and not deleted within the
add grace period)
10  net-adds-6-yr  number of domains successfully registered with an
initial term of six years (and not deleted within the add
grace period)
11  net-adds-7-yr  number of domains successfully registered with an
initial term of seven years (and not deleted within the
add grace period)    NEW GTLD AGREEMENT SPECIFICATIONS
 
12  net-adds-8-yr  number of domains successfully registered with an
initial term of eight years (and not deleted within the
add grace period)
13  net-adds-9-yr  number of domains successfully registered with an
initial term of nine years (and not deleted within the
add grace period)
14  net-adds-10-yr  number of domains successfully registered with an
initial term of ten years (and not deleted within the add
grace period)
15  net-renews-1-yr  number of domains successfully renewed either
automatically or by command with a new renewal period of
one year (and not deleted within the renew grace period)
16  net-renews-2-yr  number of domains successfully renewed either
automatically or by command with a new renewal period of
two years (and not deleted within the renew grace period)
17  net-renews-3-yr  number of domains successfully renewed either
automatically or by command with a new renewal period of
three years (and not deleted within the renew grace period)
18  net-renews-4-yr  number of domains successfully renewed either
automatically or by command with a new renewal
period of four years (and not deleted within the renew
grace period)
19  net-renews-5-yr  number of domains successfully renewed either
automatically or by command with a new renewal
period of five years (and not deleted within the renew
grace period)
20  net-renews-6-yr  number of domains successfully renewed either
automatically or by command with a new renewal
period of six years (and not deleted within the renew
grace period)
21  net-renews-7-yr  number of domains successfully renewed either
automatically or by command with a new renewal
period of seven years (and not deleted within the
renew grace period)
22  net-renews-8-yr  number of domains successfully renewed either
automatically or by command with a new renewal
period of eight years (and not deleted within the renew
grace period)
23  net-renews-9-yr  number of domains successfully renewed either     NEW GTLD AGREEMENT SPECIFICATIONS
 
automatically or by command with a new renewal
period of nine years (and not deleted within the renew
grace period)
24  net-renews-10-yr  number of domains successfully renewed either
automatically or by command with a new renewal
period of ten years (and not deleted within the renew
grace period)
25
transfer-gaining-successful
transfers initiated by this registrar that were ack'd by the
other registrar – either by command or automatically
26
transfer-gaining-nacked
transfers initiated by this registrar that were n'acked by the
other registrar
27
transfer-losing-successful
transfers initiated by another registrar that this registrar
ack'd – either by command or automatically
28
transfer-losing-nacked
transfers initiated by another registrar that this registrar
n'acked
29  transfer-disputed-won  number of transfer disputes in which this registrar prevailed
30  transfer-disputed-lost  number of transfer disputes this registrar lost
31
transfer-disputed-nodecision
number of transfer disputes involving this registrar with a
split or no decision
32  deleted-domains-grace  domains deleted within the add grace period
33  deleted-domains-nograce  domains deleted outside the add grace period
34  restored-domains  domain names restored from redemption period
35  restored-noreport  total number of restored names for which the registrar failed
to submit a restore report
36 agp-exemption-requests total number of AGP (add grace period) exemption requests
37 agp-exemptions-granted total number of AGP (add grace period) exemption requests
granted
38 agp-exempted-domains total number of names affected by granted AGP (add grace
period) exemption requests
39 attempted-adds number of attempted (successful and failed) domain
name create commands
The first line shall include the field names exactly as described in the table above as a “header line” as
described in section 2 of RFC 4180. The last line of each report shall include totals for each column
across all registrars; the first field of this line shall read “Totals” while the second field shall be left empty
in that line. No other lines besides the ones described above shall be included. Line breaks shall be
<U+000D, U+000A> as described in RFC 4180.     NEW GTLD AGREEMENT SPECIFICATIONS
2. Registry Functions Activity Report. This report shall be compiled in a comma separated-value
formatted file as specified in RFC 4180. The file shall be named “gTLD-activity-yyyymm.csv”, where
“gTLD” is the gTLD name; in case of an IDN-TLD, the A-label shall be used; “yyyymm” is the year and
month being reported. The file shall contain the following fields:
Field #  Field Name  Description
01  operational-registrars  number of operational registrars at the end of the reporting
period
02  ramp-up-registrars  number of registrars that have received a password for
access to OT&E at the end of the reporting period
03  pre-ramp-up-registrars number of registrars that have requested access, but have
not yet entered the ramp-up period at the end of the
reporting period
04  zfa-passwords number of active zone file access passwords at the end of
the reporting period
05  whois-43-queries number of WHOIS (port-43) queries responded during the
reporting period
06  web-whois-queries number of Web-based Whois queries responded during the
reporting period, not including searchable Whois
07  searchable-whois-queries number of searchable Whois queries responded during the
reporting period, if offered
08  dns-udp-queries-received number of DNS queries received over UDP transport during
the reporting period
09  dns-udp-queries-responded number of DNS queries received over UDP transport that
were responded during the reporting period
10  dns-tcp-queries-received number of DNS queries received over TCP transport during
the reporting period
11  dns-tcp-queries-responded number of DNS queries received over TCP transport that
were responded during the reporting period
12  srs-dom-check number of SRS (EPP and any other interface) domain name
“check” requests responded during the reporting period
13  srs-dom-create number of SRS (EPP and any other interface) domain name
“create” requests responded during the reporting period
14  srs-dom-delete number of SRS (EPP and any other interface) domain name
“delete” requests responded during the reporting period
15  srs-dom-info number of SRS (EPP and any other interface) domain name
“info” requests responded during the reporting period
16  srs-dom-renew number of SRS (EPP and any other interface) domain name     NEW GTLD AGREEMENT SPECIFICATIONS
“renew” requests responded during the reporting period
17  srs-dom-rgp-restore-report number of SRS (EPP and any other interface) domain name
RGP “restore” requests responded during the reporting
period
18  srs-dom-rgp-restore-request number of SRS (EPP and any other interface) domain name
RGP “restore” requests delivering a restore report
responded during the reporting period
19  srs-dom-transfer-approve number of SRS (EPP and any other interface) domain name
“transfer” requests to approve transfers responded during
the reporting period
20  srs-dom-transfer-cancel number of SRS (EPP and any other interface) domain name
“transfer” requests to cancel transfers responded during the
reporting period
21  srs-dom-transfer-query number of SRS (EPP and any other interface) domain name
“transfer” requests to query about a transfer responded
during the reporting period
22  srs-dom-transfer-reject number of SRS (EPP and any other interface) domain name
“transfer” requests to reject transfers responded during the
reporting period
23  srs-dom-transfer-request number of SRS (EPP and any other interface) domain name
“transfer” requests to request transfers responded during the
reporting period
24  srs-dom-update number of SRS (EPP and any other interface) domain name
“update” requests (not including RGP restore requests)
responded during the reporting period
25
srs-host-check
number of SRS (EPP and any other interface) host “check”
requests responded during the reporting period
26
srs-host-create
number of SRS (EPP and any other interface) host “create”
requests responded during the reporting period
27
srs-host-delete
number of SRS (EPP and any other interface) host “delete”
requests responded during the reporting period
28
srs-host-info
number of SRS (EPP and any other interface) host “info”
requests responded during the reporting period
29
srs-host-update
number of SRS (EPP and any other interface) host “update”
requests responded during the reporting period
30
srs-cont-check
number of SRS (EPP and any other interface) contact
“check” requests responded during the reporting period
31
srs-cont-create
number of SRS (EPP and any other interface) contact
“create” requests responded during the reporting period    NEW GTLD AGREEMENT SPECIFICATIONS
 
32  srs-cont-delete number of SRS (EPP and any other interface) contact
“delete” requests responded during the reporting period
33  srs-cont-info number of SRS (EPP and any other interface) contact “info”
requests responded during the reporting period
34  srs-cont-transfer-approve number of SRS (EPP and any other interface) contact
“transfer” requests to approve transfers responded during
the reporting period
35  srs-cont-transfer-cancel number of SRS (EPP and any other interface) contact
“transfer” requests to cancel transfers responded during the
reporting period
36 srs-cont-transfer-query number of SRS (EPP and any other interface) contact
“transfer” requests to query about a transfer responded
during the reporting period
37 srs-cont-transfer-reject number of SRS (EPP and any other interface) contact
“transfer” requests to reject transfers responded during the
reporting period
38 srs-cont-transfer-request number of SRS (EPP and any other interface) contact
“transfer” requests to request transfers responded during the
reporting period
39 srs-cont-update number of SRS (EPP and any other interface) contact
“update” requests responded during the reporting period
The first line shall include the field names exactly as described in the table above as a “header line” as
described in section 2 of RFC 4180. The last line of each report shall include totals for each column
across all registrars; the first field of this line shall read “Totals” while the second field shall be left empty
in that line. No other lines besides the ones described above shall be included. Line breaks shall be
<U+000D, U+000A> as described in RFC 4180.     NEW GTLD AGREEMENT SPECIFICATIONS
SPECIFICATION 4
SPECIFICATION FOR REGISTRATION DATA PUBLICATION SERVICES
1. Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator
will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based
Directory Service at <whois.nic.TLD> providing free public query-based access to at least the following
elements in the following format.  ICANN reserves the right to specify alternative formats and protocols,
and upon such specification, the Registry Operator will implement such alternative specification as soon
as reasonably practicable.
 1.1. The format of responses shall follow a semi-free text format outline below, followed by a
blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the
database.
 1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with
keys, followed by a colon and a space as delimiters, followed by the value.
 1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall
be allowed (for example to list multiple name servers). The first key/value pair after a blank line should
be considered the start of a new record, and should be considered as identifying that record, and is used to
group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
 1.4. Domain Name Data:
  1.4.1. Query format: whois EXAMPLE.TLD
  1.4.2. Response format:
  Domain Name: EXAMPLE.TLD
  Domain ID: D1234567-TLD
  WHOIS Server: whois.example.tld
  Referral URL: http://www.example.tld
  Updated Date: 2009-05-29T20:13:00Z
  Creation Date: 2000-10-08T00:45:00Z
  Registry Expiry Date: 2010-10-08T00:44:59Z
  Sponsoring Registrar: EXAMPLE REGISTRAR LLC
  Sponsoring Registrar IANA ID: 5555555
  Domain Status: clientDeleteProhibited
  Domain Status: clientRenewProhibited
  Domain Status: clientTransferProhibited
  Domain Status: serverUpdateProhibited
  Registrant ID: 5372808-ERL
  Registrant Name: EXAMPLE REGISTRANT
  Registrant Organization: EXAMPLE ORGANIZATION
  Registrant Street: 123 EXAMPLE STREET
  Registrant City: ANYTOWN
  Registrant State/Province: AP
  Registrant Postal Code: A1A1A1
  Registrant Country: EX     NEW GTLD AGREEMENT SPECIFICATIONS
  Registrant Phone: +1.5555551212
  Registrant Phone Ext: 1234
  Registrant Fax: +1.5555551213
  Registrant Fax Ext: 4321
  Registrant Email: EMAIL@EXAMPLE.TLD
  Admin ID: 5372809-ERL
  Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
  Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
  Admin Street: 123 EXAMPLE STREET
  Admin City: ANYTOWN
  Admin State/Province: AP
  Admin Postal Code: A1A1A1
  Admin Country: EX
  Admin Phone: +1.5555551212
  Admin Phone Ext: 1234
  Admin Fax: +1.5555551213
  Admin Fax Ext:
  Admin Email: EMAIL@EXAMPLE.TLD
  Tech ID: 5372811-ERL
  Tech Name: EXAMPLE REGISTRAR TECHNICAL
  Tech Organization: EXAMPLE REGISTRAR LLC
  Tech Street: 123 EXAMPLE STREET
  Tech City: ANYTOWN
  Tech State/Province: AP
  Tech Postal Code: A1A1A1
  Tech Country: EX
  Tech Phone: +1.1235551234
  Tech Phone Ext: 1234
  Tech Fax: +1.5555551213
  Tech Fax Ext: 93
  Tech Email: EMAIL@EXAMPLE.TLD
  Name Server: NS01.EXAMPLEREGISTRAR.TLD
  Name Server: NS02.EXAMPLEREGISTRAR.TLD
  DNSSEC: signedDelegation
  DNSSEC: unsigned
  >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
 1.5. Registrar Data:
  1.5.1. Query format: whois "registrar Example Registrar, Inc."
  1.5.2. Response format:
Registrar Name: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State/Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213     NEW GTLD AGREEMENT SPECIFICATIONS
 
Email: registrar@example.tld
WHOIS Server: whois.example-registrar.tld
Referral URL: http://www. example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
 1.6. Nameserver Data:
 
  1.6.1. Query format: whois "NS1.EXAMPLE.TLD" or whois "nameserver (IP Address)"
  1.6.2. Response format:
   Server Name: NS1.EXAMPLE.TLD
   IP Address: 192.0.2.123
   IP Address: 2001:0DB8::1
   Registrar: Example Registrar, Inc.
   WHOIS Server: whois.example-registrar.tld
   Referral URL: http://www. example-registrar.tld
   >>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
 1.7. The format of the following data fields: domain status, individual and organizational names,
address, street, city, state/province, postal code, country, telephone and fax numbers, email addresses,
date and times should conform to the mappings specified in EPP RFCs 5730-5734 so that the display of
this information (or values return in WHOIS responses) can be uniformly processed and understood.
 1.8. Searchability. Offering searchability capabilities on the Directory Services is optional but if
offered by the Registry Operator it shall comply with the specification described in this section.
  1.8.1. Registry Operator will offer searchability on the web-based Directory Service.
  1.8.2. Registry Operator will offer partial match capabilities, at least, on the following
fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including
all the sub-fields described in EPP (e.g., street, city, state or province, etc.).
  1.8.3. Registry Operator will offer exact-match capabilities, at least, on the following
fields: registrar id, name server name, and name server’s IP address (only applies to IP addresses stored
by the registry, i.e., glue records).     NEW GTLD AGREEMENT SPECIFICATIONS
  1.8.4. Registry Operator will offer Boolean search capabilities supporting, at least, the
following logical operators to join a set of search criteria: AND, OR, NOT.
  1.8.5. Search results will include domain names matching the search criteria.
  1.8.6. Registry Operator will: 1) implement appropriate measures to avoid abuse of this
feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in
compliance with any applicable privacy laws or policies.
 
2. Zone File Access
2.1. Third-Party Access
   2.1.1. Zone File Access Agreement. Registry Operator will enter into an agreement with
any Internet user that will allow such user to access an Internet host server or servers designated by
Registry Operator and download zone file data.  The agreement will be standardized, facilitated and
administered by a Centralized Zone Data Access Provider (the “CZDA Provider”).  Registry Operator
will provide access to zone file data per Section 2.1.3 and do so using the file format described in Section
2.1.4.  Notwithstanding the foregoing, (a) the CZDA Provider may reject the request for access of any
user that does not satisfy the credentialing requirements in Section 2.1.2 below; (b) Registry Operator
may reject the request for access of any user that does not provide correct or legitimate credentials under
Section 2.1. 2 or where Registry Operator reasonably believes will violate the terms of Section 2.1.5.
below; and, (c) Registry Operator may revoke access of any user if Registry Operator has evidence to
support that the user has violated the terms of Section 2.1.5.
   2.1.2. Credentialing Requirements. Registry Operator, through the facilitation of the
CZDA Provider, will request each user to provide it with information sufficient to correctly identify and
locate the user. Such user information will include, without limitation, company name, contact name,
address, telephone number, facsimile number, email address, and the Internet host machine name and IP
address.
   2.1.3. Grant of Access. Each Registry Operator will provide the Zone File FTP (or other
Registry supported) service for an ICANN-specified and managed URL (specifically,
<TLD>.zda.icann.org where <TLD> is the TLD for which the registry is responsible) for the user to
access the Registry’s zone data archives. Registry Operator will grant the user a non-exclusive, nontransferable, limited right to access Registry Operator’s Zone File FTP server, and to transfer a copy of
the top-level domain zone files, and any associated cryptographic checksum files no more than once per
24 hour period using FTP,  or other data transport and access protocols that may be prescribed by
ICANN. For every zone file access server, the zone files are in the top-level directory called
<zone>.zone.gz, with <zone>.zone.gz.md5 and <zone>.zone.gz.sig to verify downloads. If the Registry
Operator also provides historical data, it will use the naming pattern <zone>-yyyymmdd.zone.gz, etc.  
  2.1.4. File Format Standard. Registry Operator will provide zone files using a subformat of the standard Master File format as originally defined in RFC 1035, Section 5, including all the
records present in the actual zone used in the public DNS. Sub-format is as follows:
1. Each record must include all fields in one line as: <domain-name> <TTL> <class> <type>
<RDATA>.
2. Class and Type must use the standard mnemonics and must be in lower case.      NEW GTLD AGREEMENT SPECIFICATIONS
3. TTL must be present as a decimal integer.
4. Use of /X and /DDD inside domain names is allowed.
5. All domain names must be in lower case.
6. Must use exactly one tab as separator of fields inside a record.
7. All domain names must be fully qualified.
8. No $ORIGIN directives.
9. No use of "@" to denote current origin.
10. No use of "blank domain names" at the beginning of a record to continue the use of the domain
name in the previous record.
11. No $INCLUDE directives.
12. No $TTL directives.
13. No use of parentheses, e.g., to continue the list of fields in a record across a line boundary.
14. No use of comments.
15. No blank lines.
16. The SOA record should be present at the top and (duplicated at) the end of the zone file.
17. With the exception of the SOA record, all the records in a file must be in alphabetical order.
18. One zone per file. If a TLD divides its DNS data into multiple zones, each goes into a separate
file named as above, with all the files combined using tar into a file called <tld>.zone.tar.
   2.1.5. Use of Data by User. Registry Operator will permit user to use the zone file for
lawful purposes; provided that, (a) user takes all reasonable steps to protect against unauthorized access to
and use and disclosure of the data, and (b) under no circumstances will Registry Operator be required or
permitted to allow user to use the data to, (i) allow, enable, or otherwise support the transmission by email, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other
than user’s own existing customers, or (ii) enable high volume, automated, electronic processes that send
queries or data to the systems of Registry Operator or any ICANN-accredited registrar.  
   2.1.6. Term of Use. Registry Operator, through CZDA Provider, will provide each user
with access to the zone file for a period of not less than three (3) months. Registry Operator will allow
users to renew their Grant of Access.
   2.1.7. No Fee for Access. Registry Operator will provide, and CZDA Provider will
facilitate, access to the zone file to user at no cost.
2.2 Co-operation
2.2.1. Assistance. Registry Operator will co-operate and provide reasonable assistance to
ICANN and the CZDA Provider to facilitate and maintain the efficient access of zone file data by
permitted users as contemplated under this Schedule.
2.3 ICANN Access.  Registry Operator shall provide bulk access to the zone files for the TLD to ICANN
or its designee on a continuous basis in the manner ICANN may reasonably specify from time to time.
2.4 Emergency Operator Access.  Registry Operator shall provide bulk access to the zone files for the
TLD to the Emergency Operators designated by ICANN on a continuous basis in the manner ICANN
may reasonably specify from time to time.     NEW GTLD AGREEMENT SPECIFICATIONS
3. Bulk Registration Data Access to ICANN
3.1. Periodic Access to Thin Registration Data. In order to verify and ensure the operational
stability of Registry Services as well as to facilitate compliance checks on accredited registrars, Registry
Operator will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date
Registration Data as specified below. Data will include data committed as of 00:00:00 UTC on the day
previous to the one designated for retrieval by ICANN.
3.1.1. Contents. Registry Operator will provide, at least, the following data for all
registered domain names: domain name, domain name repository object id (roid), registrar id
(IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For
sponsoring registrars, at least, it will provide: registrar name, registrar repository object id (roid),
hostname of registrar Whois server, and URL of registrar.
  3.1.2. Format. The data will be provided in the format specified in Specification 2 for
Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the previous
section, i.e., the file will only contain Domain and Registrar objects with the fields mentioned above.
Registry Operator has the option to provide a full deposit file instead as specified in Specification 2.
  3.1.3, Access. Registry Operator will have the file(s) ready for download as of 00:00:00
UTC on the day designated for retrieval by ICANN. The file(s) will be made available for download by
SFTP, though ICANN may request other means in the future.
3.2. Exceptional Access to Thick Registration Data. In case of a registrar failure, deaccreditation, court order, etc. that prompts the temporary or definitive transfer of its domain names to
another registrar, at the request of ICANN, Registry Operator will provide ICANN with up-to-date data
for the domain names of the losing registrar. The data will be provided in the format specified in
Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing
registrar. Registry Operator will provide the data within 2 business days. Unless otherwise agreed by
Registry Operator and ICANN, the file will be made available for download by ICANN in the same
manner as the data specified in Section 3.1. of this Specification.     NEW GTLD AGREEMENT SPECIFICATIONS
 
SPECIFICATION 5
SCHEDULE OF RESERVED NAMES AT THE SECOND LEVEL IN GTLD REGISTRIES
Except to the extent that ICANN otherwise expressly authorizes in writing, Registry Operator shall
reserve (i.e., Registry Operator shall not register, delegate, use or otherwise make available such labels to
any third party, but may register such labels in its own name in order to withhold them from delegation or
use) names formed with the following labels from initial (i.e. other than renewal) registration within the
TLD:
1.   Example. The label “EXAMPLE” shall be reserved at the second level and at all other levels within
 the TLD at which Registry Operator makes registrations.
2.   Two-character labels. All two-character labels shall be initially reserved. The reservation of a two-
 character label string may be released to the extent that Registry Operator reaches agreement with the
 government and country-code manager. The Registry Operator may also propose release of these
 reservations based on its implementation of measures to avoid confusion with the corresponding
 country codes.
3.   Tagged Domain Names. Labels may only include hyphens in the third and fourth position if they
 represent valid internationalized domain names in their ASCII encoding (for example
      "xn--ndk061n").
4.   Second-Level Reservations for Registry Operations. The following names are reserved for use in
 connection with the operation of the registry for the TLD. Registry Operator may use them, but upon
 conclusion of Registry Operator's designation as operator of the registry for the TLD they shall be
 transferred  as specified by ICANN: NIC, WWW, IRIS and WHOIS.
5.   Country and Territory Names. The country and territory names contained in the following
 internationally recognized lists shall be initially reserved at the second level and at all other levels
 within the TLD at which the Registry Operator provides for registrations:
 5.1.  the short form (in English) of all country and territory names contained on the ISO 3166-
  1 list, as updated from time to time, including the European Union, which is  
  exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to
  any application needing to represent the name European Union    
  <http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-
  1_decoding_table.htm#EU>;
 5.2.  the United Nations Group of Experts on Geographical Names, Technical Reference
  Manual for the Standardization of Geographical Names, Part III Names of Countries of
  the World; and
 5.3.  the list of United Nations member states in 6 official United Nations languages prepared
  by the Working Group on Country Names of the United Nations Conference on the
  Standardization  of Geographical Names;
provided, that  the reservation of specific country and territory names may be released to the extent
that Registry Operator reaches agreement with the applicable government(s), provided, further, that     NEW GTLD AGREEMENT SPECIFICATIONS
 
Registry Operator may also propose release of these reservations, subject to review by ICANN’s
Governmental Advisory Committee and approval by ICANN.     NEW GTLD AGREEMENT SPECIFICATIONS
 
SPECIFICATION 6
REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS
1. Standards Compliance
1.1. DNS. Registry Operator shall comply with relevant existing RFCs and those published in the
future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or
additions thereto relating to the DNS and name server operations including without limitation RFCs 1034,
1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.
1.2. EPP. Registry Operator shall comply with relevant existing RFCs and those published in the
future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or
additions thereto relating to the provisioning and management of domain names using the Extensible
Provisioning Protocol (EPP) in conformance with RFCs 5910, 5730, 5731, 5732, 5733 and 5734. If
Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its
successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry
Operator must document EPP extensions in Internet-Draft format following the guidelines described in
RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects
and Extensions supported to ICANN prior to deployment.
1.3. DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System
Security Extensions (“DNSSEC”).  During the Term, Registry Operator shall comply with RFCs 4033,
4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its
successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security
Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key
material from child domain names in a secure manner according to industry best practices. Registry shall
also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls
and procedures for key material storage, access and usage for its own keys and secure acceptance of
registrants’ public-key material. Registry Operator shall publish its DPS following the format described in
“DPS-framework” (currently in draft format, see http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dpsframework) within 180 days after the “DPS-framework” becomes an RFC.
1.4. IDN. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply
with RFCs 5890, 5891, 5892, 5893 and their successors. Registry Operator shall comply with the ICANN
IDN Guidelines at <http://www.icann.org/en/topics/idn/implementation-guidelines.htm>, as they may be
amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its
IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the
ICANN IDN Guidelines.
1.5. IPv6. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry
System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two
of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered
with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described
in BCP 91 and the recommendations and considerations described in RFC 4472. Registry Operator shall
offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of
this Agreement; e.g. Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6
transport for its Shared Registration System (SRS) to any Registrar, no later than six months after
receiving the first request in writing from a gTLD accredited Registrar willing to operate with the SRS
over IPv6.     NEW GTLD AGREEMENT SPECIFICATIONS
 
2. Registry Services
2.1. Registry Services. “Registry Services” are, for purposes of the Registry Agreement, defined as
the following: (a) those services that are operations of the registry critical to the following tasks: the
receipt of data from registrars concerning registrations of domain names and name servers; provision to
registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files;
operation of the registry DNS servers; and dissemination of contact and other information concerning
domain name server registrations in the TLD as required by this Agreement; (b) other products or services
that the Registry Operator is required to provide because of the establishment of a Consensus Policy as
defined in Specification 1; (c) any other products or services that only a registry operator is capable of
providing, by reason of its designation as the registry operator; and (d) material changes to any Registry
Service within the scope of (a), (b) or (c) above.
2.2. Wildcard Prohibition. For domain names which are either not registered, or the registrant has
not supplied valid records such as NS records for listing in the DNS zone file, or their status does not
allow them to be published in the DNS, the use of DNS wildcard Resource Records as described in RFCs
1034 and 4592 or any other method or technology for synthesizing DNS Resources Records or using
redirection within the DNS by the Registry is prohibited. When queried for such domain names the
authoritative name servers must return a “Name Error” response (also known as NXDOMAIN), RCODE
3 as described in RFC 1035 and related RFCs. This provision applies for all DNS zone files at all levels in
the DNS tree for which the Registry Operator (or an affiliate engaged in providing Registration Services)
maintains data, arranges for such maintenance, or derives revenue from such maintenance.
3. Registry Continuity
3.1. High Availability. Registry Operator will conduct its operations using network and
geographically diverse, redundant servers (including network-level redundancy, end-node level
redundancy and the implementation of a load balancing scheme where applicable) to ensure continued
operation in the case of technical failure (widespread or local), or an extraordinary occurrence or
circumstance beyond the control of the Registry Operator.
3.2. Extraordinary Event. Registry Operator will use commercially reasonable efforts to restore the
critical functions of the registry within 24 hours after the termination of an extraordinary event beyond the
control of the Registry Operator and restore full system functionality within a maximum of 48 hours
following such event, depending on the type of critical function involved. Outages due to such an event
will not be considered a lack of service availability.
3.3. Business Continuity. Registry Operator shall maintain a business continuity plan, which will
provide for the maintenance of Registry Services in the event of an extraordinary event beyond the
control of the Registry Operator or business failure of Registry Operator, and may include the designation
of a Registry Services continuity provider.  If such plan includes the designation of a Registry Services
continuity provider, Registry Operator shall provide the name and contact information for such Registry
Services continuity provider to ICANN. In the case of an extraordinary event beyond the control of the
Registry Operator where the Registry Operator cannot be contacted, Registry Operator consents that
ICANN may contact the designated Registry Services continuity provider, if one exists. Registry Operator
shall conduct Registry Services Continuity testing at least once per year.
4.   Abuse Mitigation    NEW GTLD AGREEMENT SPECIFICATIONS
 
4.1. Abuse Contact. Registry Operator shall provide to ICANN and publish on its website its
accurate contact details including a valid email and mailing address as well as a primary contact for
handling inquires related to malicious conduct in the TLD, and will provide ICANN with prompt notice
of any changes to such contact details.
4.2. Malicious Use of Orphan Glue Records. Registry Operators shall take action to remove orphan
glue records (as defined at http://www.icann.org/en/committees/security/sac048.pdf) when provided with
evidence in written form that such records are present in connection with malicious conduct.
4. Supported Initial and Renewal Registration Periods
4.1. Initial Registration Periods. Initial registrations of registered names may be made in the registry
in one (1) year increments for up to a maximum of ten (10) years.  For the avoidance of doubt, initial
registrations of registered names may not exceed ten (10) years.
 4.2. Renewal Periods. Renewal of registered names may be made in one (1) year increments for up to
a maximum of ten (10) years.  For the avoidance of doubt, renewal of registered names may not extend
their registration period beyond ten (10) years from the time of the renewal.    NEW GTLD AGREEMENT SPECIFICATIONS
SPECIFICATION 7
MINIMUM REQUIREMENTS FOR RIGHTS PROTECTION MECHANISMS
1. Rights Protection Mechanisms. Registry Operator shall implement and adhere
to any rights protection mechanisms (“RPMs”) that may be mandated from time to time by
ICANN.  In addition to such RPMs, Registry Operator may develop and implement additional
RPMs that discourage or prevent registration of domain names that violate or abuse another
party’s legal rights.  Registry Operator will include all ICANN mandated and independently
developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars
authorized to register names in the TLD. Registry Operator shall implement in accordance with
requirements established by ICANN each of the mandatory RPMs set forth in the Trademark
Clearinghouse (posted at [url to be inserted when final Trademark Clearinghouse is adopted]),
which may be revised by ICANN from time to time.  Registry Operator shall not mandate that
any owner of applicable intellectual property rights use any other trademark information
aggregation, notification, or validation service in addition to or instead of the ICANN-designated
Trademark Clearinghouse.
2. Dispute Resolution Mechanisms. Registry Operator will comply with the
following dispute resolution mechanisms as they may be revised from time to time:
a. the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP)
and the Registration Restriction Dispute Resolution Procedure (RRDRP)
adopted by ICANN (posted at [urls to be inserted when final procedure is
adopted]).  Registry Operator agrees to implement and adhere to any
remedies ICANN imposes (which may include any reasonable remedy,
including for the avoidance of doubt, the termination of the Registry
Agreement pursuant to Section 4.3(e) of the Registry Agreement)
following a determination by any PDDRP or RRDRP panel and to be
bound by any such determination; and
b. the Uniform Rapid Suspension system (“URS”) adopted by ICANN
(posted at [url to be inserted]), including the implementation of
determinations issued by URS examiners.     NEW GTLD AGREEMENT SPECIFICATIONS
 
SPECIFICATION 8
CONTINUED OPERATIONS INSTRUMENT
1. The Continued Operations Instrument shall (a) provide for sufficient financial resources
to ensure the continued operation of the critical registry functions related to the TLD set
forth in Section [__] of the Applicant Guidebook posted at [url to be inserted upon
finalization of Applicant Guidebook] (which is hereby incorporated by reference into this
Specification 8) for a period of three (3) years following any termination of this
Agreement on or prior to the fifth anniversary of the Effective Date or for a period of one
(1) year following any termination of this Agreement after the fifth anniversary of the
Effective Date but prior to or on the sixth (6
th
) anniversary of the Effective Date, and (b)
be in the form of either (i) an irrevocable standby letter of credit, or (ii) an irrevocable
cash escrow deposit, each meeting the requirements set forth in Section [__] of the
Applicant Guidebook posted at [url to be inserted upon finalization of Applicant
Guidebook] (which is hereby incorporated by reference into this Specification 8).
Registry Operator shall use its best efforts to take all actions necessary or advisable to
maintain in effect the Continued Operations Instrument for a period of six (6) years from
the Effective Date, and to maintain ICANN as a third party beneficiary thereof.  Registry
Operator shall provide to ICANN copies of all final documents relating to the Continued
Operations Instrument and shall keep ICANN reasonably informed of material
developments relating to the Continued Operations Instrument.  Registry Operator shall
not agree to, or permit, any amendment of, or waiver under, the Continued Operations
Instrument or other documentation relating thereto without the prior written consent of
ICANN (such consent not to be unreasonably withheld).  The Continued Operations
Instrument shall expressly state that ICANN may access the financial resources of the
Continued Operations Instrument pursuant to Section 2.13 or Section 4.5 [insert for
government entity: or Section 7.14] of the Registry Agreement.
2. If, notwithstanding the use of best efforts by Registry Operator to satisfy its obligations
under the preceding paragraph, the Continued Operations Instrument expires or is
terminated by another party thereto, in whole or in part, for any reason, prior to the sixth
anniversary of the Effective Date, Registry Operator shall promptly (i) notify ICANN of
such expiration or termination and the reasons therefor and (ii) arrange for an alternative
instrument that provides for sufficient financial resources to ensure the continued
operation of the Registry Services related to the TLD for a period of three (3) years
following any termination of this Agreement on or prior to the fifth anniversary of the
Effective Date or for a period of one (1) year following any termination of this
Agreement after the fifth anniversary of the Effective Date but prior to or on the sixth (6)
anniversary of the Effective Date (an “Alternative Instrument”).  Any such Alternative
Instrument shall be on terms no less favorable to ICANN than the Continued Operations
Instrument and shall otherwise be in form and substance reasonably acceptable to
ICANN.
3. Notwithstanding anything to the contrary contained in this Specification 8, at any time,
Registry Operator may replace the Continued Operations Instrument with an alternative     NEW GTLD AGREEMENT SPECIFICATIONS
instrument that (i) provides for sufficient financial resources to ensure the continued
operation of the Registry Services related to the TLD for a period of three (3) years
following any termination of this Agreement on or prior to the fifth anniversary of the
Effective Date or for a period one (1) year following any termination of this Agreement
after the fifth anniversary of the Effective Date but prior to or on the sixth (6) anniversary
of the Effective Date, and (ii) contains terms no less favorable to ICANN than the
Continued Operations Instrument and is otherwise in form and substance reasonably
acceptable to ICANN.  In the event Registry Operation replaces the Continued
Operations Instrument either pursuant to paragraph 2 or this paragraph 3, the terms of this
Specification 8 shall no longer apply with respect to the original Continuing Operations
Instrument, but shall thereafter apply with respect to such replacement instrument(s).NEW GTLD AGREEMENT SPECIFICATIONS
 
SPECIFICATION 9
Registry Operator Code of Conduct
1. In connection with the operation of the registry for the TLD, Registry Operator
will not, and will not allow any parent, subsidiary, Affiliate, subcontractor or
other related entity, to the extent such party is engaged in the provision of
Registry Services with respect to the TLD (each, a “Registry Related Party”), to:
a. directly or indirectly show any preference or provide any special consideration
to any registrar with respect to operational access to registry systems and
related registry services, unless comparable opportunities to qualify for such
preferences or considerations are made available to all registrars on
substantially similar terms and subject to substantially similar conditions;
b. register domain names in its own right, except for names registered through an
ICANN accredited registrar that are reasonably necessary for the management,
operations and purpose of the TLD, provided, that Registry Operator may
reserve names from registration pursuant to Section 2.6 of the Registry
Agreement;
c. register names in the TLD or sub-domains of the TLD based upon proprietary
access to information about searches or resolution requests by consumers for
domain names not yet registered (commonly known as, "front-running");
d. allow any Affiliated registrar to disclose user data to Registry Operator or any
Registry Related Party, except as necessary for the management and
operations of the TLD, unless all unrelated third parties (including other
registry operators) are given equivalent access to such user data on
substantially similar terms and subject to substantially similar conditions; or
e. disclose confidential registry data or confidential information about its
Registry Services or operations to any employee of any DNS services
provider, except as necessary for the management and operations of the TLD,
unless all unrelated third parties (including other registry operators) are given
equivalent access to such confidential registry data or confidential information
on substantially similar terms and subject to substantially similar conditions.
2. If Registry Operator or a Registry Related Party also operates as a provider of
registrar or registrar-reseller services, Registry Operator will, or will cause such
Registry Related Party to, maintain separate books of accounts with respect to its
registrar or registrar-reseller operations.
3. Registry Operator will conduct internal reviews at least once per calendar year to
ensure compliance with this Code of Conduct. Within twenty (20) calendar days NEW GTLD AGREEMENT SPECIFICATIONS
 
following the end of each calendar year, Registry Operator will provide the results
of the internal review, along with a certification executed by an executive officer
of Registry Operator certifying as to Registry Operator’s compliance with this
Code of Conduct, via email to an address to be provided by ICANN. (ICANN
may specify in the future the form and contents of such reports or that the reports
be delivered by other reasonable means.)  Registry Operator agrees that ICANN
may publicly post such results and certification.
4. Nothing set forth herein shall: (i) limit ICANN from conducting investigations of
claims of Registry Operator’s non-compliance with this Code of Conduct; or (ii)
provide grounds for Registry Operator to refuse to cooperate with ICANN
investigations of claims of Registry Operator’s non-compliance with this Code of
Conduct.
5. Nothing set forth herein shall limit the ability of Registry Operator or any
Registry Related Party, to enter into arms-length transactions in the ordinary
course of business with a registrar or reseller with respect to products and services
unrelated in all respects to the TLD.
6. Registry Operator may request an exemption to this Code of Conduct, and such
exemption may be granted by ICANN in ICANN’s reasonable discretion, if
Registry Operator demonstrates to ICANN’s reasonable satisfaction that (i) all
domain name registrations in the TLD are registered to, and maintained by,
Registry Operator for its own exclusive use, (ii) Registry Operator does not sell,
distribute or transfer control or use of any registrations in the TLD to any third
party that is not an Affiliate of Registry Operator, and (iii) application of this
Code of Conduct to the TLD is not necessary to protect the public interest.     NEW GTLD AGREEMENT SPECIFICATIONS
SPECIFICATION 10
REGISTRY PERFORMANCE SPECIFICATIONS
1. Definitions
1.1. DNS. Refers to the Domain Name System as specified in RFCs 1034, 1035, and related RFCs.
1.2. DNSSEC proper resolution. There is a valid DNSSEC chain of trust from the root trust anchor
to a particular domain name, e.g., a TLD, a domain name registered under a TLD, etc.
1.3.EPP. Refers to the Extensible Provisioning Protocol as specified in RFC 5730 and related RFCs.
1.4. IP address. Refers to IPv4 or IPv6 addresses without making any distinction between the two.
When there is need to make a distinction, IPv4 or IPv6 is used.
1.5. Probes. Network hosts used to perform (DNS, EPP, etc.) tests (see below) that are located at
various global locations.
1.6. RDDS. Registration Data Directory Services refers to the collective of WHOIS and Web-based
WHOIS services as defined in Specification 4 of this Agreement.
1.7. RTT. Round-Trip Time or RTT refers to the time measured from the sending of the first bit of
the first packet of the sequence of packets needed to make a request until the reception of the last
bit of the last packet of the sequence needed to receive the response. If the client does not receive
the whole sequence of packets needed to consider the response as received, the request will be
considered unanswered.
1.8. SLR. Service Level Requirement is the level of service expected for a certain parameter being
measured in a Service Level Agreement (SLA).
2. Service Level Agreement Matrix
Parameter SLR (monthly basis)
DNS
DNS service availability 0 min downtime = 100% availability
DNS name server availability  432 min of downtime ( 99%)
TCP DNS resolution RTT  1500 ms, for at least 95% of the queries
UDP DNS resolution RTT  500 ms, for at least 95% of the queries
DNS update time  60 min, for at least 95% of the probes
RDDS
RDDS availability  864 min of downtime ( 98%)
RDDS query RTT  2000 ms, for at least 95% of the queries
RDDS update time  60 min, for at least 95% of the probes
EPP
EPP service availability  864 min of downtime ( 98%)
EPP session-command RTT  4000 ms, for at least 90% of the commands
EPP query-command RTT  2000 ms, for at least 90% of the commands
EPP transform-command RTT  4000 ms, for at least 90% of the commands    NEW GTLD AGREEMENT SPECIFICATIONS
 
Registry Operator is encouraged to do maintenance for the different services at the times and dates of
statistically lower traffic for each service. However, note that there is no provision for planned outages or
similar; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime
and counted for SLA purposes.
3. DNS
3.1. DNS service availability. Refers to the ability of the group of listed-as-authoritative name
servers of a particular domain name (e.g., a TLD), to answer DNS queries from DNS probes. For
the service to be considered available at a particular moment, at least, two of the delegated name
servers registered in the DNS must have successful results from “DNS tests” to each of their
public-DNS registered “IP addresses” to which the name server resolves. If 51% or more of the
DNS testing probes see the service as unavailable during a given time, the DNS service will be
considered unavailable.
3.2. DNS name server availability. Refers to the ability of a public-DNS registered “IP address” of
a particular name server listed as authoritative for a domain name, to answer DNS queries from
an Internet user. All the public DNS-registered “IP address” of all name servers of the domain
name being monitored shall be tested individually. If 51% or more of the DNS testing probes get
undefined/unanswered results from “DNS tests” to a name server “IP address” during a given
time, the name server “IP address” will be considered unavailable.
3.3. UDP DNS resolution RTT. Refers to the RTT of the sequence of two packets, the UDP DNS
query and the corresponding UDP DNS response. If the RTT is 5 times greater than the time
specified in the relevant SLR, the RTT will be considered undefined.
3.4.TCP DNS resolution RTT. Refers to the RTT of the sequence of packets from the start of the
TCP connection to its end, including the reception of the DNS response for only one DNS query.
If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be
considered undefined.
3.5. DNS resolution RTT. Refers to either “UDP DNS resolution RTT” or “TCP DNS resolution
RTT”.
3.6. DNS update time. Refers to the time measured from the reception of an EPP confirmation to a
transform command on a domain name, until the name servers of the parent domain name
answer “DNS queries” with data consistent with the change made. This only applies for changes
to DNS information.
3.7. DNS test. Means one non-recursive DNS query sent to a particular “IP address” (via UDP or
TCP). If DNSSEC is offered in the queried DNS zone, for a query to be considered answered,
the signatures must be positively verified against a corresponding DS record published in the
parent zone or, if the parent is not signed, against a statically configured Trust Anchor. The
answer to the query must contain the corresponding information from the Registry System,
otherwise the query will be considered unanswered. A query with a “DNS resolution RTT” 5
times higher than the corresponding SLR, will be considered unanswered. The possible results to
a DNS test are: a number in milliseconds corresponding to the “DNS resolution RTT” or,
undefined/unanswered.
3.8.Measuring DNS parameters. Every minute, every DNS probe will make an UDP or TCP “DNS
test” to each of the public-DNS registered “IP addresses” of the name servers of the domain     NEW GTLD AGREEMENT SPECIFICATIONS
 
name being monitored. If a “DNS test” result is undefined/unanswered, the tested IP will be
considered unavailable from that probe until it is time to make a new test.
3.9. Collating the results from DNS probes. The minimum number of active testing probes to
consider a measurement valid is 20 at any given measurement period, otherwise the
measurements will be discarded and will be considered inconclusive; during this situation no
fault will be flagged against the SLRs.
3.10. Distribution of UDP and TCP queries. DNS probes will send UDP or TCP “DNS test”
approximating the distribution of these queries.
3.11. Placement of DNS probes. Probes for measuring DNS parameters shall be placed as
near as possible to the DNS resolvers on the networks with the most users across the different
geographic regions; care shall be taken not to deploy probes behind high propagation-delay
links, such as satellite links.
4. RDDS
4.1. RDDS availability. Refers to the ability of all the RDDS services for the TLD, to respond to
queries from an Internet user with appropriate data from the relevant Registry System. If 51% or
more of the RDDS testing probes see any of the RDDS services as unavailable during a given
time, the RDDS will be considered unavailable.
4.2.WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP
connection to its end, including the reception of the WHOIS response. If the RTT is 5-times or
more the corresponding SLR, the RTT will be considered undefined.
4.3.Web-based-WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of
the TCP connection to its end, including the reception of the HTTP response for only one HTTP
request. If Registry Operator implements a multiple-step process to get to the information, only
the last step shall be measured. If the RTT is 5-times or more the corresponding SLR, the RTT
will be considered undefined.
4.4. RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web-basedWHOIS query RTT”.
4.5. RDDS update time. Refers to the time measured from the reception of an EPP confirmation to a
transform command on a domain name, host or contact, up until the servers of the RDDS
services reflect the changes made.
4.6. RDDS test. Means one query sent to a particular “IP address” of one of the servers of one of the
RDDS services. Queries shall be about existing objects in the Registry System and the responses
must contain the corresponding information otherwise the query will be considered unanswered.
Queries with an RTT 5 times higher than the corresponding SLR will be considered as
unanswered. The possible results to an RDDS test are: a number in milliseconds corresponding
to the RTT or undefined/unanswered.
4.7.Measuring RDDS parameters. Every 5 minutes, RDDS probes will select one IP address from
all the public-DNS registered “IP addresses” of the servers for each RDDS service of the TLD
being monitored and make an “RDDS test” to each one. If an “RDDS test” result is     NEW GTLD AGREEMENT SPECIFICATIONS
undefined/unanswered, the corresponding RDDS service will be considered as unavailable from
that probe until it is time to make a new test.
4.8. Collating the results from RDDS probes. The minimum number of active testing probes to
consider a measurement valid is 10 at any given measurement period, otherwise the
measurements will be discarded and will be considered inconclusive; during this situation no
fault will be flagged against the SLRs.
4.9. Placement of RDDS probes. Probes for measuring RDDS parameters shall be placed inside the
networks with the most users across the different geographic regions; care shall be taken not to
deploy probes behind high propagation-delay links, such as satellite links.
5. EPP
5.1.EPP service availability. Refers to the ability of the TLD EPP servers as a group, to respond to
commands from the Registry accredited Registrars, who already have credentials to the servers.
The response shall include appropriate data from the Registry System. An EPP command with
“EPP command RTT” 5 times higher than the corresponding SLR will be considered as
unanswered. If 51% or more of the EPP testing probes see the EPP service as unavailable during
a given time, the EPP service will be considered unavailable.
5.2.EPP session-command RTT. Refers to the RTT of the sequence of packets that includes the
sending of a session command plus the reception of the EPP response for only one EPP session
command. For the login command it will include packets needed for starting the TCP session.
For the logout command it will include packets needed for closing the TCP session. EPP session
commands are those described in section 2.9.1 of EPP RFC 5730. If the RTT is 5 times or more
the corresponding SLR, the RTT will be considered undefined.
5.3.EPP query-command RTT. Refers to the RTT of the sequence of packets that includes the
sending of a query command plus the reception of the EPP response for only one EPP query
command. It does not include packets needed for the start or close of either the EPP or the TCP
session. EPP query commands are those described in section 2.9.2 of EPP RFC 5730. If the RTT
is 5-times or more the corresponding SLR, the RTT will be considered undefined.
5.4.EPP transform-command RTT. Refers to the RTT of the sequence of packets that includes the
sending of a transform command plus the reception of the EPP response for only one EPP
transform command. It does not include packets needed for the start or close of either the EPP or
the TCP session. EPP transform commands are those described in section 2.9.3 of EPP RFC
5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered
undefined.
5.5.EPP command RTT. Refers to “EPP session-command RTT”, “EPP query-command RTT”
or “EPP transform-command RTT”.
5.6.EPP test. Means one EPP command sent to a particular “IP address” for one of the EPP servers.
Query and transform commands, with the exception of “create”, shall be about existing objects
in the Registry System. The response shall include appropriate data from the Registry System.
The possible results to an EPP test are: a number in milliseconds corresponding to the “EPP
command RTT” or undefined/unanswered.     NEW GTLD AGREEMENT SPECIFICATIONS
 
5.7.Measuring EPP parameters. Every 5 minutes, EPP probes will select one “IP address“ of the
EPP servers of the TLD being monitored and make an “EPP test”; every time they should
alternate between the 3 different types of commands and between the commands inside each
category. If an “EPP test” result is undefined/unanswered, the EPP service will be considered as
unavailable from that probe until it is time to make a new test.
5.8. Collating the results from EPP probes. The minimum number of active testing probes to
consider a measurement valid is 5 at any given measurement period, otherwise the measurements
will be discarded and will be considered inconclusive; during this situation no fault will be
flagged against the SLRs.
5.9. Placement of EPP probes. Probes for measuring EPP parameters shall be placed inside or close
to Registrars points of access to the Internet across the different geographic regions; care shall be
taken not to deploy probes behind high propagation-delay links, such as satellite links.
6. Emergency Thresholds
The following matrix presents the Emergency Thresholds that, if reached by any of the services
mentioned above for a TLD, would cause the Emergency Transition of the Critical Functions as specified
in Section 2.13. of this Agreement.
Critical Function Emergency Threshold
DNS service (all servers) 4-hour downtime / week
DNSSEC proper resolution 4-hour downtime / week
EPP 24-hour downtime / week
RDDS (WHOIS/Web-based
WHOIS)
24-hour downtime / week
Data Escrow Breach of the Registry Agreement caused by missing escrow
deposits as described in Specification 2, Part B, Section 6.
7. Emergency Escalation
Escalation is strictly for purposes of notifying and investigating possible or potential issues in relation to
monitored services. The initiation of any escalation and the subsequent cooperative investigations do not
in themselves imply that a monitored service has failed its performance requirements.
Escalations shall be carried out between ICANN and Registry Operators, Registrars and Registry
Operator, and Registrars and ICANN. Registry Operators and ICANN must provide said emergency
operations departments. Current contacts must be maintained between ICANN and Registry Operators
and published to Registrars, where relevant to their role in escalations, prior to any processing of an
Emergency Escalation by all related parties, and kept current at all times.
7.1.Emergency Escalation initiated by ICANN
Upon reaching 10% of the Emergency thresholds as described in Section 6, ICANN’s emergency
operations will initiate an Emergency Escalation with the relevant Registry Operator. An Emergency
Escalation consists of the following minimum elements: electronic (i.e., email or SMS) and/or voice
contact notification to the Registry Operator’s emergency operations department with detailed
information concerning the issue being escalated, including evidence of monitoring failures, cooperative
trouble-shooting of the monitoring failure between ICANN staff and the Registry Operator, and the     NEW GTLD AGREEMENT SPECIFICATIONS
commitment to begin the process of rectifying issues with either the monitoring service or the service
being monitoring.
7.2.Emergency Escalation initiated by Registrars
Registry Operator will maintain an emergency operations departments prepared to handle emergency
requests from registrars. In the event that a registrar is unable to conduct EPP transactions with the
Registry because of a fault with the Registry Service and is unable to either contact (through ICANN
mandated methods of communication) the Registry Operator, or the Registry Operator is unable or
unwilling to address the fault, the registrar may initiate an Emergency Escalation to the emergency
operations department of ICANN.  ICANN then may initiate an Emergency Escalation with the Registry
Operator as explained above.
7.3. Notifications of Outages and Maintenance
In the event that a Registry Operator plans maintenance, they will provide related notice to the ICANN
emergency operations department, at least, 24 hours ahead of that maintenance.  ICANN’s emergency
operations department will note planned maintenance times, and suspend Emergency Escalation services
for the monitored services during the expected maintenance outage period.
If Registry Operator declares an outage, as per their contractual obligations with ICANN, on services
under SLA and performance requirements, it will notify the ICANN emergency operations department.
During that declared outage, ICANN’s emergency operations department will note and suspend
Emergency Escalation services for the monitored services involved.
8. Covenants of Performance Measurement
8.1. No interference. Registry Operator shall not interfere with measurement Probes, including any
form of preferential treatment of the requests for the monitored services. Registry Operator shall
respond to the measurement tests described in this Specification as it would do with any other
request from Internet users (for DNS and RDDS) or registrars (for EPP).
8.2. ICANN testing registrar. Registry Operator agrees that ICANN will have a testing registrar used
for purposes of measuring the SLRs described above. Registry Operator agrees to not provide
any differentiated treatment for the testing registrar other than no billing of the transactions.
ICANN shall not use the registrar for registering domain names (or other registry objects) for
itself or others, except for the purposes of verifying contractual compliance with the conditions
described in this Agreement.TRADEMARK CLEARINGHOUSE
         19 SEPTEMBER 2011
1. PURPOSE OF CLEARINGHOUSE
1.1 The Trademark Clearinghouse is a central repository for information to be
authenticated, stored, and disseminated, pertaining to the rights of trademark holders.
ICANN will enter into an arms-length contract with service provider or providers,
awarding the right to serve as a Trademark Clearinghouse Service Provider, i.e., to
accept, authenticate, validate and facilitate the transmission of information related to
certain trademarks.
1.2 The Clearinghouse will be required to separate its two primary functions:  (i)
authentication and validation of the trademarks in the Clearinghouse; and (ii) serving as
a database to provide information to the new gTLD registries to support pre-launch
Sunrise or Trademark Claims Services.  Whether the same provider could serve both
functions or whether two providers will be determined in the tender process.  
1.3 The Registry shall only need to connect with one centralized database to obtain the
information it needs to conduct its Sunrise or Trademark Claims Services regardless of
the details of the Trademark Clearinghouse Service Provider’s contract(s) with ICANN.
1.4 Trademark Clearinghouse Service Provider may provide ancillary services, as long as
those services and any data used for those services are kept separate from the
Clearinghouse database.
1.5 The Clearinghouse database will be a repository of authenticated information and
disseminator of the information to a limited number of recipients.  Its functions will be
performed in accordance with a limited charter, and will not have any discretionary
powers other than what will be set out in the charter with respect to authentication and
validation.  The Clearinghouse administrator(s) cannot create policy.  Before material
changes are made to the Clearinghouse functions, they will be reviewed through the
ICANN public participation model.
1.6 Inclusion in the Clearinghouse is not proof of any right, nor does it create any legal
rights.  Failure to submit trademarks into the Clearinghouse should not be perceived to
be lack of vigilance by trademark holders or a waiver of any rights, nor can any negative
influence be drawn from such failure.  
2. SERVICE PROVIDERS
2.1 The selection of Trademark Clearinghouse Service Provider(s) will be subject to
predetermined criteria, but the foremost considerations will be the ability to store,
authenticate, validate and disseminate the data at the highest level of technical stability - 2 -
and security without interference with the integrity or timeliness of the registration
process or registry operations.
2.2 Functions – Authentication/Validation; Database Administration.  Public commentary
has suggested that the best way to protect the integrity of the data and to avoid
concerns that arise through sole-source providers would be to separate the functions of
database administration and data authentication/validation.  
2.2.1 One entity will authenticate registrations ensuring the word marks qualify as
registered or are court-validated word marks or word marks that are protected
by statute or treaty.  This entity would also be asked to ensure that proof of use
of marks is provided, which can be demonstrated by furnishing a signed
declaration and one specimen of current use.  
2.2.2  The second entity will maintain the database and provide Sunrise and
Trademark Claims Services (described below).  
2.3 Discretion will be used, balancing effectiveness, security and other important factors, to
determine whether ICANN will contract with one or two entities - one to authenticate
and validate, and the other to, administer in order to preserve integrity of the data.
2.4 Contractual Relationship.  
2.4.1 The Clearinghouse shall be separate and independent from ICANN.  It will
operate based on market needs and collect fees from those who use its
services.  ICANN may coordinate or specify interfaces used by registries and
registrars, and provide some oversight or quality assurance function to ensure
rights protection goals are appropriately met.
2.4.2 The Trademark Clearinghouse Service Provider(s) (authenticator/validator and
administrator) will be selected through an open and transparent process to
ensure low costs and reliable, consistent service for all those utilizing the
Clearinghouse services.
2.4.3 The Service Provider(s) providing the authentication of the trademarks
submitted into the Clearinghouse shall adhere to rigorous standards and
requirements that would be specified in an ICANN contractual agreement.
2.4.4 The contract shall include service level requirements, customer service
availability (with the goal of seven days per week, 24 hours per day, 365 days
per year), data escrow requirements, and equal access requirements for all
persons and entities required to access the Trademark Clearinghouse database.   - 3 -
2.4.5 To the extent practicable, the contract should also include indemnification by
Service Provider for errors such as false positives for participants such as
Registries, ICANN, Registrants and Registrars.
2.5. Service Provider Requirements.  The Clearinghouse Service Provider(s) should utilize
regional marks authentication service providers (whether directly or through subcontractors) to take advantage of local experts who understand the nuances of the
trademark in question.  Examples of specific performance criteria details in the contract
award criteria and service-level-agreements are:
2.5.1 provide 24 hour accessibility seven days a week (database administrator);
2.5.2 employ systems that are technically reliable and secure (database
administrator);
2.5.3 use globally accessible and scalable systems so that multiple marks from
multiple sources in multiple languages can be accommodated and sufficiently
cataloged (database administrator and validator);
2.5.4 accept submissions from all over the world - the entry point for trademark
holders to submit their data into the Clearinghouse database could be regional
entities or one entity;
2.5.5 allow for multiple languages, with exact implementation details to be
determined;
2.5.6 provide access to the Registrants to verify and research Trademark Claims
Notices;
2.5.7 have the relevant experience in database administration, validation or
authentication, as well as accessibility to and knowledge of the various relevant
trademark laws (database administrator and authenticator); and
2.5.8 ensure through performance requirements, including those involving interface
with registries and registrars, that neither domain name registration timeliness,
nor registry or registrar operations will be hindered (database administrator).
3. CRITERIA FOR TRADEMARK INCLUSION IN CLEARINGHOUSE
3.1 The trademark holder will submit to one entity – a single entity for entry will facilitate
access to the entire Clearinghouse database.  If regional entry points are used, ICANN
will publish an information page describing how to locate regional submission points.
Regardless of the entry point into the Clearinghouse, the authentication procedures
established will be uniform.
3.2 The standards for inclusion in the Clearinghouse are:
3.2.1 Nationally or regionally registered word marks from all jurisdictions.
3.2.2 Any word mark that has been validated through a court of law or other judicial
proceeding. - 4 -
3.2.3 Any word mark protected by a statute or treaty in effect at the time the mark is
submitted to the Clearinghouse for inclusion.
3.2.4 Other marks that constitute intellectual property.
3.2.5 Protections afforded to trademark registrations do not extend to applications
for registrations, marks within any opposition period or registered marks that
were the subject of successful invalidation, cancellation or rectification
proceedings.
3.3 The type of data supporting entry of a registered word mark into the Clearinghouse
must include a copy of the registration or the relevant ownership information, including
the requisite registration number(s), the jurisdictions where the registrations have
issued, and the name of the owner of record.  
3.4 Data supporting entry of a judicially validated word mark into the Clearinghouse must
include the court documents, properly entered by the court, evidencing the validation of
a given word mark.  
3.5 Data supporting entry into the Clearinghouse of word marks protected by a statute or
treaty in effect at the time the mark is submitted to the Clearinghouse for inclusion,
must include a copy of the relevant portion of the statute or treaty and evidence of its
effective date.
3.6 Data supporting entry into the Clearinghouse of marks that constitute intellectual
property of types other than those set forth in sections 3.2.1-3.2.3 above shall be
determined by the registry operator and the Clearinghouse based on the services any
given registry operator chooses to provide.
3.7  Registrations that include top level extensions such as “icann.org” or “.icann” as the
word mark will not be permitted in the Clearinghouse regardless of whether that mark
has been registered or it has been otherwise validated or protected (e.g., if a mark
existed for icann.org or .icann, neither will not be permitted in the Clearinghouse).
3.8 All mark holders seeking to have their marks included in the Clearinghouse will be
required to submit a declaration, affidavit, or other sworn statement that the
information provided is true and current and has not been supplied for an improper
purpose.  The mark holder will also be required to attest that it will keep the
information supplied to the Clearinghouse current so that if, during the time the mark is
included in the Clearinghouse, a registration gets cancelled or is transferred to another
entity, or in the case of a court- or Clearinghouse-validated mark the holder abandons
use of the mark, the mark holder has an affirmative obligation to notify the
Clearinghouse.  There will be penalties for failing to keep information current.
Moreover, it is anticipated that there will be a process whereby registrations can be - 5 -
removed from the Clearinghouse if it is discovered that the marks are procured by fraud
or if the data is inaccurate.
3.9 As an additional safeguard, the data will have to be renewed periodically by any mark
holder wishing to remain in the Clearinghouse.  Electronic submission should facilitate
this process and minimize the cost associated with it.  The reason for periodic
authentication is to streamline the efficiencies of the Clearinghouse and the information
the registry operators will need to process and limit the marks at issue to the ones that
are in use.
4. USE OF CLEARINGHOUSE DATA
4.1 All mark holders seeking to have their marks included in the Clearinghouse will have to
consent to the use of their information by the Clearinghouse.  However, such consent
would extend only to use in connection with the stated purpose of the Trademark
Clearinghouse Database for Sunrise or Trademark Claims services.  The reason for such a
provision would be to presently prevent the Clearinghouse from using the data in other
ways without permission.  There shall be no bar on the Trademark Clearinghouse
Service Provider or other third party service providers providing ancillary services on a
non-exclusive basis.
4.2 In order not to create a competitive advantage, the data in the Trademark
Clearinghouse should be licensed to competitors interested in providing ancillary
services on equal and non-discriminatory terms and on commercially reasonable terms
if the mark holders agree.  Accordingly, two licensing options will be offered to the mark
holder:  (a) a license to use its data for all required features of the Trademark
Clearinghouse, with no permitted use of such data for ancillary services either by the
Trademark Clearinghouse Service Provider or any other entity; or (b) license to use its
data for the mandatory features of the Trademark Clearinghouse and for any ancillary
uses reasonably related to the protection of marks in new gTLDs, which would include a
license to allow the Clearinghouse to license the use and data in the Trademark
Clearinghouse to competitors that also provide those ancillary services.  The specific
implementation details will be determined, and all terms and conditions related to the
provision of such services shall be included in the Trademark Clearinghouse Service
Provider’s contract with ICANN and subject to ICANN review.
4.3 Access by a prospective registrant to verify and research Trademark Claims Notices shall
not be considered an ancillary service, and shall be provided at no cost to the Registrant.
Misuse of the data by the service providers would be grounds for immediate
termination. - 6 -
5. DATA AUTHENTICATION AND VALIDATION GUIDELINES
5.1 One core function for inclusion in the Clearinghouse would be to authenticate that the
data meets certain minimum criteria.  As such, the following minimum criteria are
suggested:
5.1.1 An acceptable list of data authentication sources, i.e. the web sites of patent
and trademark offices throughout the world, third party providers who can
obtain information from various trademark offices;
5.1.2 Name, address and contact information of the applicant is accurate, current and
matches that of the registered owner of the trademarks listed;
5.1.3 Electronic contact information is provided and accurate;
5.1.4 The registration numbers and countries match the information in the respective
trademark office database for that registration number.
5.2 For validation of marks by the Clearinghouse that were not protected via a court,
statute or treaty, the mark holder shall be required to provide evidence of use of the
mark in connection with the bona fide offering for sale of goods or services prior to
application for inclusion in the Clearinghouse.  Acceptable evidence of use will be a
signed declaration and a single specimen of current use, which might consist of labels,
tags, containers, advertising, brochures, screen shots, or something else that evidences
current use.
6. MANDATORY RIGHTS PROTECTION MECHANISMS
All new gTLD registries will be required to use the Trademark Clearinghouse to support its prelaunch or initial launch period rights protection mechanisms (RPMs).  These RPMs, at a
minimum, must consist of a Trademark Claims service and a Sunrise process.  
6.1 Trademark Claims service
6.1.1 New gTLD Registry Operators must provide Trademark Claims services during an
initial launch period for marks in the Trademark Clearinghouse.  This launch
period must occur for at least the first 60 days that registration is open for
general registration.
6.1.2 A Trademark Claims service is intended to provide clear notice to the
prospective registrant of the scope of the mark holder’s rights in order to
minimize the chilling effect on registrants (Trademark Claims Notice).  A form
that describes the required elements is attached.  The specific statement by - 7 -
prospective registrant warrants that:  (i) the prospective registrant has received
notification that the mark(s) is included in the Clearinghouse; (ii) the prospective
registrant has received and understood the notice; and (iii) to the best of the
prospective registrant’s knowledge, the registration and use of the requested
domain name will not infringe on the rights that are the subject of the
notice.
6.1.3 The Trademark Claims Notice should provide the prospective registrant access
to the Trademark Clearinghouse Database information referenced in the
Trademark Claims Notice to enhance understanding of the Trademark rights
being claimed by the trademark holder.  These links (or other sources) shall be
provided in real time without cost to the prospective registrant.  Preferably, the
Trademark Claims Notice should be provided in the language used for the rest
of the interaction with the registrar or registry, but it is anticipated that at the
very least in the most appropriate UN-sponsored language (as specified by the
prospective registrant or registrar/registry).  
6.1.4 If the domain name is registered in the Clearinghouse, the registrar (again
through an interface with the Clearinghouse) will promptly notify the mark
holders(s) of the registration after it is effectuated.
6.1.5 The Trademark Clearinghouse Database will be structured to report to registries
when registrants are attempting to register a domain name that is considered
an “Identical Match” with the mark in the Clearinghouse.  “Identical Match”
means that the domain name consists of the complete and identical textual
elements of the mark.  In this regard: (a) spaces contained within a mark that
are either replaced by hyphens (and vice versa) or omitted; (b) only certain
special characters contained within a trademark are spelled out with
appropriate words describing it (@ and &); (c) punctuation or special characters
contained within a mark that are unable to be used in a second-level domain
name may either be (i) omitted or (ii) replaced by spaces, hyphens or
underscores and still be considered identical matches; and (d) no plural and no
“marks contained” would qualify for inclusion. - 8 -
6.2 Sunrise service
6.2.1 Sunrise registration services must be offered for a minimum of 30 days during
the pre-launch phase and notice must be provided to all trademark holders in
the Clearinghouse if someone is seeking a sunrise registration.  This notice will
be provided to holders of marks in the Clearinghouse that are an Identical
Match to the name to be registered during Sunrise.
6.2.2 Sunrise Registration Process.  For a Sunrise service, sunrise eligibility
requirements (SERs) will be met as a minimum requirement, verified by
Clearinghouse data, and incorporate a Sunrise Dispute Resolution Policy (SDRP).
6.2.3 The proposed SERs include:  (i) ownership of a mark (that satisfies the criteria in
section 7.2 below), (ii) optional registry elected requirements re: international
class of goods or services covered by registration; (iii) representation that all
provided information is true and correct; and (iv) provision of data sufficient to
document rights in the trademark.
6.2.4 The proposed SDRP must allow challenges based on at least the following four
grounds:  (i) at time the challenged domain name was registered, the registrant
did not hold a trademark registration of national effect (or regional effect) or
the trademark had not been court-validated or protected by statute or treaty;
(ii) the domain name is not identical to the mark on which the registrant based
its Sunrise registration; (iii) the trademark registration on which the registrant
based its Sunrise registration is not of national effect (or regional effect) or the
trademark had not been court-validated or protected by statute or treaty; or (iv)
the trademark registration on which the domain name registrant based its
Sunrise registration did not issue on or before the effective date of the Registry
Agreement and was not applied for on or before ICANN announced the
applications received.
6.2.5 The Clearinghouse will maintain the SERs, validate and authenticate marks, as
applicable, and hear challenges.
7. PROTECTION FOR MARKS IN CLEARINGHOUSE
The scope of registered marks that must be honored by registries in providing Trademarks
Claims services is broader than those that must be honored by registries in Sunrise services.
7.1 For Trademark Claims services - Registries must recognize and honor all word marks that
have been or are:  (i) nationally or regionally registered; (ii) court-validated; or (iii) - 9 -
specifically protected by a statute or treaty in effect at the time the mark is submitted to
the Clearinghouse for inclusion.  No demonstration of use is required.
7.2 For Sunrise services - Registries must recognize and honor all word marks:  (i) nationally
or regionally registered and for which proof of use – which can be a declaration and a
single specimen of current use – was submitted to, and validated by, the Trademark
Clearinghouse; or (ii) that have been court-validated; or (iii) that are specifically
protected by a statute or treaty currently in effect and that was in effect on or before 26
June 2008.
8. COSTS OF CLEARINGHOUSE
Costs should be completely borne by the parties utilizing the services.  Trademark holders will pay to
register the Clearinghouse, and registries will pay for Trademark Claims and Sunrise services.  Registrars
and others who avail themselves of Clearinghouse services will pay the Clearinghouse directly.- 10 -
TRADEMARK NOTICE
[In English and the language of the registration agreement]
You have received this Trademark Notice because you have applied for a domain name
which matches at least one trademark record submitted to the Trademark Clearinghouse.
You may or may not be entitled to register the domain name depending on your intended
use and whether it is the same or significantly overlaps with the trademarks listed below.
Your rights to register this domain name may or may not be protected as noncommercial
use or “fair use” by the laws of your country. [in bold italics or all caps]
Please read the trademark information below carefully, including the trademarks,
jurisdictions, and goods and service for which the trademarks are registered. Please be
aware that not all jurisdictions review trademark applications closely, so some of the
trademark information below may exist in a national or regional registry which does not
conduct a thorough or substantive review of trademark rights prior to registration.
If you have questions, you may want to consult an attorney or legal expert on
trademarks and intellectual property for guidance.
If you continue with this registration, you represent that, you have received and you
understand this notice and to the best of your knowledge, your registration and use of the
requested domain name will not infringe on the trademark rights listed below.
The following [number] Trademarks are listed in the Trademark Clearinghouse:
1. Mark: Jurisdiction: Goods: [click here for more if maximum character count is exceeded]
International Class of Goods and Services or Equivalent if applicable: Trademark
Registrant: Trademark Registrant Contact:
[with links to the TM registrations as listed in the TM Clearinghouse]
2. Mark: Jurisdiction: Goods: [click here for more if maximum character count is exceeded]
International Class of Goods and Services or Equivalent if applicable: Trademark
Registrant:
Trademark Registrant Contact:
****** [with links to the TM registrations as listed in the TM Clearinghouse]
X. 1. Mark: Jurisdiction: Goods: [click here for more if maximum character count is
exceeded] International Class of Goods and Services or Equivalent if applicable: Trademark
Registrant: Trademark Registrant Contact: UNIFORM RAPID SUSPENSION SYSTEM (“URS”)
19 SEPTEMBER 2011
DRAFT PROCEDURE
1. Complaint
1.1 Filing the Complaint
a)   Proceedings are initiated by electronically filing with a URS Provider a Complaint
outlining the trademark rights and the actions complained of entitling the
trademark holder to relief.
b)   Each Complaint must be accompanied by the appropriate fee, which is under
consideration. The fees will be non-refundable.
c)    One Complaint is acceptable for multiple related companies against one Registrant,
but only if the companies complaining are related. Multiple Registrants can be
named in one Complaint only if it can be shown that they are in some way related.
There will not be a minimum number of domain names imposed as a prerequisite to
filing.
1.2 Contents of the Complaint
The form of the Complaint will be simple and as formulaic as possible. There will be a
Form Complaint. The Form Complaint shall include space for the following:
1.2.1 Name, email address and other contact information for the Complaining Party
(Parties).
1.2.2 Name, email address and contact information for any person authorized to act
on behalf of Complaining Parties.
1.2.3 Name of Registrant (i.e. relevant information available from Whois) and Whois
listed available contact information for the relevant domain name(s).
1.2.4 The specific domain name(s) that are the subject of the Complaint. For each
domain name, the Complainant shall include a copy of the currently available
Whois information and a description and copy, if available, of the offending
portion of the website content associated with each domain name that is the
subject of the Complaint.
1.2.5 The specific trademark/service marks upon which the Complaint is based and
pursuant to which the Complaining Parties are asserting their rights to them, for
which goods and in connection with what services.
1.2.6 A statement of the grounds upon which the Complaint is based setting forth
facts showing that the Complaining Party is entitled to relief, namely:URS-2
1.2.6.1. that the registered domain name is identical or confusingly similar to a
word mark: (i) for which the Complainant holds a valid national or
regional registration and that is in current use; or (ii) that has been
validated through court proceedings; or (iii) that is specifically protected
by a statute or treaty in effect at the time the URS complaint is filed.
a.    Use can be shown by demonstrating that evidence of use – which
can be a declaration and one specimen of current use in commerce
- was submitted to, and validated by, the Trademark Clearinghouse)
b.   Proof of use may also be submitted directly with the URS Complaint.
and
1.2.6.2. that the Registrant has no legitimate right or interest to the domain
name; and
1.2.6.3. that the domain was registered and is being used in bad faith.
A non-exclusive list of circumstances that demonstrate bad faith registration
and use by the Registrant include:
a. Registrant has registered or acquired the domain name
primarily for the purpose of selling, renting or otherwise
transferring the domain name registration to the complainant
who is the owner of the trademark or service mark or to a
competitor of that complainant, for valuable consideration in
excess of documented out-of pocket costs directly related to
the domain name; or
b. Registrant has registered the domain name in order to prevent
the trademark holder or service mark from reflecting the mark
in a corresponding domain name, provided that Registrant has
engaged in a pattern of such conduct; or
c. Registrant registered the domain name primarily for the
purpose of disrupting the business of a competitor; or
d. By using the domain name Registrant has intentionally
attempted to attract for commercial gain, Internet users to
Registrant’s web site or other on-line location, by creating a
likelihood of confusion with the complainant’s mark as to the
source, sponsorship, affiliation, or endorsement of Registrant’s
web site or location or of a product or service on that web site
or location.URS-3
1.2.7 A box in which the Complainant may submit up to 500 words of explanatory
free form text.
1.2.8. An attestation that the Complaint is not being filed for any improper basis and
that there is a sufficient good faith basis for filing the Complaint.
2. Fees
2.1 URS Provider will charge fees to the Complainant. Fees are thought to be in the range of
USD 300 per proceeding, but will ultimately be set by the Provider.
2.2        Complaints listing fifteen (15) or more disputed domain names registered by the same
registrant will be subject to a Response Fee which will be refundable to the prevailing
party.  Under no circumstances shall the Response Fee exceed the fee charged to the
Complainant.
3. Administrative Review
3.1 Complaints will be subjected to an initial administrative review by the URS Provider for
compliance with the filing requirements. This is a review to determine that the
Complaint contains all of the necessary information, and is not a determination as to
whether a prima facie case has been established.
3.2 The Administrative Review shall be conducted within two (2) business days of
submission of the Complaint to the URS Provider.
3.3 Given the rapid nature of this Procedure, and the intended low level of required fees,
there will be no opportunity to correct inadequacies in the filing requirements.
3.4        If a Complaint is deemed non-compliant with filing requirements, the Complaint will be
dismissed without prejudice to the Complainant filing a new complaint. The initial filing
fee shall not be refunded in these circumstances.
4. Notice and Locking of Domain
4.1 Upon completion of the Administrative Review, the URS Provider must immediately
notify the registry operator (via email) (“Notice of Complaint”) after the Complaint has
been deemed compliant with the filing requirements. Within 24 hours of receipt of the
Notice of Complaint from the URS Provider, the registry operator shall “lock” the
domain, meaning the registry shall restrict all changes to the registration data, including
transfer and deletion of the domain names, but the name will continue to resolve.  The
registry operator will notify the URS Provider immediately upon locking the domain
name (”Notice of Lock”).
4.2 Within 24 hours after receiving Notice of Lock from the registry operator, the URS
Provider shall notify the Registrant of the Complaint, sending a hard copy of the Notice
of Complaint to the addresses listed in the Whois contact information, and providing an
electronic copy of the Complaint, advising of the locked status, as well as the potentialURS-4
effects if the Registrant fails to respond and defend against the Complaint.  Notices
must be clear and understandable to Registrants located globally. The Notice of
Complaint shall be in English and translated by the Provider into the predominant
language used in the registrant’s country or territory.
4.3 All Notices to the Registrant shall be sent through email, fax (where available) and
postal mail. The Complaint and accompanying exhibits, if any, shall be served
electronically.
4.4 The URS Provider shall also electronically notify the registrar of record for the domain
name at issue via the addresses the registrar has on file with ICANN.
5. The Response
5.1 A Registrant will have 14 calendar days from the date the URS Provider sent its Notice of
Complaint to the Registrant to electronically file a Response with the URS Provider.
Upon receipt, the Provider will electronically send a copy of the Response, and
accompanying exhibits, if any, to the Complainant.
5.2 No filing fee will be charged if the Registrant files its Response prior to being declared in
default or not more than thirty (30) days following a Determination. For Responses filed
more than thirty (30) days after a Determination, the Registrant should pay a reasonable
non-refundable fee for re-examination, plus a Response Fee as set forth in section 2.2
above if the Complaint lists twenty-six (26) or more disputed domain names against the
same registrant.  The Response Fee will be refundable to the prevailing party.
5.3 Upon request by the Registrant, a limited extension of time to respond may be granted
by the URS Provider if there is a good faith basis for doing so. In no event shall the
extension be for more than seven (7) calendar days.
5.4 The Response shall be no longer than 2,500 words, excluding attachments, and the
content of the Response should include the following:
5.4.1 Confirmation of Registrant data.
5.4.2 Specific admission or denial of each of the grounds upon which the Complaint is
based.
5.4.3 Any defense which contradicts the Complainant’s claims.
5.4.4 A statement that the contents are true and accurate.
5.5 In keeping with the intended expedited nature of the URS and the remedy afforded to a
successful Complainant, affirmative claims for relief by the Registrant will not be
permitted except for an allegation that the Complainant has filed an abusive Complaint.
5.6 Once the Response is filed, and the URS Provider determines that the Response is
compliant with the filing requirements of a Response (which shall be on the same day),URS-5
the Complaint, Response and supporting materials will immediately be sent to a
qualified Examiner, selected by the URS Provider, for review and Determination. All
materials submitted are considered by the Examiner.
5.7 The Response can contain any facts refuting the claim of bad faith registration by setting
out any of the following circumstances:
5.7.1 Before any notice to Registrant of the dispute, Registrant’s use of, or
demonstrable preparations to use, the domain name or a name corresponding
to the domain name in connection with a bona fide offering of goods or
services; or
5.7.2 Registrant (as an individual, business or other organization) has been commonly
known by the domain name, even if Registrant has acquired no trademark or
service mark rights; or
5.7.3 Registrant is making a legitimate or fair use of the domain name, without intent
for commercial gain to misleadingly divert consumers or to tarnish the
trademark or service mark at issue.
Such claims, if found by the Examiner to be proved based on its evaluation of all
evidence, shall result in a finding in favor of the Registrant.
5.8 The Registrant may also assert Defenses to the Complaint to demonstrate that the
Registrant’s use of the domain name is not in bad faith by showing, for example, one of
the following:
5.8.1 The domain name is generic or descriptive and the Registrant is making fair use
of it.
5.8.2 The domain name sites are operated solely in tribute to or in criticism of a
person or business that is found by the Examiner to be fair use.
5.8.3 Registrant’s holding of the domain name is consistent with an express term of a
written agreement entered into by the disputing Parties and that is still in effect.
5.8.4 The domain name is not part of a wider pattern or series of abusive registrations
because the Domain Name is of a significantly different type or character to
other domain names registered by the Registrant.
5.9 Other factors for the Examiner to consider:
5.9.1 Trading in domain names for profit, and holding a large portfolio of domain
names, are of themselves not indicia of bad faith under the URS. Such conduct,
however, may be abusive in a given case depending on the circumstances of the
dispute. The Examiner must review each case on its merits.
5.9.2 Sale of traffic (i.e. connecting domain names to parking pages and earning clickper-view revenue) does not in and of itself constitute bad faith under the URS.URS-6
Such conduct, however, may be abusive in a given case depending on the
circumstances of the dispute. The Examiner will take into account:
5.9.2.1. the nature of the domain name;
5.9.2.2. the nature of the advertising links on any parking page associated with
the domain name; and
5.9.2.3. that the use of the domain name is ultimately the Registrant’s
responsibility.
6. Default
6.1 If at the expiration of the 14-day answer period (or extended period if granted), the
Registrant does not submit an answer, the Complaint proceeds to Default.
6.2 In either case, the Provider shall provide Notice of Default via email to the Complainant
and Registrant, and via mail and fax to Registrant. During the Default period, the
Registrant will be prohibited from changing content found on the site to argue that it is
now a legitimate use and will also be prohibited from changing the Whois information.
6.3 All Default cases proceed to Examination for review on the merits of the claim.
6.4 If after Examination in Default cases, the Examiner rules in favor of Complainant,
Registrant shall have the right to seek relief from Default via de novo review by filing a
Response at any time up to six months after the date of the Notice of Default.  The
Registrant will also be entitled to request an extension of an additional six months if the
extension is requested before the expiration of the initial six-month period.
6.5 If a Response is filed after:  (i) the Respondent was in Default (so long as the Response is
filed in accordance with 6.4 above); and (ii) proper notice is provided in accordance with
the notice requirements set forth above, the domain name shall again resolve to the
original IP address as soon as practical, but shall remain locked as if the Response had
been filed in a timely manner before Default. The filing of a Response after Default is
not an appeal; the case is considered as if responded to in a timely manner.
6.5 If after Examination in Default case, the Examiner rules in favor of Registrant, the
Provider shall notify the Registry Operator to unlock the name and return full control of
the domain name registration to the Registrant.
7. Examiners
7.1 One Examiner selected by the Provider will preside over a URS proceeding.
7.2 Examiners should have demonstrable relevant legal background, such as in trademark
law, and shall be trained and certified in URS proceedings. Specifically, Examiners shall
be provided with instructions on the URS elements and defenses and how to conduct
the examination of a URS proceeding.URS-7
7.3 Examiners used by any given URS Provider shall be rotated to the extent feasible to avoid
“forum or examiner shopping.”  URS Providers are strongly encouraged to work equally
with all certified Examiners, with reasonable exceptions (such as language needs, nonperformance, or malfeasance) to be determined on a case by case analysis.
8. Examination Standards and Burden of Proof
8.1 The standards that the qualified Examiner shall apply when rendering its Determination
are whether:
8.1.2   The registered domain name is identical or confusingly similar to a word mark: (i)
for which the Complainant holds a valid national or regional registration and that
is in current use; or (ii) that has been validated through court proceedings; or (iii)
that is specifically protected by a statute or treaty currently in effect and that
was in effect at the time the URS Complaint is filed; and
8.1.2.1    Use can be shown by demonstrating that evidence of use – which can
be a declaration and one specimen of current use – was submitted to,
and validated by, the Trademark Clearinghouse.
8.1.2.2   Proof of use may also be submitted directly with the URS Complaint.
8.1.2   The Registrant has no legitimate right or interest to the domain name; and
8.1.3   The domain was registered and is being used in a bad faith.
8.2 The burden of proof shall be clear and convincing evidence.
8.3 For a URS matter to conclude in favor of the Complainant, the Examiner shall render a
Determination that there is no genuine issue of material fact.  Such Determination may
include that: (i) the Complainant has rights to the name; and (ii) the Registrant has no
rights or legitimate interest in the name. This means that the Complainant must present
adequate evidence to substantiate its trademark rights in the domain name (e.g.,
evidence of a trademark registration and evidence that the domain name was registered
and is being used in bad faith in violation of the URS).
8.4 If the Examiner finds that the Complainant has not met its burden, or that genuine issues
of material fact remain in regards to any of the elements, the Examiner will reject the
Complaint under the relief available under the URS. That is, the Complaint shall be
dismissed if the Examiner finds that evidence was presented or is available to the
Examiner to indicate that the use of the domain name in question is a non-infringing use
or fair use of the trademark.
8.5 Where there is any genuine contestable issue as to whether a domain name registration
and use of a trademark are in bad faith, the Complaint will be denied, the URS
proceeding will be terminated without prejudice, e.g., a UDRP, court proceeding orURS-8
another URS may be filed. The URS is not intended for use in any proceedings with open
questions of fact, but only clear cases of trademark abuse.
8.6 To restate in another way, if the Examiner finds that all three standards are satisfied by
clear and convincing evidence and that there is no genuine contestable issue, then the
Examiner shall issue a Determination in favor of the Complainant. If the Examiner finds
that any of the standards have not been satisfied, then the Examiner shall deny the
relief requested, thereby terminating the URS proceeding without prejudice to the
Complainant to proceed with an action in court of competent jurisdiction or under the
UDRP.
9. Determination
9.1 There will be no discovery or hearing; the evidence will be the materials submitted with
the Complaint and the Response, and those materials will serve as the entire record
used by the Examiner to make a Determination.
9.2 If the Complainant satisfies the burden of proof, the Examiner will issue a Determination
in favor of the Complainant.  The Determination will be published on the URS Provider’s
website. However, there should be no other preclusive effect of the Determination
other than the URS proceeding to which it is rendered.
9.3 If the Complainant does not satisfy the burden of proof, the URS proceeding is
terminated and full control of the domain name registration shall be returned to the
Registrant.
9.4 Determinations resulting from URS proceedings will be published by the service provider
in a format specified by ICANN.
9.5 Determinations shall also be emailed by the URS Provider to the Registrant, the
Complainant, the Registrar, and the Registry Operator, and shall specify the remedy and
required actions of the registry operator to comply with the Determination.
9.6 To conduct URS proceedings on an expedited basis, examination should begin
immediately upon the earlier of the expiration of a fourteen (14) day Response period
(or extended period if granted), or upon the submission of the Response. A
Determination shall be rendered on an expedited basis, with the stated goal that it be
rendered within three (3) business days from when Examination began.  Absent
extraordinary circumstances, however, Determinations must be issued no later than five
(5) days after the Response is filed.  Implementation details will be developed to
accommodate the needs of service providers once they are selected.  (The tender offer
for potential service providers will indicate that timeliness will be a factor in the award
decision.)
10. Remedy
10.1 If the Determination is in favor of the Complainant, the decision shall be immediately
transmitted to the registry operator.URS-9
10.2 Immediately upon receipt of the Determination, the registry operator shall suspend the
domain name, which shall remain suspended for the balance of the registration period
and would not resolve to the original web site.  The nameservers shall be redirected to
an informational web page provided by the URS Provider about the URS. The URS
Provider shall not be allowed to offer any other services on such page, nor shall it
directly or indirectly use the web page for advertising purposes (either for itself or any
other third party).  The Whois for the domain name shall continue to display all of the
information of the original Registrant except for the redirection of the nameservers. In
addition, the Whois shall reflect that the domain name will not be able to be transferred,
deleted or modified for the life of the registration.
10.3 There shall be an option for a successful Complainant to extend the registration period
for one additional year at commercial rates.
10.4 No other remedies should be available in the event of a Determination in favor of the
Complainant.
11. Abusive Complaints
11.1 The URS shall incorporate penalties for abuse of the process by trademark holders.
11.2 In the event a party is deemed to have filed two (2) abusive Complaints, or one (1)
“deliberate material falsehood,” that party shall be barred from utilizing the URS for
one-year following the date of issuance of a Determination finding a complainant to
have:  (i) filed its second abusive complaint; or (ii) filed a deliberate material falsehood.
11.3 A Complaint may be deemed abusive if the Examiner determines:
11.3.1   it was presented solely for improper purpose such as to harass, cause
unnecessary delay, or needlessly increase the cost of doing business; and
11.3.2   (i) the claims or other assertions were not warranted by any existing law or the
URS standards; or (ii) the factual contentions lacked any evidentiary support
11.4 An Examiner may find that Complaint contained a deliberate material falsehood if it
contained an assertion of fact, which at the time it was made, was made with the
knowledge that it was false and which, if true, would have an impact on the outcome on
the URS proceeding.
11.5 Two findings of “deliberate material falsehood” shall permanently bar the party from
utilizing the URS.
11.6      URS Providers shall be required to develop a process for identifying and tracking barred
parties, and parties whom Examiners have determined submitted abusive complaints or
deliberate material falsehoods.URS-10
11.7 The dismissal of a complaint for administrative reasons or a ruling on the merits, in itself,
shall not be evidence of filing an abusive complaint.
11.8 A finding that filing of a complaint was abusive or contained a deliberate materially
falsehood can be appealed solely on the grounds that an Examiner abused his/her
discretion, or acted in an arbitrary or capricious manner.
12. Appeal
12.1 Either party shall have a right to seek a de novo appeal of the Determination based on
the existing record within the URS proceeding for a reasonable fee to cover the costs of
the appeal. An appellant must identify the specific grounds on which the party is
appealing, including why the appellant claims the Examiner’s Determination was
incorrect.
12.2 The fees for an appeal shall be borne by the appellant. A limited right to introduce new
admissible evidence that is material to the Determination will be allowed upon payment
of an additional fee, provided the evidence clearly pre-dates the filing of the Complaint.
The Appeal Panel, to be selected by the Provider, may request, in its sole discretion,
further statements or documents from either of the Parties.
12.3 Filing an appeal shall not change the domain name’s resolution. For example, if the
domain name no longer resolves to the original nameservers because of a
Determination in favor or the Complainant, the domain name shall continue to point to
the informational page provided by the URS Provider. If the domain name resolves to
the original nameservers because of a Determination in favor of the registrant, it shall
continue to resolve during the appeal process.
12.4 An appeal must be filed within 14 days after a Determination is issued and any Response
must be filed 14 days after an appeal is filed.
12.5 If a respondent has sought relief from Default by filing a Response within six months (or
the extended period if applicable) of issuance of initial Determination, an appeal must
be filed within 14 days from date the second Determination is issued and any Response
must be filed 14 days after the appeal is filed.
12.6 Notice of appeal and findings by the appeal panel shall be sent by the URS Provider via
e-mail to the Registrant, the Complainant, the Registrar, and the Registry Operator.
12.7 The Providers’ rules and procedures for appeals, other than those stated above, shall
apply.
13. Other Available Remedies
The URS Determination shall not preclude any other remedies available to the appellant, such as
UDRP (if appellant is the Complainant), or other remedies as may be available in a court of
competition jurisdiction.  A URS Determination for or against a party shall not prejudice theURS-11
party in UDRP or any other proceedings.
14. Review of URS
A review of the URS procedure will be initiated one year after the first Examiner Determination is
issued.  Upon completion of the review, a report shall be published regarding the usage of the
procedure, including statistical information, and posted for public comment on the usefulness
and effectiveness of the procedure.TRADEMARK POST-DELEGATION DISPUTE RESOLUTION PROCEDURE (TRADEMARK PDDRP)
19 SEPTEMBER 2011
1. Parties to the Dispute
The parties to the dispute will be the trademark holder and the gTLD registry operator.  ICANN
shall not be a party.
2. Applicable Rules
2.1 This procedure is intended to cover Trademark post-delegation dispute resolution
proceedings generally.  To the extent more than one Trademark PDDRP provider
(“Provider”) is selected to implement the Trademark PDDRP, each Provider may have
additional rules that must be followed when filing a Complaint.  The following are
general procedures to be followed by all Providers.
2.2 In the Registry Agreement, the registry operator agrees to participate in all postdelegation procedures and be bound by the resulting Determinations.  
3. Language
3.1 The language of all submissions and proceedings under the procedure will be English.
3.2 Parties may submit supporting evidence in their original language, provided and subject
to the authority of the Expert Panel to determine otherwise, that such evidence is
accompanied by an English translation of all relevant text.
4. Communications and Time Limits
4.1 All communications with the Provider must be submitted electronically.  
4.2 For the purpose of determining the date of commencement of a time limit, a notice or
other communication will be deemed to have been received on the day that it is
transmitted to the appropriate contact person designated by the parties.
4.3 For the purpose of determining compliance with a time limit, a notice or other
communication will be deemed to have been sent, made or transmitted on the day that
it is dispatched.
4.4 For the purpose of calculating a period of time under this procedure, such period will
begin to run on the day following the date of receipt of a notice or other
communication.
4.5 All references to day limits shall be considered as calendar days unless otherwise
specified.  - 2 -
5. Standing
5.1 The mandatory administrative proceeding will commence when a third-party
complainant (“Complainant”) has filed a Complaint with a Provider asserting that the
Complainant is a trademark holder (which may include either registered or unregistered
marks as defined below) claiming that one or more of its marks have been infringed, and
thereby the Complainant has been harmed, by the registry operator’s manner of
operation or use of the gTLD.
5.2 Before proceeding to the merits of a dispute, and before the Respondent is required to
submit a substantive Response, or pay any fees, the Provider shall appoint a special oneperson Panel to perform an initial “threshold” review (“Threshold Review Panel”).
6. Standards
For purposes of these standards, “registry operator” shall include entities directly or indirectly
controlling, controlled by or under common control with a registry operator, whether by
ownership or control of voting securities, by contract or otherwise where ‘control’ means the
possession, directly or indirectly, of the power to direct or cause the direction of the
management and policies of an entity, whether by ownership or control of voting securities, by
contract or otherwise.
6.1 Top Level:
A complainant must assert and prove, by clear and convincing evidence, that the
registry operator’s affirmative conduct in its operation or use of its gTLD string that is
identical or confusingly similar to the complainant’s mark, causes or materially
contributes to the gTLD doing one of the following:
(a) taking unfair advantage of the distinctive character or the reputation of the
complainant's mark; or
(b) impairing the distinctive character or the reputation of the complainant's
mark; or
(c) creating a likelihood of confusion with the complainant's mark.
An example of infringement at the top-level is where a TLD string is identical to a
trademark and then the registry operator holds itself out as the beneficiary of the mark.  
6.2 Second Level
Complainants are required to prove, by clear and convincing evidence that, through the
registry operator’s affirmative conduct:
(a) there is a substantial pattern or practice of specific bad faith intent by the
registry operator to profit from the sale of trademark infringing domain names;
and - 3 -
(b) the registry operator’s bad faith intent to profit from the systematic
registration of domain names within the gTLD that are identical or confusingly
similar to the complainant’s mark, which:
(i) takes unfair advantage of the distinctive character or the reputation
of the complainant's mark; or
(ii) impairs the distinctive character or the reputation of the
complainant's mark, or
 (iii) creates a likelihood of confusion with the complainant's mark.  
In other words, it is not sufficient to show that the registry operator is on notice of
possible trademark infringement through registrations in the gTLD.  The registry
operator is not liable under the PDDRP solely because: (i) infringing names are in its
registry; or (ii) the registry operator knows that infringing names are in its registry; or
(iii) the registry operator did not monitor the registrations within its registry.
A registry operator is not liable under the PDDRP for any domain name registration that:
(i) is registered by a person or entity that is unaffiliated with the registry operator; (ii) is
registered without the direct or indirect encouragement, inducement, initiation or
direction of any person or entity affiliated with the registry operator; and (iii) provides
no direct or indirect benefit to the registry operator other than the typical registration
fee (which may include other fees collected incidental to the registration process for
value added services such enhanced registration security).
An example of infringement at the second level is where a registry operator has a
pattern or practice of actively and systematically encouraging registrants to register
second level domain names and to take unfair advantage of the trademark to the extent
and degree that bad faith is apparent.  Another example of infringement at the second
level is where a registry operator has a pattern or practice of acting as the registrant or
beneficial user of infringing registrations, to monetize and profit in bad faith.
7. Complaint
7.1 Filing:
The Complaint will be filed electronically.  Once the Administrative Review has been
completed and the Provider deems the Complaint be in compliance, the Provider will
electronically serve the Complaint and serve a paper notice on the registry operator that
is the subject of the Complaint (“Notice of Complaint”) consistent with the contact
information listed in the Registry Agreement.
7.2 Content:
7.2.1 The name and contact information, including address, phone, and email
address, of the Complainant, and, to the best of Complainant’s knowledge, the
name and address of the current owner of the registration. - 4 -
7.2.2 The name and contact information, including address, phone, and email address
of any person authorized to act on behalf of Complainant.
7.2.3 A statement of the nature of the dispute, and any relevant evidence, which shall
include:
(a) The particular legal rights claim being asserted, the marks that form the
basis for the dispute and a short and plain statement of the basis upon
which the Complaint is being filed.
(b)  A detailed explanation of how the Complainant’s claim meets the
requirements for filing a claim pursuant to that particular ground or
standard.
(c) A detailed explanation of the validity of the Complaint and why the
Complainant is entitled to relief.
(d) A statement that the Complainant has at least 30 days prior to filing the
Complaint notified the registry operator in writing of:  (i) its specific
concerns and specific conduct it believes is resulting in infringement of
Complainant’s trademarks and (ii) it willingness to meet to resolve the
issue.
(e) An explanation of how the mark is used by the Complainant (including
the type of goods/services, period and territory of use – including all online usage) or otherwise protected by statute, treaty or has been
validated by a court or the Clearinghouse.
(f) Copies of any documents that the Complainant considers to evidence its
basis for relief, including evidence of current use of the Trademark at
issue in the Complaint and domain name registrations.
(g) A statement that the proceedings are not being brought for any
improper purpose.
(h) A statement describing how the registration at issue has harmed the
trademark owner.
7.3 Complaints will be limited 5,000 words and 20 pages, excluding attachments, unless the
Provider determines that additional material is necessary.  
7.4 At the same time the Complaint is filed, the Complainant will pay a non-refundable filing
fee in the amount set in accordance with the applicable Provider rules.  In the event that
the filing fee is not paid within 10 days of the receipt of the Complaint by the Provider,
the Complaint will be dismissed without prejudice. - 5 -
8. Administrative Review of the Complaint
8.1 All Complaints will be reviewed by the Provider within five (5) business days of
submission to the Provider to determine whether the Complaint contains all necessary
information and complies with the procedural rules.  
8.2 If the Provider finds that the Complaint complies with procedural rules, the Complaint
will be deemed filed, and the proceedings will continue to the Threshold Review.  If the
Provider finds that the Complaint does not comply with procedural rules, it will
electronically notify the Complainant of such non-compliant and provide the
Complainant five (5) business days to submit an amended Complaint.  If the Provider
does not receive an amended Complaint within the five (5) business days provided, it
will dismiss the Complaint and close the proceedings without prejudice to the
Complainant’s submission of a new Complaint that complies with procedural rules.
Filing fees will not be refunded.
8.3 If deemed compliant, the Provider will electronically serve the Complaint on the registry
operator and serve the Notice of Complaint consistent with the contact information
listed in the Registry Agreement.
9. Threshold Review
9.1 Provider shall establish a Threshold Review Panel, consisting of one panelist selected by
the Provider, for each proceeding within five (5) business days after completion of
Administrative Review and the Complaint has been deemed compliant with procedural
rules.
9.2 The Threshold Review Panel shall be tasked with determining whether the Complainant
satisfies the following criteria:
9.2.1 The Complainant is a holder of a word mark that: (i) is nationally or regionally
registered and that is in current use; or (ii) has been validated through court
proceedings; or (iii) that is specifically protected by a statute or treaty at the
time the PDDRP complaint is filed;
9.2.1.1  Use can be shown by demonstrating that evidence of use – which can
be a declaration and one specimen of current use – was submitted to,
and validated by, the Trademark Clearinghouse
9.2.1.2 Proof of use may also be submitted directly with the Complaint.
9.2.2 The Complainant has asserted that it has been materially harmed as a result of
trademark infringement;
9.2.3 The Complainant has asserted facts with sufficient specificity that, if everything
the Complainant asserted is true, states a claim under the Top Level Standards
herein
OR- 6 -
The Complainant has asserted facts with sufficient specificity that, if everything
the Complainant asserted is true, states a claim under the Second Level
Standards herein;
9.2.4 The Complainant has asserted that:  (i) at least 30 days prior to filing the
Complaint the Complainant notified the registry operator in writing of its
specific concerns and specific conduct it believes is resulting in infringement of
Complainant’s trademarks, and it willingness to meet to resolve the issue; (ii)
whether the registry operator responded to the Complainant’s notice of specific
concerns; and (iii) if the registry operator did respond, that the Complainant
attempted to engage in good faith discussions to resolve the issue prior to
initiating the PDDRP.
9.3 Within ten (10) business days of date Provider served Notice of Complaint, the registry
operator shall have the opportunity, but is not required, to submit papers to support its
position as to the Complainant’s standing at the Threshold Review stage.  If the registry
operator chooses to file such papers, it must pay a filing fee.
9.4 If the registry operator submits papers, the Complainant shall have ten (10) business
days to submit an opposition.
9.5 The Threshold Review Panel shall have ten (10) business days from due date of
Complainant’s opposition or the due date of the registry operator’s papers if none were
filed, to issue Threshold Determination.
 9.6 Provider shall electronically serve the Threshold Determination on all parties.
9.7 If the Complainant has not satisfied the Threshold Review criteria, the Provider will
dismiss the proceedings on the grounds that the Complainant lacks standing and declare
that the registry operator is the prevailing party.
9.8 If the Threshold Review Panel determines that the Complainant has standing and
satisfied the criteria then the Provider to will commence the proceedings on the merits.
10. Response to the Complaint
10.1 The registry operator must file a Response to each Complaint within forty-five (45) days
after the date of the Threshold Review Panel Declaration.
10.2 The Response will comply with the rules for filing of a Complaint and will contain the
name and contact information for the registry operator, as well as a point-by-point
response to the statements made in the Complaint.
10.3 The Response must be filed with the Provider and the Provider must serve it upon the
Complainant in electronic form with a hard-copy notice that it has been served.   - 7 -
10.4 Service of the Response will be deemed effective, and the time will start to run for a
Reply, upon confirmation that the electronic Response and hard-copy notice of the
Response was sent by the Provider to the addresses provided by the Complainant.
10.5 If the registry operator believes the Complaint is without merit, it will affirmatively
plead in its Response the specific grounds for the claim.  
11. Reply
11.1 The Complainant is permitted ten (10) days from Service of the Response to submit a
Reply addressing the statements made in the Response showing why the Complaint is
not “without merit.”  A Reply may not introduce new facts or evidence into the record,
but shall only be used to address statements made in the Response.  Any new facts or
evidence introduced in a Response shall be disregarded by the Expert Panel.
11.2 Once the Complaint, Response and Reply (as necessary) are filed and served, a Panel will
be appointed and provided with all submissions.
12. Default
12.1 If the registry operator fails to respond to the Complaint, it will be deemed to be in
default.
12.2 Limited rights to set aside the finding of default will be established by the Provider, but
in no event will they be permitted absent a showing of good cause to set aside the
finding of default.
12.3 The Provider shall provide notice of Default via email to the Complainant and registry
operator.
12.4 All Default cases shall proceed to Expert Determination on the merits.
13. Expert Panel
13.1 The Provider shall establish an Expert Panel within 21 days after receiving the Reply, or
if no Reply is filed, within 21 days after the Reply was due to be filed.
13.2 The Provider appoint a one-person Expert Panel, unless any party requests a threemember Expert Panel.  No Threshold Panel member shall serve as an Expert Panel
member in the same Trademark PDDRP proceeding.
13.3 In the case where either party requests a three-member Expert Panel, each party (or
each side of the dispute if a matter has been consolidated) shall select an Expert and the
two selected Experts shall select the third Expert Panel member.  Such selection shall be
made pursuant to the Providers rules or procedures.  Trademark PDDRP panelists within
a Provider shall be rotated to the extent feasible. - 8 -
13.4 Expert Panel member must be independent of the parties to the post-delegation
challenge.  Each Provider will follow its adopted procedures for requiring such
independence, including procedures for challenging and replacing a panelist for lack of
independence.  
14. Costs
14.1 The Provider will estimate the costs for the proceedings that it administers under this
procedure in accordance with the applicable Provider rules.  Such costs will be
estimated to cover the administrative fees of the Provider, the Threshold Review Panel
and the Expert Panel, and are intended to be reasonable.
14.2 The Complainant shall be required to pay the filing fee as set forth above in the
“Complaint” section, and shall be required to submit the full amount of the Provider
estimated administrative fees, the Threshold Review Panel fees and the Expert Panel
fees at the outset of the proceedings.  Fifty percent of that full amount shall be in cash
(or cash equivalent) to cover the Complainant’s share of the proceedings and the other
50% shall be in either cash (or cash equivalent), or in bond, to cover the registry
operator’s share if the registry operator prevails.
14.3 If the Panel declares the Complainant to be the prevailing party, the registry operator is
required to reimburse Complainant for all Panel and Provider fees incurred.  Failure to
do shall be deemed a violation of the Trademark PDDRP and a breach of the Registry
Agreement, subject to remedies available under the Agreement up to and including
termination.
15. Discovery
15.1 Whether and to what extent discovery is allowed is at the discretion of the Panel,
whether made on the Panel’s own accord, or upon request from the Parties.
15.2 If permitted, discovery will be limited to that for which each Party has a substantial
need.    
15.3 In extraordinary circumstances, the Provider may appoint experts to be paid for by the
Parties, request live or written witness testimony, or request limited exchange of
documents.
15.4 At the close of discovery, if permitted by the Expert Panel, the Parties will make a final
evidentiary submission, the timing and sequence to be determined by the Provider in
consultation with the Expert Panel.  
16. Hearings
16.1 Disputes under this Procedure will be resolved without a hearing unless either party
requests a hearing or the Expert Panel determines on its own initiative that one is
necessary. - 9 -
16.2 If a hearing is held, videoconferences or teleconferences should be used if at all
possible.  If not possible, then the Expert Panel will select a place for hearing if the
Parties cannot agree.  
16.3 Hearings should last no more than one day, except in the most extraordinary
circumstances.
16.4 All dispute resolution proceedings will be conducted in English.
17. Burden of Proof
The Complainant bears the burden of proving the allegations in the Complaint; the burden must
be by clear and convincing evidence.  
18. Remedies
18.1 Since registrants are not a party to the action, a recommended remedy cannot take the
form of deleting, transferring or suspending registrations (except to the extent
registrants have been shown to be officers, directors, agents, employees, or entities
under common control with a registry operator).
18.2 Recommended remedies will not include monetary damages or sanctions to be paid to
any party other than fees awarded pursuant to section 14.
18.3 The Expert Panel may recommend a variety of graduated enforcement tools against the
registry operator if it the Expert Panel determines that the registry operator is liable
under this Trademark PDDRP, including:
18.3.1 Remedial measures for the registry to employ to ensure against allowing future
infringing registrations, which may be in addition to what is required under the
registry agreement, except that the remedial measures shall not:
(a) Require the Registry Operator to monitor registrations not related to
the names at issue in the PDDRP proceeding; or
(b) Direct actions by the registry operator that are contrary to those
required under the Registry Agreement;
18.3.2 Suspension of accepting new domain name registrations in the gTLD until such
time as the violation(s) identified in the Determination is(are) cured or a set
period of time;
OR,
18.3.3 In extraordinary circumstances where the registry operator acted with malice,
providing for the termination of a Registry Agreement. - 10 -
18.4 In making its recommendation of the appropriate remedy, the Expert Panel will consider
the ongoing harm to the Complainant, as well as the harm the remedies will create for
other, unrelated, good faith domain name registrants operating within the gTLD.
18.5 The Expert Panel may also determine whether the Complaint was filed “without merit,”
and, if so, award the appropriate sanctions on a graduated scale, including:
18.5.1 Temporary bans from filing Complaints;
18.5.2 Imposition of costs of registry operator, including reasonable attorney fees; and
18.5.3 Permanent bans from filing Complaints after being banned temporarily.
18.6 Imposition of remedies shall be at the discretion of ICANN, but absent extraordinary
circumstances, those remedies will be in line with the remedies recommended by the
Expert Panel.
19. The Expert Panel Determination
19.1 The Provider and the Expert Panel will make reasonable efforts to ensure that the
Expert Determination is issued within 45 days of the appointment of the Expert Panel
and absent good cause, in no event later than 60 days after the appointment of the
Expert Panel.
19.2 The Expert Panel will render a written Determination.  The Expert Determination will
state whether or not the Complaint is factually founded and provide the reasons for that
Determination.  The Expert Determination should be publicly available and searchable
on the Provider’s web site.
19.3 The Expert Determination may further include a recommendation of specific remedies.
Costs and fees to the Provider, to the extent not already paid, will be paid within thirty
(30) days of the Expert Panel’s Determination.
19.4 The Expert Determination shall state which party is the prevailing party.
19.5 While the Expert Determination that a registry operator is liable under the standards of
the Trademark PDDRP shall be taken into consideration, ICANN will have the authority
to impose the remedies, if any, that ICANN deems appropriate given the circumstances
of each matter.
20. Appeal of Expert Determination
20.1 Either party shall have a right to seek a de novo appeal of the Expert Determination of
liability or recommended remedy based on the existing record within the Trademark
PDDRP proceeding for a reasonable fee to cover the costs of the appeal.
20.2 An appeal must be filed with the Provider and served on all parties within 20 days after
an Expert Determination is issued and a response to the appeal must be filed within 20 - 11 -
days after the appeal.  Manner and calculation of service deadlines shall in consistent
with those set forth in Section 4 above, “Communication and Time Limits.”
20.3 A three-member Appeal Panel is to be selected by the Provider, but no member of the
Appeal Panel shall also have been an Expert Panel member.
20.4 The fees for an appeal in the first instance shall be borne by the appellant.
20.5 A limited right to introduce new admissible evidence that is material to the
Determination will be allowed upon payment of an additional fee, provided the
evidence clearly pre-dates the filing of the Complaint.
20.6 The Appeal Panel may request at its sole discretion, further statements or evidence
from any party regardless of whether the evidence pre-dates the filing of the Complaint
if the Appeal Panel determines such evidence is relevant.
20.7 The prevailing party shall be entitled to an award of costs of appeal.
20.8 The Providers rules and procedures for appeals, other than those stated above, shall
apply.
21. Challenge of a Remedy
21.1 ICANN shall not implement a remedy for violation of the Trademark PDDRP for at least
20 days after the issuance of an Expert Determination, providing time for an appeal to
be filed.
21.2 If an appeal is filed, ICANN shall stay its implementation of a remedy pending resolution
of the appeal.
21.3 If ICANN decides to implement a remedy for violation of the Trademark PDDRP, ICANN
will wait ten (10) business days (as observed in the location of its principal office) after
notifying the registry operator of its decision.  ICANN will then implement the decision
unless it has received from the registry operator during that ten (10) business-day
period official documentation that the registry operator has either:  (a) commenced a
lawsuit against the Complainant in a court of competent jurisdiction challenging the
Expert Determination of liability against the registry operator, or (b) challenged the
intended remedy by initiating dispute resolution under the provisions of its Registry
Agreement.  If ICANN receives such documentation within the ten (10) business day
period, it will not seek to implement the remedy in furtherance of the Trademark
PDDRP until it receives:  (i) evidence of a resolution between the Complainant and the
registry operator; (ii) evidence that registry operator’s lawsuit against Complainant has
been dismissed or withdrawn; or (iii) a copy of an order from the dispute resolution
provider selected pursuant to the Registry Agreement dismissing the dispute against
ICANN whether by reason of agreement of the parties or upon determination of the
merits. - 12 -
21.4 The registry operator may challenge ICANN’s imposition of a remedy imposed in
furtherance of an Expert Determination that the registry operator is liable under the
PDDRP, to the extent a challenge is warranted, by initiating dispute resolution under the
provisions of its Registry Agreement.  Any arbitration shall be determined in accordance
with the parties’ respective rights and duties under the Registry Agreement.  Neither the
Expert Determination nor the decision of ICANN to implement a remedy is intended to
prejudice the registry operator in any way in the determination of the arbitration
dispute.  Any remedy involving a termination of the Registry Agreement must be
according to the terms and conditions of the termination provision of the Registry
Agreement.
21.5 Nothing herein shall be deemed to prohibit ICANN from imposing remedies at any time
and of any nature it is otherwise entitled to impose for a registry operator’s noncompliance with its Registry Agreement.
22. Availability of Court or Other Administrative Proceedings
22.1 The Trademark PDDRP is not intended as an exclusive procedure and does not preclude
individuals from seeking remedies in courts of law, including, as applicable, review of an
Expert Determination as to liability.
22.2 In those cases where a Party submits documented proof to the Provider that a Court
action involving the same Parties, facts and circumstances as the Trademark PDDRP was
instituted prior to the filing date of the Complaint in the Trademark PDDRP, the Provider
shall suspend or terminate the Trademark PDDRP.RRDRP-1
REGISTRY RESTRICTIONS DISPUTE RESOLUTION PROCEDURE (RRDRP)
1
19 SEPTEMBER 2011
1. Parties to the Dispute
The parties to the dispute will be the harmed established institution and the gTLD registry
operator.  ICANN shall not be a party.
2. Applicable Rules
2.1 This procedure is intended to cover these dispute resolution proceedings generally. To
the extent more than one RRDRP provider (“Provider”) is selected to implement the
RRDRP, each Provider may have additional rules and procedures that must be followed
when filing a Complaint.  The following are the general procedure to be followed by all
Providers.
2.2 In any new community-based gTLD registry agreement, the registry operator shall be
required to agree to participate in the RRDRP and be bound by the resulting
Determinations.
3. Language
3.1 The language of all submissions and proceedings under the procedure will be English.
3.2        Parties may submit supporting evidence in their original language, provided and subject
to the authority of the RRDRP Expert Panel to determine otherwise, that such evidence
is accompanied by an English translation of all relevant text.
4. Communications and Time Limits
4.1 All communications with the Provider must be filed electronically.
4.2 For the purpose of determining the date of commencement of a time limit, a notice or
other communication will be deemed to have been received on the day that it is
transmitted to the appropriate contact person designated by the parties.
4.3 For the purpose of determining compliance with a time limit, a notice or other
communication will be deemed to have been sent, made or transmitted on the day that
it is dispatched.
1
Initial complaints that a Registry has failed to comply with registration restrictions shall be processed through a
Registry Restriction Problem Report System (RRPRS) using an online form similar to the Whois Data Problem
Report System (WDPRS) at InterNIC.net. A nominal processing fee could serve to decrease frivolous complaints.
The registry operator shall receive a copy of the complaint and will be required to take reasonable steps to
investigate (and remedy if warranted) the reported non-compliance. The Complainant will have the option to
escalate the complaint in accordance with this RRDRP, if the alleged non-compliance continues. Failure by the
Registry to address the complaint to complainant’s satisfaction does not itself give the complainant standing to file
an RRDRP complaint.RRDRP-2
4.4 For the purpose of calculating a period of time under this procedure, such period will
begin to run on the day following the date of receipt of a notice or other
communication.
4.5 All references to day limits shall be considered as calendar days unless otherwise
specified.
5. Standing
5.1 The mandatory administrative proceeding will commence when a third-party
complainant (“Complainant”) has filed a Complaint with a Provider asserting that the
Complainant is a harmed established institution as a result of the community-based
gTLD registry operator not complying with the registration restrictions set out in the
Registry Agreement.
5.2 Established institutions associated with defined communities are eligible to file a
community objection. The “defined community” must be a community related to the
gTLD string in the application that is the subject of the dispute. To qualify for standing
for a community claim, the Complainant must prove both: it is an established
institution, and has an ongoing relationship with a defined community that consists of a
restricted population that the gTLD supports.
5.3 Complainants must have filed a claim through the Registry Restriction Problem Report
System (RRPRS) to have standing to file an RRDRP.
5.4 The Panel will determine standing and the Expert Determination will include a
statement of the Complainant’s standing.
6. Standards
6.1 For a claim to be successful, the claims must prove that:
6.1.1 The community invoked by the objector is a defined community;
6.1.2 There is a strong association between the community invoked and the gTLD
label or string;
6.1.3 The TLD operator violated the terms of the community-based restrictions in its
agreement;
6.1.4 There is a measureable harm to the Complainant and the community named by
the objector.
7. Complaint
7.1 Filing:RRDRP-3
The Complaint will be filed electronically. Once the Administrative Review has been
completed and the Provider deems the Complaint to be in compliance, the Provider will
electronically serve the Complaint and serve a hard copy and fax notice on the registry
operator consistent with the contact information listed in the Registry Agreement.
7.2 Content:
7.2.1 The name and contact information, including address, phone, and email
address, of the Complainant, the registry operator and, to the best of
Complainant’s knowledge, the name and address of the current owner of the
registration.
7.2.2 The name and contact information, including address, phone, and email address
of any person authorized to act on behalf of Complainant.
7.2.3 A statement of the nature of the dispute, which must include:
7.2.3.1  The particular registration restrictions in the Registry Agreement with
which the registry operator is failing to comply; and
7.2.3.2  A detailed explanation of how the registry operator’s failure to comply
with the identified registration restrictions has caused harm to the
complainant.
7.2.4 A statement that the proceedings are not being brought for any improper
purpose.
7.2.5 A statement that the Complainant has filed a claim through the RRPRS and that
the RRPRS process has concluded.
7.2.6 A statement that Complainant has not filed a Trademark Post-Delegation
Dispute Resolution Procedure (PDDRP) complaint relating to the same or similar
facts or circumstances.
7.3 Complaints will be limited to 5,000 words and 20 pages, excluding attachments, unless
the Provider determines that additional material is necessary.
7.4 Any supporting documents should be filed with the Complaint.
7.5 At the same time the Complaint is filed, the Complainant will pay a filing fee in the
amount set in accordance with the applicable Provider rules.  In the event that the filing
fee is not paid within 10 days of the receipt of the Complaint by the Provider, the
Complaint will be dismissed without prejudice to the Complainant to file another
complaint.
8. Administrative Review of the Complaint
8.1 All Complaints will be reviewed within five (5) business days of submission by panelists
designated by the applicable Provider to determine whether the Complainant has
complied with the procedural rules.RRDRP-4
8.2 If the Provider finds that the Complaint complies with procedural rules, the Complaint
will be deemed filed, and the proceedings will continue.  If the Provider finds that the
Complaint does not comply with procedural rules, it will electronically notify the
Complainant of such non-compliance and provide the Complainant five (5) business
days to submit an amended Complaint.  If the Provider does not receive an amended
Complaint within the five (5) business days provided, it will dismiss the Complaint and
close the proceedings without prejudice to the Complainant’s submission of a new
Complaint that complies with procedural rules.  Filing fees will not be refunded if the
Complaint is deemed not in compliance.
8.3 If deemed compliant, the Provider will electronically serve the Complaint on the registry
operator and serve a paper notice on the registry operator that is the subject of the
Complaint consistent with the contact information listed in the Registry Agreement.
9. Response to the Complaint
9.1 The registry operator must file a response to each Complaint within thirty (30) days of
service the Complaint.
9.2 The Response will comply with the rules for filing of a Complaint and will contain the
names and contact information for the registry operator, as well as a point by point
response to the statements made in the Complaint.
9.3 The Response must be electronically filed with the Provider and the Provider must serve
it upon the Complainant in electronic form with a hard-copy notice that it has been
served.
9.4 Service of the Response will be deemed effective, and the time will start to run for a
Reply, upon electronic transmission of the Response.
9.5 If the registry operator believes the Complaint is without merit, it will affirmatively
plead in it Response the specific grounds for the claim.
9.6 At the same time the Response is filed, the registry operator will pay a filing fee in the
amount set in accordance with the applicable Provider rules.  In the event that the filing
fee is not paid within ten (10) days of the receipt of the Response by the Provider, the
Response will be deemed improper and not considered in the proceedings, but the
matter will proceed to Determination.
10 Reply
10.1 The Complainant is permitted ten (10) days from Service of the Response to submit a
Reply addressing the statements made in the Response showing why the Complaint is
not “without merit.” A Reply may not introduce new facts or evidence into the record,
but shall only be used to address statements made in the Response. Any new facts or
evidence introduced in a Response shall be disregarded by the Expert Panel.
10.2 Once the Complaint, Response and Reply (as necessary) are filed and served, a Panel will
be appointed and provided with all submissions.RRDRP-5
11. Default
11.1 If the registry operator fails to respond to the Complaint, it will be deemed to be in
default.
11.2      Limited rights to set aside the finding of default will be established by the Provider, but
in no event will it be permitted absent a showing of good cause to set aside the finding
of Default.
11.3 The Provider shall provide Notice of Default via email to the Complainant and registry
operator.
11.4 All Default cases shall proceed to Expert Determination on the merits.
12. Expert Panel
12.1 The Provider shall select and appoint a single-member Expert Panel within (21) days
after receiving the Reply, or if no Reply is filed, within 21 days after the Reply was due to
be filed.
12.2 The Provider will appoint a one-person Expert Panel unless any party requests a threemember Expert Panel.
12.3 In the case where either party requests a three-member Expert Panel, each party (or
each side of the dispute if a matter has been consolidated) shall select an Expert and the
two selected Experts shall select the third Expert Panel member. Such selection shall be
made pursuant to the Provider’s rules or procedures.  RRDRP panelists within a Provider
shall be rotated to the extent feasible.
12.4 Expert Panel members must be independent of the parties to the post-delegation
challenge.  Each Provider will follow its adopted procedures for requiring such
independence, including procedures for challenging and replacing an Expert for lack of
independence.
13. Costs
13.1 The Provider will estimate the costs for the proceedings that it administers under this
procedure in accordance with the applicable Provider Rules.  Such costs will cover the
administrative fees, including the Filing and Response Fee, of the Provider, and the
Expert Panel fees, and are intended to be reasonable.
13.2 The Complainant shall be required to pay the Filing fee as set forth above in the
“Complaint” section, and shall be required to submit the full amount of the other
Provider-estimated administrative fees, including the Response Fee, and the Expert
Panel fees at the outset of the proceedings. Fifty percent of that full amount shall be in
cash (or cash equivalent) to cover the Complainant’s share of the proceedings and the
other 50% shall be in either cash (or cash equivalent), or in bond, to cover the registry
operator’s share if the registry operator prevails.RRDRP-6
13.3 If the Panel declares the Complainant to be the prevailing party, the registry operator is
required to reimburse Complainant for all Panel and Provider fees incurred, including
the Filing Fee. Failure to do shall be deemed a violation of the RRDRP and a breach of
the Registry Agreement, subject to remedies available under the Agreement up to and
including termination.
13.4 If the Panel declares the registry operator to be the prevailing party, the Provider shall
reimburse the registry operator for its Response Fee.
14. Discovery/Evidence
14.1 In order to achieve the goal of resolving disputes rapidly and at a reasonable cost,
discovery will generally not be permitted. In exceptional cases, the Expert Panel may
require a party to provide additional evidence.
14.2 If permitted, discovery will be limited to that for which each Party has a substantial
need.
14.3      Without a specific request from the Parties, but only in extraordinary circumstances, the
Expert Panel may request that the Provider appoint experts to be paid for by the Parties,
request live or written witness testimony, or request limited exchange of documents.
15. Hearings
15.1 Disputes under this RRDRP will usually be resolved without a hearing.
15.2      The Expert Panel may decide on its own initiative, or at the request of a party, to hold a
hearing. However, the presumption is that the Expert Panel will render Determinations
based on written submissions and without a hearing.
15.3 If a request for a hearing is granted, videoconferences or teleconferences should be
used if at all possible.  If not possible, then the Expert Panel will select a place for
hearing if the parties cannot agree.
15.4 Hearings should last no more than one day, except in the most exceptional
circumstances.
15.5 If the Expert Panel grants one party’s request for a hearing, notwithstanding the other
party’s opposition, the Expert Panel is encouraged to apportion the hearing costs to the
requesting party as the Expert Panel deems appropriate.
15.6 All dispute resolution proceedings will be conducted in English.
16. Burden of Proof
The Complainant bears the burden of proving its claim; the burden should be by a
preponderance of the evidence.RRDRP-7
17. Recommended Remedies
17.1 Since registrants of domain names registered in violation of the agreement restriction
are not a party to the action, a recommended remedy cannot take the form of deleting,
transferring or suspending registrations that were made in violation of the agreement
restrictions (except to the extent registrants have been shown to be officers, directors,
agents, employees, or entities under common control with a registry operator).
17.2 Recommended remedies will not include monetary damages or sanctions to be paid to
any party other than fees awarded pursuant to section 13.
17.3 The Expert Panel may recommend a variety of graduated enforcement tools against the
registry operator if the Expert Panel determines that the registry operator allowed
registrations outside the scope of its promised limitations, including:
17.3.1   Remedial measures, which may be in addition to requirements under the
registry agreement, for the registry to employ to ensure against allowing future
registrations that do not comply with community-based limitations; except that
the remedial measures shall not:
(a) Require the registry operator to monitor registrations not related to the
names at issue in the RRDRP proceeding, or
(b) direct actions by the registry operator that are contrary to those
required under the registry agreement
17.3.2   Suspension of accepting new domain name registrations in the gTLD until such
time as the violation(s) identified in the Determination is(are) cured or a set
period of time;
OR,
17.3.3   In extraordinary circumstances where the registry operator acted with malice
providing for the termination of a registry agreement.
17.3 In making its recommendation of the appropriate remedy, the Expert Panel will consider
the ongoing harm to the Complainant, as well as the harm the remedies will create for
other, unrelated, good faith domain name registrants operating within the gTLD.
18. The Expert Determination
18.1 The Provider and the Expert Panel will make reasonable efforts to ensure that the
Expert Determination is rendered within 45 days of the appointment of the Expert Panel
and absent good cause, in no event later than 60 days after the appointment of the
Expert Panel.
18.2 The Expert Panel will render a written Determination. The Expert Determination will
state whether or not the Complaint is factually founded and provide the reasons for itsRRDRP-8
Determination. The Expert Determination should be publicly available and searchable
on the Provider’s web site.
18.3 The Expert Determination may further include a recommendation of specific remedies.
Costs and fees to the Provider, to the extent not already paid, will be paid within thirty
(30) days of the Expert Determination.
18.4 The Expert Determination shall state which party is the prevailing party.
18.5 While the Expert Determination that a community-based restricted gTLD registry
operator was not meeting its obligations to police the registration and use of domains
within the applicable restrictions shall be considered, ICANN shall have the authority to
impose the remedies ICANN deems appropriate, given the circumstances of each
matter.
19. Appeal of Expert Determination
19.1 Either party shall have a right to seek a de novo appeal of the Expert Determination
based on the existing record within the RRDRP proceeding for a reasonable fee to cover
the costs of the appeal.
19.2 An appeal must be filed with the Provider and served on all parties within 20 days after
an Expert Determination is issued and a response to the appeal must be filed within 20
days after the appeal. Manner and calculation of service deadlines shall in consistent
with those set forth in Section 4 above, “Communication and Time Limits.”
19.3 A three-member Appeal Panel is to be selected by the Provider, but no member of the
Appeal Panel shall also have been an Expert Panel member.
19.4 The fees for an appeal in the first instance shall be borne by the appellant.
19.5 A limited right to introduce new admissible evidence that is material to the
Determination will be allowed upon payment of an additional fee, provided the
evidence clearly pre-dates the filing of the Complaint.
19.6 The Appeal Panel may request at its sole discretion, further statements or evidence
from any party regardless of whether the evidence pre-dates the filing of the Complaint
if the Appeal Panel determines such evidence is relevant.
19.7 The prevailing party shall be entitled to an award of costs of appeal.
19.8 The Providers rules and procedures for appeals, other than those stated above, shall
apply.
20. Breach
20.1      If the Expert determines that the registry operator is in breach, ICANN will then proceed
to notify the registry operator that it is in breach. The registry operator will be given the
opportunity to cure the breach as called for in the Registry Agreement.RRDRP-9
20.2      If registry operator fails to cure the breach then both parties are entitled to utilize the
options available to them under the registry agreement, and ICANN may consider the
recommended remedies set forth in the Expert Determination when taking action.
20.3 Nothing herein shall be deemed to prohibit ICANN from imposing remedies at any time
and of any nature it is otherwise entitled to impose for a registry operator’s noncompliance with its Registry Agreement.
21. Availability of Court or Other Administrative Proceedings
21.1 The RRDRP is not intended as an exclusive procedure and does not preclude individuals
from seeking remedies in courts of law, including, as applicable, review of an Expert
Determination as to liability.
21.2 The parties are encouraged, but not required to participate in informal negotiations
and/or mediation at any time throughout the dispute resolution process but the
conduct of any such settlement negotiation is not, standing alone, a reason to suspend
any deadline under the proceedings.gTLD Applicant
Guidebook
(v. 2011-09-19)
Module 6
19 September 2011Applicant Guidebook | version 2011-09-19
6-1
Module 6
Top-Level Domain Application –
Terms and Conditions
By submitting this application through ICANN’s online
interface for a generic Top Level Domain (gTLD) (this
application), applicant (including all parent companies,
subsidiaries, affiliates, agents, contractors, employees and
any and all others acting on its behalf) agrees to the
following terms and conditions (these terms and conditions)
without modification. Applicant understands and agrees
that these terms and conditions are binding on applicant
and are a material part of this application.
1. Applicant warrants that the statements and
representations contained in the application
(including any documents submitted and oral
statements made and confirmed in writing in
connection with the application) are true and
accurate and complete in all material respects,
and that ICANN may rely on those statements and
representations fully in evaluating this application.
Applicant acknowledges that any material
misstatement or misrepresentation (or omission of
material information) may cause ICANN and the
evaluators to reject the application without a
refund of any fees paid by Applicant.  Applicant
agrees to notify ICANN in writing of any change in
circumstances that would render any information
provided in the application false or misleading.
2. Applicant warrants that it has the requisite
organizational power and authority to make this
application on behalf of applicant, and is able to
make all agreements, representations, waivers, and
understandings stated in these terms and
conditions and to enter into the form of registry
agreement as posted with these terms and
conditions.
3. Applicant acknowledges and agrees that ICANN
has the right to determine not to proceed with any
and all applications for new gTLDs, and that there is
no assurance that any additional gTLDs will be
created. The decision to review, consider and
approve an application to establish one or more Module 6
Top-Level Domain Application
Terms and Conditions
Applicant Guidebook | version 2011-09-19
6-2
gTLDs and to delegate new gTLDs after such
approval is entirely at ICANN’s discretion. ICANN
reserves the right to reject any application that
ICANN is prohibited from considering under
applicable law or policy, in which case any fees
submitted in connection with such application will
be returned to the applicant.
4. Applicant agrees to pay all fees that are
associated with this application. These fees include
the evaluation fee (which is to be paid in
conjunction with the submission of this application),
and any fees associated with the progress of the
application to the extended evaluation stages of
the review and consideration process with respect
to the application, including any and all fees as
may be required in conjunction with the dispute
resolution process as set forth in the application.
Applicant acknowledges that the initial fee due
upon submission of the application is only to obtain
consideration of an application. ICANN makes no
assurances that an application will be approved or
will result in the delegation of a gTLD proposed in an
application. Applicant acknowledges that if it fails
to pay fees within the designated time period at
any stage of the application review and
consideration process, applicant will forfeit any fees
paid up to that point and the application will be
cancelled.  Except as expressly provided in this
Application Guidebook, ICANN is not obligated to
reimburse an applicant for or to return any fees
paid to ICANN in connection with the application
process.
5. Applicant shall indemnify, defend, and hold
harmless ICANN (including its affiliates, subsidiaries,
directors, officers, employees, consultants,
evaluators, and agents, collectively the ICANN
Affiliated Parties) from and against any and all thirdparty claims, damages, liabilities, costs, and
expenses, including legal fees and expenses, arising
out of or relating to: (a) ICANN’s or an ICANN
Affiliated Party’s consideration of the application,
and any approval or rejection of the application;
and/or (b) ICANN’s or an ICANN Affiliated Party’s
reliance on information provided by applicant in
the application.Module 6
Top-Level Domain Application
Terms and Conditions
Applicant Guidebook | version 2011-09-19
6-3
6. Applicant hereby releases ICANN and the ICANN
Affiliated Parties from any and all claims by
applicant that arise out of, are based upon, or are
in any way related to, any action, or failure to act,
by ICANN or any ICANN Affiliated Party in
connection with ICANN’s or an ICANN Affiliated
Party’s review of this application, investigation or
verification, any characterization or description of
applicant or the information in this application, or
the decision by ICANN to recommend, or not to
recommend, the approval of applicant’s gTLD
application. APPLICANT AGREES NOT TO
CHALLENGE, IN COURT OR IN ANY OTHER JUDICIAL
FORA, ANY FINAL DECISION MADE BY ICANN WITH
RESPECT TO THE APPLICATION, AND IRREVOCABLY
WAIVES ANY RIGHT TO SUE OR PROCEED IN COURT
OR ANY OTHER JUDICIAL FOR A ON THE BASIS OF
ANY OTHER LEGAL CLAIM AGAINST ICANN AND
ICANN AFFILIATED PARTIES WITH RESPECT TO THE
APPLICATION. APPLICANT ACKNOWLEDGES AND
ACCEPTS THAT APPLICANT’S NONENTITLEMENT TO
PURSUE ANY RIGHTS, REMEDIES, OR LEGAL CLAIMS
AGAINST ICANN OR THE ICANN AFFILIATED PARTIES
IN COURT OR ANY OTHER JUDICIAL FORA WITH
RESPECT TO THE APPLICATION SHALL MEAN THAT
APPLICANT WILL FOREGO ANY RECOVERY OF ANY
APPLICATION FEES, MONIES INVESTED IN BUSINESS
INFRASTRUCTURE OR OTHER STARTUP COSTS AND
ANY AND ALL PROFITS THAT APPLICANT MAY EXPECT
TO REALIZE FROM THE OPERATION OF A REGISTRY
FOR THE TLD; PROVIDED, THAT APPLICANT MAY
UTILIZE ANY ACCOUNTABILITY MECHANISM SET
FORTH IN ICANN’S BYLAWS FOR PURPOSES OF
CHALLENGING ANY FINAL DECISION MADE BY
ICANN WITH RESPECT TO THE APPLICATION.
APPLICANT ACKNOWLEDGES THAT ANY ICANN
AFFILIATED PARTY IS AN EXPRESS THIRD PARTY
BENEFICIARY OF THIS SECTION 6 AND MAY ENFORCE
EACH PROVISION OF THIS SECTION 6 AGAINST
APPLICANT.
7. Applicant hereby authorizes ICANN to publish on
ICANN’s website, and to disclose or publicize in any
other manner, any materials submitted to, or
obtained or generated by, ICANN and the ICANN
Affiliated Parties in connection with the application,
including evaluations, analyses and any other
materials prepared in connection with the Module 6
Top-Level Domain Application
Terms and Conditions
Applicant Guidebook | version 2011-09-19
6-4
evaluation of the application; provided, however,
that information will not be disclosed or published
to the extent that this Applicant Guidebook
expressly states that such information will be kept
confidential, except as required by law or judicial
process. Except for information afforded
confidential treatment, applicant understands and
acknowledges that ICANN does not and will not
keep the remaining portion of the application or
materials submitted with the application
confidential.
8. Applicant certifies that it has obtained permission
for the posting of any personally identifying
information included in this application or materials
submitted with this application. Applicant
acknowledges that the information that ICANN
posts may remain in the public domain in
perpetuity, at ICANN’s discretion.
9. Applicant gives ICANN permission to use
applicant’s name in ICANN’s public
announcements (including informational web
pages) relating to Applicant's application and any
action taken by ICANN related thereto.
10. Applicant understands and agrees that it will
acquire rights in connection with a gTLD only in the
event that it enters into a registry agreement with
ICANN, and that applicant’s rights in connection
with such gTLD will be limited to those expressly
stated in the registry agreement. In the event
ICANN agrees to recommend the approval of the
application for applicant’s proposed gTLD,
applicant agrees to enter into the registry
agreement with ICANN in the form published in
connection with the application materials. (Note:
ICANN reserves the right to make reasonable
updates and changes to this proposed draft
agreement during the course of the application
process, including as the possible result of new
policies that might be adopted during the course of
the application process). Applicant may not resell,
assign, or transfer any of applicant’s rights or
obligations in connection with the application.
11. Applicant authorizes ICANN to:Module 6
Top-Level Domain Application
Terms and Conditions
Applicant Guidebook | version 2011-09-19
6-5
a. Contact any person, group, or entity to
request, obtain, and discuss any
documentation or other information that,
in ICANN’s sole judgment, may be
pertinent to the application;
b. Consult with persons of ICANN’s choosing
regarding the information in the
application or otherwise coming into
ICANN’s possession, provided, however,
that ICANN will use reasonable efforts to
ensure that such persons maintain the
confidentiality of information in the
application that this Applicant
Guidebook expressly states will be kept
confidential.
12. For the convenience of applicants around the
world, the application materials published by
ICANN in the English language have been
translated into certain other languages frequently
used around the world. Applicant recognizes that
the English language version of the application
materials (of which these terms and conditions is a
part) is the version that binds the parties, that such
translations are non-official interpretations and may
not be relied upon as accurate in all respects, and
that in the event of any conflict between the
translated versions of the application materials and
the English language version, the English language
version controls.
13. Applicant understands that ICANN has a longstanding relationship with Jones Day, an
international law firm, and that ICANN intends to
continue to be represented by Jones Day
throughout the application process and the
resulting delegation of TLDs.  ICANN does not know
whether any particular applicant is or is not a client
of Jones Day.  To the extent that Applicant is a
Jones Day client, by submitting this application,
Applicant agrees to execute a waiver permitting
Jones Day to represent ICANN adverse to Applicant
in the matter.  Applicant further agrees that by
submitting its Application, Applicant is agreeing to
execute waivers or take similar reasonable actions
to permit other law and consulting firms retained by
ICANN in connection with the review and Module 6
Top-Level Domain Application
Terms and Conditions
Applicant Guidebook | version 2011-09-19
6-6
evaluation of its application to represent ICANN
adverse to Applicant in the matter.
14. ICANN reserves the right to make reasonable
updates and changes to this applicant guidebook
and to the application process at any time by
posting notice of such updates and changes to the
ICANN website, including as the possible result of
new policies that might be adopted or advice to
ICANN from ICANN advisory committees during the
course of the application process.  Applicant
acknowledges that ICANN may make such
updates and changes and agrees that its
application will be subject to any such updates and
changes.    In the event that Applicant has
completed and submitted its application prior to
such updates or changes and Applicant can
demonstrate to ICANN that compliance with such
updates or changes would present a material
hardship to Applicant, then ICANN will work with
Applicant in good faith to attempt to make
reasonable accommodations in order to mitigate
any negative consequences for Applicant to the
extent possible consistent with ICANN's mission to
ensure the stable and secure operation of the
Internet's unique identifier systems.