Gtld Registration Manual

8/4/2019 Gtld Registration Manual

1/291

19 September 2011

gTLD Applic ant

GuidebookVersion 2011-09-19


2/291

19 September 2011

ICANNs Board of Directors approved the New Generic Top-Level Domain Program

in June 2011, ushering in a vast change to the Internets 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

Boards 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,

ICANNs 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 ICANNs 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


3/291

PreambleNew gTLD Program Background

New gTLDs have been in the forefront of ICANNs agenda since its creation. The new gTLD

program will open up the top level of the Internets 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 theprogram 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 ICANNformally completed its policy

development work on new gTLDs and approved a set of 19 policy recommendations.

Representatives from a wide variety of stakeholder groupsgovernments, individuals, civil society,

business and intellectual property constituencies, and the technology communitywere engaged

in discussions for more than 18 months on such questions as the demand, benefits and risks of newgTLDs, 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 athttp://gnso.icann.org/issues/new-gtlds.

ICANNs worknext 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.
http://gnso.icann.org/issues/new-gtldshttp://gnso.icann.org/issues/new-gtldshttp://gnso.icann.org/issues/new-gtldshttp://www.icann.org/en/topics/new-gtld-program.htmhttp://www.icann.org/en/topics/new-gtld-program.htmhttp://www.icann.org/en/topics/new-gtld-program.htmhttp://gnso.icann.org/issues/new-gtlds


4/291

gTLD Applicant

Guidebook(v. 2011-09-19)

Module 1

19 September 2011


5/291

Applicant Guidebook | version 2011-09-191-1

Module 1Introduction to the gTLD Application Process

This mo dule gives app licants an ove rview o f the p roc ess for

ap plying for a new g eneric top -level dom ain, and includes

instruc tions on how to c om plete and subm it an

ap plic ation, the supp orting do c umenta tion an a pp lic ant

must subm it w ith a n a pp lica tion, the fees req uired , and

when a nd how to subm it them.

This mo dule a lso d esc ribes the c ond itions assoc iate d w ith

pa rticular types of a pplica tions, and the stage s of the

ap plic ation life c ycle.

Prospe c tive a pp lic ants are enc ourag ed to read andbe c om e familia r with the c onte nts of this entire m od ule, as

we ll as the o thers, befo re sta rting the ap plica tion proc ess

to ma ke sure the y understand wha t is req uired of them

and what they can expec t at ea ch stage of the

application evaluation process.

For the c omp lete set o f the supp orting do c umenta tion

and more a bout t he o rigins, history and deta ils of the

po lic y deve lop ment b ac kground to the New gTLD

Prog ram, p lease see http://gnso.icann.org/issues/new-

gtlds/.

This Ap plica nt Guideb ook is the imp lementa tion of Boa rd -approved consensus policy concerning the introduction of

new gTLDs, and ha s bee n revised extensively via p ub lic

c omm ent and c onsultation over a two-year period .

1.1 Application Life Cycle and Timelines

This sec tion p rov ides a desc ription o f the sta ge s tha t an

app lic a tion passes throug h onc e it is submitte d . Som e

sta ge s w ill occ ur for all app lica tions sub mitted ; others will

only oc c ur in spe c ific c irc umstanc es. App lic ant s should be

aw are o f the stage s and step s involved in p roc essing

ap plic ations rec eived.

1.1.1 Application Submission Dates

The user reg istration and app lic a tion submission p eriod s

open at 00:01 UTC 12 Janua ry 2012.
http://gnso.icann.org/issues/new-gtlds/http://gnso.icann.org/issues/new-gtlds/http://gnso.icann.org/issues/new-gtlds/http://gnso.icann.org/issues/new-gtlds/http://gnso.icann.org/issues/new-gtlds/http://gnso.icann.org/issues/new-gtlds/


6/291



The user reg istrat ion p eriod c loses a t 23:59 UTC 29 Ma rch

2012. New users to TAS will not b e a cc ep ted beyond this

time. Users alrea dy reg istered will be ab le to c om plete the

app lic a tion submission p roc ess.

App lic ants should b e aw are tha t, due to req uiredproc essing steps (i.e., online user reg istration, a pp lic a tion

submission, fee submission, and fee rec onc iliation) and

sec urity mea sures built into t he o nline app lic a tion system, it

might t ake substantial time to pe rform a ll of the nec essary

step s to subm it a c omp lete ap plic ation. Acc ordingly,

ap plic ants are enc ourag ed to subm it their co mp leted

ap plica tions and fees as soon as prac tica ble a fter the

Ap p lic a tion Submission Period op ens. Waiting until the end

of this pe riod to beg in the proc ess ma y not p rovide

suffic ient time to subm it a c omp lete ap plic ation b efore the

period c loses. Acc ording ly, new user reg istrations will not

be a cc epted a f ter the da te indica ted ab ove.

The app lic a tion submission period c loses a t 23:59 UTC 12

Ap ril 2012.

To rec eive c onsideration, all ap p lic a tions must b e

submitted electronically through the online application

system by the close of the application submission period.

An a pp lica tion w ill not be c onside red , in the a bsenc e o f

exce p tional c ircumstanc es, if:

It is rec eived a fter the c lose o f the app lic at ion

submission period.

The ap plica tion form is incom plete (either the

que stions have not be en fully answe red or req uired

supporting documents are missing). Applicants will

not ordinarily be p ermitted to supplem ent the ir

app lica tions a fter submission.

The e valuation fee has not b een pa id by the

dea d line. Refe r to Sec tion 1.5 for fee informa tion.

ICANN ha s go ne to signific an t leng ths to ensure tha t the

online a pplica tion system will be a va ilab le for the d ura tion

of the ap plica tion subm ission p eriod . In the e vent that the

system is not ava ilab le, ICANN will provide a lternativeinstruct ions for sub mitting app lic a tions on its we bsite.

1.1.2 Application Processing Stages

This subsec tion p rov ides an overview of the sta ges involved

in processing an application submitted to ICANN. Figure

1-1 provides a simp lified dep iction of the p roc ess. The


7/291



shortest a nd most straightfo rwa rd pa th is ma rked with b old

lines, while c ertain stage s tha t ma y or may not b e

ap plica b le in any g iven c ase a re a lso show n. A b rief

de sc ription of ea c h stage follow s.

ApplicationSubmission

Period

InitialEvaluation

Transition toDelegation

ExtendedEvaluation

Dispute

Resolution

String

Contention

AdministrativeCompleteness

Check

ObjectionFiling

Time

Figure 1-1 Once submitted to ICANN, applications will pass through mul tiplestages of processing.

1.1.2.1 Application Submission Period

At the time the ap plica tion subm ission period op ens, those

wishing t o submit new gTLD ap plica tions can bec om e

reg iste red users of the TLD Ap p lica tion Syste m (TAS).

After completing the user registration, applicants will supplya d ep osit for eac h req uested ap plica tion slot (see sec tion

1.4), after which they w ill rec eive a c cess to the full

app lic a tion form. To c om plete the ap plica tion, users will

answe r a series of q uestions to p rovide g eneral informa tion,

de monstrate financ ial c ap ab ility, and de monstrate

tec hnic a l and ope ra tional ca pab ility. The suppo rting

doc ume nts listed in subsec tion 1.2.2 of this mo dule m ust

also b e submitted throug h the online a pplica tion system as

instructed in the relevant q uestions.

Ap p licants must a lso sub mit the ir eva luation fe es during t his

period . Refe r to Sec tion 1.5 of this mo dule for ad d itiona l

informa tion a bo ut fees and pa yments.

Eac h a pp lic at ion slot is for one g TLD. An ap plica nt m ay

submit as many applications as desired; however, there is

no m ea ns to ap p ly for mo re t han one gTLD in a single

application.


8/291



Follow ing the c lose of the app lic a tion submission p eriod ,

ICANN will provide ap plica nts with pe riod ic sta tus upda tes

on the progress of their applications.

1.1.2.2 Administrative Completeness Check

Imme diately following the c lose o f the a pp lic ation

submission period , ICANN will beg in che c king a ll

app lic a tions for co mp leteness. This c hec k ensures tha t:

All ma nda tory questions a re a nswe red ;

Req uired supp orting d oc uments a re p rovide d in

the p rop er forma t(s); and

The e valuation fees have be en rece ived .

ICANN w ill po st the public p ortions of a ll ap plica tions

co nside red co mp lete a nd read y for eva luation within two

we eks of the c lose of the app lic a tion submission period .Ce rta in que stions rela te to internal p roc esses or

informa tion: app lic ant responses to the se questions will not

be p osted . Eac h que stion is labeled in the a pplica tion form

as to whe ther the informa tion will be p osted . See po sting

designations for the full set of questions in the attachment

to Mod ule 2.

The a dministrat ive co mp leteness chec k is expec ted to b e

c omp leted for all app lic ations in a pe riod of a pp roxima tely

8 wee ks, sub ject to e xtension de pend ing on volume. In the

event that all app lica tions c annot be proce ssed within this

pe riod, ICANN will post up dat ed proc ess informat ion a ndan e stimate d time line.

1.1.2.3 Comment Period

Public c om me nt me chanisms are pa rt of ICANN s po lic y

de velopme nt, imp leme ntation, and op erational p roc esses.

As a priva te-pub lic pa rtnership , ICANN is de dica ted to:

preserving the op erational sec urity a nd sta bility o f the

Internet, promoting c omp etition, ac hieving broad

rep resenta tion of g loba l Internet c om munities, and

de velop ing polic y ap p rop riate to its mission throug h

bot tom-up , co nsensus-ba sed p roc esses. This nec essarily

involves the p artic ipa tion of m any stakeholde r group s in apublic discussion.

ICANN will open a c omm ent p eriod (the Ap plic ation

Com ment p eriod ) at the time ap plic ations are pub licly

posted on ICA NNs web site (refe r to sub sec tion 1.1.2.2). This

pe riod w ill a llow time for the c om munity to review a nd

subm it c omm ents on p osted ap plic ation ma terials


9/291



(referred to as a pp lic ation c omm ents. ) The c omm ent

forum w ill req uire c om me nters to a ssoc ia te c om me nts with

spe c ific ap plic ations and the releva nt p ane l. App lic ation

c om me nts rec eived w ithin a 60-day period from the

po sting of the ap plica tion ma teria ls will be a va ilab le to the

evaluation panels performing the Initial Evaluation reviews.This period is sub jec t to extension, shou ld the vo lume of

ap plica tions or othe r circ umstanc es req uire. To be

considered b y eva luators, com ments must be rece ived in

the designa ted c omm ent forum within the stated time

period.

Eva luators will perform due d ilige nc e on the ap plica tion

com me nts (i.e., dete rmine the ir releva nc e to the

eva luation, verify the a cc urac y of c laims, analyze

meaningfulness of referenc es c ited ) and take the

information p rovide d in these c om me nts into

consideration. In c ases whe re c onsideration o f the

co mme nts has imp ac ted the sc oring o f the ap plica tion,the e va luators will seek clarific a tion from the ap plica nt.

Sta tem ents conc erning c onsideration of app lic at ion

co mme nts that ha ve impa c ted the eva luation dec ision will

be reflec ted in the e va luators summ ary rep orts, which w ill

be published at the end of Extend ed Eva luation.

Comm ents rec eived a fter the 60-da y pe riod will be stored

and ava ilab le (along w ith c omm ents rec eived d uring the

c om ment p eriod ) for other considerations, suc h a s the

d ispute resolution p roc ess, as desc ribed b elow .

In the ne w g TLD ap p lic a tion p roc ess, a ll app lic ants shou ld

be a wa re that c omm ent fora a re a m ec hanism for the

public to b ring releva nt informa tion and issues to the

a ttention of those c harged w ith handling new g TLD

ap plic ations. Anyone ma y subm it a c omm ent in a p ublic

co mment forum.

Com ments and the Forma l Objec tion Process: A d istinc tion

should be ma de b etwe en ap plica tion co mme nts, which

ma y be relevant to ICANNs task of de termining whe ther

app lic a tions me et the estab lished c riteria , and fo rma l

ob ject ions tha t conc ern ma tters outside those eva luation

c riteria . The forma l ob ject ion p roc ess wa s c rea ted to allow

a full and fair c onsideration of ob ject ions ba sed on c ertainlimited grounds outside ICANNs eva luation of a pp lic at ions

on their merits (see sub sec tion 3.2).

Pub lic c om ments will not be c onsidered a s formal

ob ject ions. Comm ents on m at ters assoc ia ted with formal

ob ject ions will not b e c onsidered by pa nels during Initia l

Eva luation. These c om ments will be a va ilab le to a nd m ay


10/291



be subseq uently considered b y an expe rt pa nel during a

d ispute resolution p roc ee d ing (see sub sec tion 1.1.2.9).

How ever, in g eneral, ap plic ation c omm ents have a very

limited role in the d ispute resolution p rocess.

String Contention: Comments designated for theCo mm unity Priority Panel, as relevant to the c riteria in

Mod ule 4, ma y be ta ken into ac c ount during a Com munity

Priority Eva lua tion.

Government Notifications: Gove rnments ma y provide a

notific ation using the a pp lica tion c omm ent forum to

communicate concerns relating to national laws. However,

a g ove rnme nt s notific at ion o f co nc ern will not in itself be

de eme d to b e a formal objection. A notifica tion by a

go vernment d oes not c onstitute ground s for rejec tion of a

gTLD ap plica tion. A gove rnme nt ma y elec t to use this

co mme nt me c hanism to p rovide such a notific ation, in

ad d ition to or as an a lternat ive to the G AC Ea rly Warningproc ed ure desc ribed in subsec tion 1.1.2.4 below .

Gove rnments ma y also c omm unica te d irec tly to

ap p licants using the co ntac t informa tion posted in the

ap plica tion, e.g., to send a notific ation that an ap plied -for

gTLD string might b e c ontrary to a na tional law, and to t ry

to a dd ress any c onc erns with the a pp lic ant.

General Com ments: A ge neral pub lic c omm ent forum w ill

rem a in op en through all stage s of the eva luation proc ess,

to p rovide a mea ns for the p ublic to b ring forward a ny

other relevant informa tion or issues.

1.1.2.4 GAC Early Warning

Conc urrent with the 60-da y c omm ent p eriod , ICANNs

Go vernmenta l Advisory Comm ittee (GAC) m ay issue a

GAC Early Warning notice c onc erning an ap p lica tion. This

provide s the a pp lic ant w ith an indica tion tha t the

app lic a tion is see n as potent ially sensitive o r p rob lema tic

by one or mo re gove rnme nts.

The GAC Early Warning is a no tice on ly. It is not a forma l

ob jection, nor do es it direc tly lead to a proc ess tha t ca n

result in rejec tion of the ap plica tion. How eve r, a G AC Early

Warning should be taken seriously as it ra ises the likelihoo dthat the a pp lica tion c ould be the subject of GAC Advice

on New gTLDs (see sub sec tion 1.1.2.7) or of a forma l

ob jec tion (see sub sec tion 1.1.2.6) at a late r sta ge in the

process.


11/291



A GAC Early Warning typ ica lly results from a not ice to t he

GAC b y one or more gove rnments that a n ap plic ation

might be p rob lema tic, e.g., po tentially viola te na tional law

or raise sensitivities. A G AC Early Warning ma y be issued for

any rea son.1 The GAC ma y then send that notice to the

Boa rd c onstituting t he GAC Early Warning. ICANN willnot ify app lic ants of G AC Early Warnings as soo n a s

prac tica ble a fter rec eipt from the G AC. The GAC Ea rly

Warning notice ma y include a no minated p oint of co ntac t

for furthe r informa tion.

GAC c onsensus is not req uired for a GAC Early Warning to

be issued . Minima lly, the GAC Ea rly Warning must b e

provided in writing to the ICANN Boa rd, and be c learly

lab eled as a GAC Ea rly Warning . This ma y take the form of

an em a il from the G AC C ha ir to t he ICANN Boa rd . For

GAC Early Warnings to b e m ost effec tive, they should

inc lude the rea son for the wa rning and identify the

ob ject ing co untries.

Upo n rec eipt of a G AC Ea rly Warning, the a pplica nt ma y

elect to w ithdraw the a pp lic ation for a pa rtial refund (see

subsec tion 1.5.1), or may e lect to c ontinue w ith the

ap plica tion (this ma y inc lude me eting with rep resenta tives

from the releva nt g ove rnme nt(s) to try to ad dress the

c onc ern). To qualify for the refund desc ribed in subsec tion

1.5.1, the a pplica nt must p rovide notific a tion to ICANN of

its election to withdraw the a pp lic ation w ithin 21 ca lenda r

days of the GAC Ea rly Warning delivery.

To red uc e the possibility of a GAC Ea rly Warning , all

ap plica nts are enc ouraged to ide ntify po tential sensitivities

in ad vanc e of a pplica tion submission, and to wo rk with the

releva nt parties (inc luding go vernments) be foreha nd to

mitiga te c onc erns related to the a pp lic ation.

1.1.2.5 Initial Evaluation

Initia l Eva luation w ill be gin imme d ia tely a fter the

ad ministrat ive co mp leteness chec k conc ludes. All

c om p lete ap plica tions will be reviewed during Initial

Eva luation. At the beg inning of this pe riod , bac kground

sc ree ning on the a pp lying entity and the individuals

nam ed in the ap plic ation will be c ond ucte d. Applic ations

1While 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 ofidentity, such as nationality, race or ethnicity, religion, belief, culture or particular social origin or group, political opinion, membershipof a national minority, disability, age, and/or a language or linguistic group (non-exhaustive)" and "those strings that refer to particularsectors, such as those subject to national regulation (such as .bank, .pharmacy) or those that describe or are targeted to apopulation or industry that is vulnerable to online fraud or abuse.


12/291



must p ass this step in co njunc tion w ith the Initia l Eva luation

reviews.

There a re tw o m a in eleme nts of the Initia l Eva luation :

1. String rev iews (c onc erning the app lied -for gTLD

string ). String rev iews includ e a determina tion tha t

the app lied -for gTLD string is no t likely to cause

sec urity o r sta b ility prob lem s in the DNS, inc lud ing

prob lem s c aused by similarity to existing TLDs or

reserved names.

2. Ap plica nt reviews (co nc erning the entity ap plying

for the gTLD and its p roposed registry services).

App lica nt reviews include a de termination o f

whethe r the a pp lic ant has the req uisite tec hnica l,

op erationa l, and financ ial c ap ab ilit ies to o pe rate a

registry.

By the c onc lusion of the Initial Eva luat ion period , ICANN will

post no tice of a ll Initia l Eva luation results. Dep end ing on

the volume o f applica tions rec eived , suc h notices ma y be

posted in ba tc hes ove r the course o f the Initial Eva luation

period.

The Initial Eva luation is expe c ted to b e c om p leted for a ll

app lic a tions in a p eriod of a pp roxima tely 5 months. If the

volume of a pplica tions rec eived signific ant ly exce ed s 500,

app lic a tions will be proc essed in ba tc hes and the 5-mo nth

time line w ill not b e m et . The first ba tc h w ill be limited to 500

app lic a tions and subseq uent b at c hes will be limited to 400

to a c co unt for c ap ac ity limitations due to ma nag ingextended eva luation, string c ontention, and other

p roc esses assoc ia ted with ea c h p revious bat c h.

If ba tc hing is req uired , a p roc ess externa l to the

app lic a tion submission p roc ess will be em ployed to

esta b lish e va luation p riority. This p roc ess will be based on

an online ticketing system or other ob ject ive c riteria.

If ba tc hing is required , the String Similarity review will be

c om plete d o n all app lic a tions prior to the establishme nt of

eva luation p riority ba tc hes. For ap plica tions identified as

part of a c onte ntion set, the entire c onte ntion set w ill be

kept tog ether in the sam e b atc h.

If b a tc hes a re estab lished , ICANN w ill po st up da ted

p roc ess information a nd an e stimate d timeline.

Note that the processing constraints will limit delegation

ra tes to a stea dy sta te e ven in the eve nt of an extrem ely

high volume of applica tions. The a nnua l delega tion rat e


13/291



will not exce ed 1,000 per year in any case, no ma tter how

ma ny ap plica tions are rec eived.2

1.1.2.6 Objection Filing

Formal ob ject ions to a pplica tions c an be filed on any of

four enumerat ed grounds, by pa rties with stand ing toob ject . The o b jection filing period will ope n a fter ICANN

po sts the list o f c om p lete a pplica tions as desc ribed in

sub sec tion 1.1.2.2, and will la st fo r ap proximate ly 7 months.

Ob jec to rs must file suc h forma l ob jec tions d irec tly with

d ispute resolut ion service p roviders (DRSPs), not w ith

ICANN. The o b jec tion filing p eriod will c lose fo llow ing the

end of t he Initia l Eva luation p eriod (refer to subsec tion

1.1.2.5), with a tw o-week window o f time b etw een the

posting o f the Initia l Eva luat ion results and the c lose o f the

ob jection filing p eriod . Ob ject ions tha t have be en filed

during the ob ject ion filing period will be ad dressed in the

d ispute resolution sta ge, wh ich is out lined in sub sec tion

1.1.2.9 and d iscussed in de ta il in Mod ule 3.

All ap plica nts should b e a wa re tha t third p a rties have the

op po rtunity to file objec tions to any ap plica tion during the

ob jection filing pe riod. App licants who se a pp lica tions a re

the subject of a forma l objection will have a n op po rtunity

to file a respo nse a c c ording to the dispute resolution

servic e p rovide r s rules and proc ed ures. An a pp lic ant

wishing to file a forma l ob ject ion to anot her ap p lic a tion

that ha s be en subm itted wo uld do so w ithin the o bjec tion

filing pe riod , following the ob ject ion filing p roc ed ures in

Mod ule 3.

Ap plica nts are enc ouraged to identify possib le reg ional,

cultural, property interests, or other sensitivities regarding

TLD strings and the ir uses be fore a pp lying and , whe re

possible, co nsult with interested parties to m itiga te a ny

c onc erns in adva nce .

1.1.2.7 Receipt of GAC Advice on New gTLDs

The GA C m ay p rovide p ublic po lic y ad vic e d irec tly to the

ICANN Boa rd o n any a pp lic at ion. The p roc ed ure for GAC

Ad vice o n New gTLDs desc ribed in Module 3 indica tes

that, to b e c onside red by the Boa rd during the eva luationproc ess, the G AC Advice on New g TLDs must be submitte d

by the c lose o f the objec tion filing p eriod . A GAC Early

Warning is not a p rerequisite to use o f the GAC Advice

process.

2See "Delegation Rate Scenarios for New gTLDs" athttp://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-

06oct10-en.pdffor additional discussion.
http://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-06oct10-en.pdfhttp://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-06oct10-en.pdfhttp://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-06oct10-en.pdfhttp://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-06oct10-en.pdfhttp://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-06oct10-en.pdfhttp://icann.org/en/topics/new-gtlds/delegation-rate-scenarios-new-gtlds-06oct10-en.pdf


14/291



GAC Ad vice on New gTLDs tha t include s a c onsensus

statement3 from the GAC tha t an a pp lic ation should not

proce ed as subm itted (or other terms create d by the GAC

to e xpress tha t intent), and t ha t includes a thorough

explana tion of the p ublic p olic y ba sis for suc h advice, will

c rea te a strong presump tion for the Boa rd tha t theap plica tion should not b e a pp roved . If the Boa rd do es not

ac t in ac c orda nce with this type o f ad vic e, it must provide

rat iona le for do ing so.

See Mod ule 3 for ad ditiona l deta il on the proce dures

conc erning G AC Advice o n New gTLDs.

1.1.2.8 Extended Evaluation

Extend ed Evaluat ion is availab le only to certain ap p lic ant s

tha t do no t p ass Initia l Eva luation.

Ap plica nts failing c ertain elem ents of the Initia l Eva luation

c an reque st an Extend ed Eva luation. If the ap p licant doesnot pass Initia l Eva luation and doe s no t expressly req uest

an Extende d Eva luation, the a pp lic at ion will proc ee d no

furthe r. The Extend ed Eva luation period a llow s for an

ad ditiona l exchang e of informa tion be twee n the

ap plic ant and eva luators to c larify informa tion c onta ined

in the app lic at ion. The reviews performed in Extende d

Eva luation do not introd uc e additional evalua tion criteria.

An ap plica tion ma y be req uired to e nter an Extende d

Eva luat ion if one or more p rop osed registry services ra ise

tec hnica l issues tha t m ight ad versely a ffec t the sec urity o r

sta b ility of the DNS. The Extend ed Eva luation period

prov ides a t ime frame fo r these issues to b e investiga ted .

App licants will be informed if suc h a review is req uired by

the e nd of the Initial Eva luation period .

Eva luators and any ap p lic able e xperts consulted w ill

com munica te the c onc lusions resulting from the ad ditional

review b y the end of the Extend ed Eva luation pe riod.

At the c onc lusion o f the Extend ed Eva luation pe riod,

ICANN will post summ ary rep orts, by p anel, from the Initia l

and Extende d Eva luation p eriod s.

If an ap plica tion passes the Extende d Eva luation, it c an

then p roc eed to the next relevant stag e. If the ap plic ation

does not pass the Extende d Eva luation, it w ill proc ee d no

further.

3The GAC will clarify the basis on which consensus advice is developed.


15/291



The Extend ed Eva luation is expe c ted to be c om p leted fo r

all applica tions in a p eriod of app roxima tely 5 months,

though this timefram e c ould b e increased ba sed on

volume. In this eve nt, ICANN w ill post up da ted p roc ess

information and an estimate d timeline.

1.1.2.9 Dispute Resolution

Dispute resolution a pp lies on ly to app lic ants whose

ap plic ations are the subject of a forma l objection.

Where formal objec tions are filed and filing fees paid

during the o b jection filing p eriod , indep end ent d ispu te

resolut ion service p roviders (DRSPs) w ill initiate and

co nclude p roc eed ings ba sed on the ob jec tions rec eived.

The forma l objec tion proc ed ure e xists to p rovide a pa th for

those w ho wish to ob jec t to a n ap plic ation that ha s be en

sub mitted to ICANN. Dispute resolution service p rov iders

serve a s the fora to ad judica te the proce ed ings ba sed on

the subject ma tter and the need ed expertise.

Consolida tion of objec tions filed w ill occ ur whe re

app rop ria te, at t he d isc ret ion of the DRSP.

As a result of a d ispute resolution p roc ee d ing, either the

ap plic ant w ill preva il (in which c ase the ap plica tion c an

proce ed to the next relevant stag e), or the ob jec tor will

preva il (in which c ase either the ap plica tion will proc ee d

no further or the a pp lic ation will be b ound to a c ontention

resolution proc ed ure). In the eve nt o f multiple ob jec tions,

an ap p licant m ust p reva il in a ll d ispute resolution

proce ed ings c onc erning the ap plica tion to proc eed to the

next releva nt stage . App licants will be no tified by theDRSP(s) of the results of d ispute resolut ion p roc ee d ings.

Dispu te resolution proc eedings, where a pp lic able, a re

expec ted to be co mp leted for all ap plica tions within

ap proxima tely a 5-month time fram e. In the event that

volume is suc h tha t this timefram e c annot b e

ac c omm od ate d, ICANN will work with the d ispute

resolution service p rov iders to c rea te p roc essing

proce dures and po st up da ted timeline informa tion.

1.1.2.10 String Contention

String c onte ntion applies only when there is more tha n one

qua lified app lic a tion for the same or similar gTLD strings.

String c ont ent ion refe rs to the sc enario in which the re is

more tha n one q ua lified ap p lica tion for the ide ntica l gTLD

string o r for similar gTLD string s. In this Ap p lic ant Guideb oo k,

simila r me ans strings so simila r tha t they c rea te a


16/291



prob ab ility of user co nfusion if mo re tha n one of the strings

is de lega ted into the roo t zone .

Ap plica nts are enc ouraged to resolve string co ntention

c ases am ong them selves p rior to the string c onte ntion

resolution sta ge . In the a bsence o f resolution b y thec onte nding a pplica nts, string c onte ntion cases are

resolved either throug h a c om munity priority evalua tion (if

a c omm unity-ba sed ap plic ant e lec ts it) or through an

auction.

In the eve nt of conte ntion be twe en a pp lied -for gTLD

strings tha t rep resent ge og rap hic na me s, the p arties ma y

be required to fo llow a different proc ess to resolve the

c onten tion. See sub sec tion 2.2.1.4 of Mod ule 2 for more

information.

Groups of a pp lied -for strings tha t a re either identica l or

simila r a re c a lled con tention sets. All app lic ants should b eawa re tha t if an ap plica tion is identified as being part of a

contention set, string contention resolution procedures will

not b eg in until a ll app lic at ions in the c onte ntion set ha ve

c om plete d a ll aspe c ts of eva luation, including dispute

resolution, if applicable.

To illustrate , as shown in Figure 1-2, Ap p licants A, B, and C

a ll app ly for .EXAMPLE and a re ide ntified as a c onten tion

set. Ap p licants A a nd C p ass Initia l Eva luation , but

Ap plica nt B doe s not. Ap plica nt B req uests Extend ed

Eva luation. A third p a rty files an o bjec tion to Ap p lic ant C s

ap plica tion, and App lic ant C ent ers the d ispute resolution

proc ess. Ap plica nt A must wa it to see whe ther App lic ant sB and C suc cessfully comp lete the Extende d Eva luation

and dispute resolution phases, respectively, before it can

proc eed to the string c onte ntion resolution stage . In this

exam ple, Ap p lic an t B pa sses the Extend ed Eva luation, but

App lic ant C does not p reva il in the d isput e resolution

proc eed ing. String c onte ntion resolution then p roc ee ds

be twee n App lic ants A and B.


17/291



Figure 1-2 All applications in a contention set must complete all previousevaluation and dispute r esolution stages before string cont ention

resolution can begin.

Applicants prevailing in a string contention resolution

proce dure will proce ed to wa rd d elega tion of the ap plied -

fo r gTLDs.

String c ont ent ion resolution for a c ont ent ion set is

estimate d to take from 2.5 to 6 mo nths to c om p lete. The

time req uired will va ry per ca se b ec ause som e c onte ntion

c ases ma y be resolved in either a c om munity priority

eva luation or an auc tion, while ot hers ma y req uire b oth

processes.

1.1.2.11 Transition to DelegationAp plica nts succ essfully comp leting all the relevant stage s

out lined in this subsec tion 1.1.2 a re req uired to c arry out a

series of c onc luding step s before d elegat ion of the

app lied -for gTLD into the roo t zone. These steps includ e

exec ution of a reg istry ag reeme nt with ICANN and

c omp letion of a p re-delega tion tec hnica l test to va lida te

informa tion p rovided in the ap plic ation.

Follow ing exec ution of a reg istry agreem ent, the

p rospe c tive reg istry op erator must c om p lete tec hnica l set-

up a nd show sat isfac tory performa nc e on a set o f

tec hnica l tests before d elega tion of the gTLD into t he rootzone ma y be initia ted . If the p re-de lega tion testing

req uirem ent s a re no t sa tisfied so tha t the gTLD can be

de leg ate d into the root zone within the time fram e

spec ified in the reg istry ag ree me nt, ICANN ma y in its sole

and ab solute d isc retion elec t to t ermina te the reg istry

agreement.


18/291



Onc e a ll of these step s have b een succ essfully com p leted ,

the a pp lic ant is eligible for deleg at ion of its ap plied-for

gTLD into the DNS root zone.

It is expe c ted tha t the transition to delegat ion step s c an b e

com plete d in ap p roxima tely 2 months, thoug h this c ouldtake more time d ep end ing on the a pp lic ant s level of

p rep ared ness for the p re-de lega tion testing and the

volume o f ap plica tions undergoing these step s

concurrently.

1.1.3 Lifecycle Timelines

Based on t he e stimate s for eac h stage de sc ribed in this

sec tion, the lifec ycle for a stra ight forwa rd ap p lic a tion

c ould b e a pproxima tely 9 months, as follow s:

Initial Evaluation

Transition to Delegation

5 Months

2 Months

Administrative Check2 Months

Figure 1-3 A straightforward application could have an approximate 9-monthlifecycle.

The lifec ycle for a highly com p lex ap p lic a tion could be

muc h longe r, suc h as 20 months in the exam ple b elow :


19/291



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 a pp lic at ion reviews will be ma de availab le to

the pub lic a t va rious sta ges in the p roc ess, as shown

below.

Period Posting Content

During AdministrativeCompleteness Check

Public portions of all applications (postedwithin 2 weeks of the start of theAdministrative Completeness Check).

End of AdministrativeCompleteness Check

Results of Administrative CompletenessCheck.

GAC Early Warning Period GAC Early Warnings received.

During Initial Evaluation

Status updates for applications withdrawn orineligible for further review.Contention sets resulting from StringSimilarity review.

End of Initial Evaluation Application status updates with all InitialEvaluation results.

GAC Advice on New gTLDs GAC Advice received.

End of Extended Evaluation

Application status updates with all ExtendedEvaluation results.Evaluation summary reports from the Initialand Extended Evaluation periods.

During Objection Information on filed objections and status


20/291



Period Posting Content

Filing/Dispute Resolution updates available via Dispute ResolutionService Provider websites.Notice of all objections posted by ICANNafter close of objection filing period.

During Contention Resolution(Community PriorityEvaluation)

Results of each Community PriorityEvaluation posted as completed.

During Contention Resolution(Auction)

Results from each auction posted ascompleted.

Transition to DelegationRegistry Agreements posted whenexecuted.Pre-delegation testing status updated.

1.1.5 Sample Application Scenarios

The following sc ena rios b riefly show a va riety o f wa ys in

which an a pp lica tion ma y proc eed through the

eva luation p roc ess. The ta b le tha t follow s exem p lifies

va rious p roc esses and out com es. This is not intend ed to be

an e xhaustive list o f possibilities. There a re o the r po ssible

c omb inations of pa ths an a pp lic ation c ould follow.

Estimate d time frame s for eac h scena rio a re a lso inc luded ,

ba sed on c urrent knowledg e. Actua l time fram es ma y vary

de pe nding o n several fac tors, including the tota l number

of a pp lic ations rec eived b y ICANN during the a pp lica tion

submission period . It shou ld b e e mp ha sized tha t m ost

ap plica tions are expe c ted to p ass throug h the p roc ess in

the shortest period of time , i.e., they will not g o th roug h

extended eva luation , dispute resolution, or stringc ont ent ion resolution p roc esses. Although mo st of the

scena rios be low a re for proce sses extend ing beyond nine

months, it is expec ted tha t mo st applica tions will com plete

the p roc ess within the nine-month timeframe .

ScenarioNumber

InitialEval-

uation

ExtendedEval-

uation

Objec-tion(s)Filed

StringConten-

tion

Ap-proved

for Dele-gationSteps

Esti-mated

ElapsedTime

1 Pass N/A None No Yes 9 months

2 Fail Pass None No Yes14

months

3 Pass N/A None Yes Yes11.5 15months

4 Pass N/AApplicantprevails

No Yes14

months

5 Pass N/AObjectorprevails

N/A No12

months

6 Fail Quit N/A N/A No 7 months


21/291



ScenarioNumber

InitialEval-

uation

ExtendedEval-

uation

Objec-tion(s)Filed

StringConten-

tion

Ap-proved

for Dele-gationSteps

Esti-mated

ElapsedTime

7 Fail Fail N/A N/A No

12

months

8 Fail PassApplicantprevails

Yes Yes16.5 20months

9 Fail PassApplicantprevails

Yes No14.5 18months

Sc ena rio 1 Pass Initial Eva luation, No Ob jec tion, No

Contention In the mo st straight forwa rd c ase, the

app lic a tion passes Initia l Eva luation a nd the re is no ne ed

for an Extend ed Eva luation. No ob ject ions a re filed du ring

the ob jection pe riod, so there is no dispute to resolve. As

the re is no con tention fo r the app lied -for gTLD string , the

ap plica nt ca n enter into a registry ag reem ent a nd theap plica tion ca n proc eed towa rd d elegation of the

app lied -for gTLD. Most a pp lic at ions are expec ted to

c om plete the p roc ess within this timeframe .

Scena rio 2 Extend ed Eva luation, No Ob jec tion, No

Contention In this c ase, the a pp lic a tion fa ils one o r mo re

aspec ts of the Initial Eva luation . The a pp lic ant is eligible fo r

and req uests an Extend ed Eva luation for the a pp rop ria te

elements. Here, the application passes the Extended

Eva luation . As with Scenario 1, no ob jec tions a re filed

during the ob ject ion pe riod, so the re is no d isput e to

resolve . As the re is no c on tention fo r the gTLD string, the

ap plic ant c an e nter into a reg istry ag reem ent a nd the

ap plica tion ca n proc eed towa rd d elega tion of the

app lied -for gTLD.

Scena rio 3 Pass Initial Eva luation, No Ob jec tion,

Contention In this c ase, the app lic a tion p asses the Initial

Eva luation so there is no nee d for Extend ed Eva luation . No

ob jections a re filed during t he o bjec tion pe riod , so the re is

no dispute to resolve. How eve r, there are o ther

app lic a tions for the same or a similar gTLD string , so t here is

c onte ntion. In this case, the ap plica tion p reva ils in the

c onte ntion resolution, so the ap plica nt c an e nter into a

reg istry agreement a nd the a pp lic ation ca n procee dtow ard d elegat ion of the a pp lied -for gTLD.

Scenario 4 Pass Initial Eva luation, Win Ob jec tion, No

Contention In th is c ase, the app lic a tion p asses the Initia l

Eva luation so there is no nee d for Extend ed Eva luation .

During the ob ject ion filing period , an objec tion is filed o n

one o f the four enumerated grounds by a n ob jec tor with


22/291



sta nd ing (refe r to M od ule 3, Ob jec tion Proced ures). The

ob jec tion is hea rd by a d ispute resolution servic e provider

pa nel that finds in favo r of the a pplica nt. The a pplica nt

ca n enter into a registry ag reem ent a nd the ap plica tion

ca n proce ed towa rd d elega tion of the a pp lied -for gTLD.

Scenario 5 Pass Initial Eva luation, Lose Objec tion In this

case, the app lica tion p asses the Initia l Eva luat ion so there

is no need for Extende d Eva luation. During the ob ject ion

pe riod, multiple o b jections a re filed by o ne o r mo re

ob ject ors with standing fo r one or more of the four

enum erated o bjec tion grounds. Eac h ob ject ion is hea rd

by a d ispute resolution service p rov ider panel. In this c ase,

the p ane ls find in favo r of the a pp licant for mo st of the

ob ject ions, but one finds in favor of the objec tor. As one of

the ob jec tions has be en up held, the a pp lic ation do es not

proceed.

Scenario 6 Fail Initial Evaluation, Applicant Withdraws Inthis c ase, the a pp lica tion fails one or more a spe c ts of the

Initia l Eva luation. The a pplica nt d ec ides to w ithd raw the

ap plica tion rat her than co ntinuing w ith Extende d

Eva luation. The a pplica tion does not p roc eed.

Sc ena rio 7 Fail Initial Eva luation, Fail Extended Eva luation

-- In this c ase, the a pp lic a tion fa ils one or more a spec ts of

the Initia l Eva luation . The app lic ant req uests Extend ed

Eva luation for the approp riate e lement s. How eve r, the

ap plica tion fa ils Extend ed Eva luation a lso. The app lic a tion

doe s not proc eed .

Scenario 8 Extended Evaluation, Win Objection, PassContention In this case, the app lica tion fa ils one or more

aspec ts of the Initia l Eva luation . The a pp licant is eligible fo r

and req uests an Extend ed Eva luation for the a pprop riate


Eva luation. During the ob ject ion filing period , an objec tion

is filed on one o f the four enum erated ground s by an

ob ject or with stand ing. The o bjec tion is hea rd by a d isput e

resolution service p rov ider panel tha t find s in favor of the

app lic ant. How eve r, there are othe r ap p lic a tions for the

same or a simila r gTLD string , so the re is c on tention. In this

c ase, the app lic ant preva ils ove r othe r ap plica tions in the

c ontention resolution p roc ed ure, the ap plic ant c an e nterinto a reg istry ag reem ent, and the ap plica tion c an

proce ed towa rd de leg ation of the ap plied -for gTLD.

Scena rio 9 Extend ed Eva luation, Ob jec tion, Fail

ContentionIn this c ase, the a pp lic a tion fa ils one or more

aspec ts of the Initial Eva luation . The a pp lic ant is eligible fo r

and req uests an Extende d Eva luation for the a pp rop riate


23/291




Eva luation. During the ob jection filing period , an ob jection

is filed on one o f the four enum erated ground s by a n

ob ject or with standing. The o bjec tion is hea rd by a d ispu te

resolution service p rov ider that find s in favo r of the

ap plica nt. How eve r, there are othe r ap plica tions for thesame or a similar gTLD string, so the re is c on tention. In this

case, anothe r ap p licant prevails in the c onte ntion

resolution p roc ed ure, and the a pp lic ation d oes not

proceed.

Transition to Delegation After an a pp lic ation has

suc c essfully co mp leted Initial Eva luation, and othe r stage s

as ap plic ab le, the a pp lica nt is req uired to c omp lete a set

of step s lead ing to de lega tion of the gTLD, inc luding

exec ution of a reg istry ag reeme nt with ICANN, and

c om pletion of p re-de lega tion testing. Refer to Mod ule 5 for

a desc ription o f the steps req uired in this sta ge .

1.1.6 Subsequent Application Rounds

ICANNs goa l is to launc h sub seq uent gTLD ap p lica tion

rounds as quickly as possible. The exac t t iming w ill be

ba sed on experienc es ga ined and c hang es req uired after

this round is c om plete d . The go al is for the next ap p lic a tion

round to b eg in within one yea r of the c lose of the

application submission period for the initial round.

ICANN has c om mitted to review ing the effec ts of the New

gTLD Prog ram on the op erat ions of the roo t zone system

afte r the first a pplica tion round , and will defe r the

de lega tions in a sec ond ap plica tion round until it isde termined tha t the de lega tions resulting from the first

round d id not jeop ardize roo t zone system sec urity or

stability.

1.2 Information for All Applicants

1.2.1 Eligibility

Esta b lished c orpora tions, orga niza tions, or institut ions in

go od stand ing may ap ply for a ne w g TLD. Ap p lic at ions

from individua ls or sole p roprietorships will not bec onsidered. Applica tions from or on be ha lf of yet-to-be -

forme d lega l entities, or ap plica tions presuppo sing the

future format ion of a lega l entity (for exam ple, a p end ing

Joint Venture) will not b e c onsidered.


24/291



ICANN has designed the New gTLD Prog ram with m ultiple

stakeholde r protec tion me c hanisms. Bac kground

sc ree ning, fea tures of the gTLD Reg istry Agreeme nt, da ta

and financ ial esc row me c hanisms a re a ll intend ed to

provide registrant and user protections.

The a pplica tion form requires ap p licants to p rovide

information on the leg a l establishme nt of the app lying

ent ity, as well as the identific a tion o f direc to rs, offic ers,

pa rtne rs, and m a jor sha reholders of tha t en tity. The na me s

and po sitions of individuals included in the a pp lic a tion will

be pub lished as pa rt of the app lic at ion; othe r information

collec ted abo ut the ind ividua ls will not b e published .

Bac kground sc reening a t b oth the entity level and the

ind ividua l level will be c ond uc ted for a ll app lic a tions to

con firm eligibility. This inquiry is c onduc ted on the basis of

the informa tion p rov ided in questions 1-11 of theap plica tion form. ICANN may ta ke into a cc ount

information rec eived from any source if it is releva nt to the

criteria in this section.

ICANN w ill pe rform ba c kground sc reening in only two

area s: (1) Ge nera l business d iligenc e a nd c riminal histo ry;

and (2) History of c ybe rsqua tting beha vior. The c riteria

used for crimina l histo ry are a ligned w ith the c rimes of

trust standa rd som etimes used in the ba nking and financ e

industry.

In the absence of exceptional circumstances, applications

from any entity with or inc luding any individual withc onvic tions or dec isions of the types listed in (a) (m)

be low will be autom atica lly disqua lified from the prog ram .

a . within the pa st te n yea rs, has be en

co nvic ted o f any crime relate d to financial

or c orporate g ove rnanc e ac tivities, or has

bee n judged by a c ourt to have c ommitted

fraud or brea c h of fiduc iary duty, or has

be en the subjec t of a judicial dete rmination

tha t ICANN deem s as the sub sta ntive

eq uivalent of any of these;

b . within the pa st te n yea rs, has be en

disc iplined by any go vernment or industry

regulatory body for conduct involving

dishonesty or misuse of the funds of others;


25/291



c . within the p ast ten yea rs has be en

c onvic ted of any willful ta x-relate d fraud o r

willful evasion of tax liabilities;

d . within the p ast ten yea rs has be en

convicted of perjury, forswearing, failing toco ope rate w ith a law enforce ment

investiga tion, or making fa lse sta teme nts to

a law enforce ment age ncy or

representative;

e. has ever been c onvicted of any c rime

involving the use o f co mp uters, telep hony

systems, te lec om munica tions or the Internet

to fac ilita te the c om mission of c rimes;

f. has ever been c onvicted of any c rime

involving the use o f a wea pon, forc e, or the

threa t of force;

g. has ever been c onvicted of any violent or

sexua l offense vict imizing c hild ren, the

elderly, or individuals with disabilities;

h. has eve r been co nvicted of the illega l sale,

ma nufac ture, or d istribution o f

pha rma c eutical drugs, or been c onvicted

or suc c essfully extrad ited for any offense

de sc ribed in Article 3 of the United Na tions

Co nvention Aga inst Illic it Tra ffic in Narco tic

Drugs and Psychot rop ic Sub sta nc es of

19884;

i. has eve r bee n c onvic ted or suc cessfully

extrad ited for any offense d esc ribed in the

United Nations Co nvention ag ainst

Transna tiona l Organized Crime (all

Protocols) 5,6;

j. has be en c onvict ed , within the respec tive

timeframes, of aiding, ab etting, fac ilitating,

ena b ling, c onspiring to c om mit, or failing to

rep ort any of the listed c rimes abo ve (i.e.,

within the past 10 years for crimes listed in4http://www.unodc.org/unodc/en/treaties/illicit-trafficking.html

5http://www.unodc.org/unodc/en/treaties/CTOC/index.html

6It 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 anapplicant would have been convicted pursuant to the UN convention but merely convicted of a crime listed under these conventions,to trigger these criteria.
http://www.unodc.org/unodc/en/treaties/illicit-trafficking.htmlhttp://www.unodc.org/unodc/en/treaties/illicit-trafficking.htmlhttp://www.unodc.org/unodc/en/treaties/illicit-trafficking.htmlhttp://www.unodc.org/unodc/en/treaties/CTOC/index.htmlhttp://www.unodc.org/unodc/en/treaties/CTOC/index.htmlhttp://www.unodc.org/unodc/en/treaties/CTOC/index.htmlhttp://www.unodc.org/unodc/en/treaties/illicit-trafficking.html


26/291



(a) - (d) above , or eve r for the c rimes listed

in (e) (i) above);

k. has entered a guilty plea as pa rt of a plea

ag reem ent or has a c ourt c ase in any

jurisdiction with a disposition of AdjudicatedGuilty or Ad judica tion Withheld (or reg iona l

equivalents), within the respective

timeframes listed abo ve for any o f the listed

crimes (i.e., within the past 10 years for

c rimes listed in (a) (d ) ab ove, or eve r for

the c rimes listed in (e) (i) above);

l. is the subject of a disqualification imposed

by ICANN and in effect a t the time the

ap plica tion is considered;

m. has be en involved in a pa ttern of a dve rse,

final de c isions indica ting that the ap plica ntor individua l nam ed in the ap plic ation wa s

enga ge d in c ybersqua tting a s de fined in

the Uniform Dom a in Na me Dispu te

Resolution Policy (UDRP), the Anti-

Cyb ersquat ting Consume r Prote c tion Ac t

(ACPA), or othe r eq uivalen t leg islation, or

wa s enga ge d in reverse d oma in nam e

hijac king unde r the UDRP or ba d faith or

rec kless d isreg ard und er the ACPA or other

eq uivalen t leg islation. Three o r more suc h

dec isions with one o c curring in the last four

yea rs will generally b e c onsidered to

c onstitute a pa ttern.

n. fails to p rovid e ICANN with the ident ifying

information nec essa ry to c onfirm identity a t

the time o f ap plica tion or to resolve

que stions of ident ity during the ba c kground

sc ree ning p roc ess;

o. fails to p rovide a g oo d fa ith effort to

disclose all relevant information relating to

item s (a) (m).

Bac kground sc ree ning is in plac e to p rote c t the p ub licinterest in the a lloc a tion of c ritica l Inte rnet resources, and

ICANN reserves the right to deny a n ot herwise q ua lified

ap plic ation b ased on any informa tion ide ntified during the

ba ckground sc reening p roc ess. For examp le, a final and

leg ally binding de c ision o bta ined by a national law

enforce me nt or consumer protec tion authority finding that

the ap plica nt was enga ged in fraudulent and d ec eptive


27/291



c om me rc ia l p rac tices as de fined in the Orga niza tion for

Eco nomic C o-ope ration and Developme nt (OECD)

Guide lines for Protec ting C onsume rs from Fraudulent a nd

Dec ep tive C om me rc ial Prac tices Ac ross Borders7 may

c ause a n ap plic ation to b e rejec ted . ICANN may a lso

c ontac t the ap plic ant w ith ad ditiona l questions ba sed oninforma tion ob tained in the ba c kground screening

process.

All app lica nts are req uired to p rovide c omp lete a nd

de tailed explana tions reg arding a ny of the ab ove e vents

as part of the a pplica tion. Background sc reening

information will not b e ma de publicly ava ilab le by ICANN.

Reg istrar Cross-Ownership -- ICANN-accredited registrars

are eligib le to app ly for a gTLD. How ever, all gTLD reg istries

are req uired to a bide b y a Co de of Cond uct a dd ressing,

inter a lia, non-d isc riminato ry ac c ess for a ll autho rized

reg istrars. ICANN reserves the right t o refe r any a pp lic a tionto the a pp rop riate c omp etition a uthority relative to any

c ross-ow ne rship issues.

Lega l Compliance --ICA NN must c om p ly with a ll U.S. laws,

rules, and reg ulations. One suc h set of reg ulations is the

ec onom ic and trad e sanc tions program a dm inistered by

the Offic e o f Fore ign Asset s Co ntrol (OFAC ) of the U.S.

Dep artment of the Trea sury. These sanc tions have b ee n

imposed on c erta in countries, as well as individua ls and

ent ities tha t a ppea r on OFAC's List o f Spec ially Designa ted

Nationa ls and Bloc ked Persons (the SDN List). ICANN is

prohibited from providing most goods or services to

residents of sanc tioned countries or their go vernmenta l

ent ities or to SDNs witho ut a n app licab le U.S. governme nt

autho riza tion or exemp tion. ICANN genera lly will not see k a

lic ense to provide go od s or servic es to an ind ividua l or

ent ity on the SDN List. In the past, whe n ICANN ha s bee n

req uested t o p rovide services to ind ividua ls or entities tha t

a re not SDNs, but a re residents of sanc tioned c ountries,

ICANN ha s soug ht a nd be en grante d lic enses as req uired .

In a ny given ca se, howeve r, OFAC c ould d ec ide not to

issue a req uested lic ense.

1.2.2 Required Documents

All ap plica nts should b e p rep ared to submit the follow ing

doc uments, which are required to a cc omp any ea ch

application:

7http://www.oecd.org/document/56/0,3746,en_2649_34267_2515000_1_1_1_1,00.html
http://www.oecd.org/document/56/0,3746,en_2649_34267_2515000_1_1_1_1,00.htmlhttp://www.oecd.org/document/56/0,3746,en_2649_34267_2515000_1_1_1_1,00.htmlhttp://www.oecd.org/document/56/0,3746,en_2649_34267_2515000_1_1_1_1,00.htmlhttp://www.oecd.org/document/56/0,3746,en_2649_34267_2515000_1_1_1_1,00.html


28/291



1. Proof of legal e stab lishme nt Docum enta tion of the

ap p licant s esta blishme nt a s a spe c ific typ e o f entity in

ac c orda nc e w ith the a pp lic able law s of its jurisdic tion.

2. Financial statements. App licants must provide a ud ited

or inde pe ndently ce rtified financ ial sta tem ents for the

most recently co mp leted fisc al yea r for the a pp lic ant.

In som e c ases, unaud ited financ ial sta tem ents ma y be

provided.

Suppo rting do cume nta tion should b e subm itted in the

origina l language. Eng lish translations a re not req uired .

All do c ume nts must b e va lid at the time o f submission.

Refer to the Eva luation Criteria , a ttac hed to M od ule 2, for

ad ditional d eta ils on the req uirem ents for these

documents.

Som e typ es of suppo rting do cume nta tion are req uired only

in ce rta in ca ses:

1. Comm unity end orsement If an ap plic ant has

designa ted its app lic at ion as com munity-based (see

sec tion 1.2.3), it w ill be asked to submit a written

end orsem ent o f its ap plica tion by one or more

esta b lished institutions rep resent ing the com munity it

has nam ed . An ap plic ant ma y subm it w ritten

endorsem ent s from multiple institutions. If ap p lic ab le,

this will be subm itted in the sec tion of the a pp lic at ion

c onc erning the c omm unity-ba sed de signa tion.

At lea st one suc h endorsem ent is req uired for a

c omp lete a pp lica tion. The form a nd c ontent of theend orsem ent a re a t the d isc retion of the p arty

p roviding the end orsem ent; how eve r, the letter must

identify the a pp lied -for gTLD string a nd the a pp lying

entity, includ e a n express sta teme nt o f support for the

ap plic ation, and supp ly the c onta ct informa tion of the

entity providing the e ndo rsem ent.

Written end orsem ents from ind ividua ls need not be

subm itted with the a pp lic ation, but ma y be subm itted

in the ap plica tion c omm ent forum.

2. Government supp ort or non-objec tion If an app lic ant

has ap plied fo r a gTLD string tha t is a ge og raphic nam e(as defined in this Guide bo ok), the ap plica nt is req uired

to submit doc ume nta tion of supp ort for or non-

ob jec tion to its ap plic ation from the releva nt

gove rnme nts or pub lic autho rities. Refe r to subsec tion

2.2.1.4 for more informa tion on the req uirem ents for

ge og rap hic name s. If ap plica ble, this will be submitted

in the g eog rap hic nam es sec tion of the a pp lic ation.


29/291



3. Doc umentation of third-pa rty funding co mm itmentsIf

an app lic ant lists fund ing from th ird pa rties in its

ap plic ation, it must provide evidenc e o f co mmitment

by the pa rty co mm itting the funds. If ap plica ble, this

will be subm itted in the financ ia l sec tion of the

application.

1.2.3 Community-Based Designation

All ap plica nts are req uired to d esigna te w hethe r their

ap plic ation is community-based .

1.2.3.1 Definitions

For purpo ses of this Ap p lic ant Gu ideboo k, a community-

based g TLD is a g TLD tha t is op erated for the b ene fit of a

c learly delinea ted com munity. Designation or non-

de signa tion of a n a pp lic ation a s c omm unity-ba sed is

entirely at the d isc retion of the ap p licant. Any ap plica nt

ma y designa te its ap plica tion as c om munity-based ;how eve r, ea c h app lic ant ma king th is designa tion is asked

to substa ntiate its sta tus as rep resent a tive o f the

c om munity it na mes in the a pplica tion by submission of

written e ndorsem ents in suppo rt of the ap plica tion.

Add itiona l informa tion m ay b e requested in the e vent of a

c om munity p riority eva luation (refer to sec tion 4.2 of

Mod ule 4). An ap plica nt for a c om munity-based gTLD is

expec ted to:

1. Demo nstra te a n ong oing relat ionship with a c learly

delineated community.

2. Have app lied for a g TLD string strong ly and spec ifica llyrelated to the co mmunity nam ed in the app lic ation.

3. Have proposed de dica ted registration a nd use po licies

for reg istran ts in its p roposed gTLD, inc lud ing

ap prop riate sec urity verific at ion proc ed ures,

commensurate with the community-based purpose it

has name d.

4. Have its app lic at ion end orsed in writing by one or more

esta b lished institutions rep resenting the c om munity it

has nam ed .

For purposes of d ifferentiation, an ap plica tion tha t ha s not

been designa ted as com munity-based will be referred to

hereina fter in this do c ume nt a s a standard application. A

sta nd ard g TLD ca n be used for any purpose c onsisten t with

the requireme nts of the a pp lic ation a nd eva luation

c riteria, a nd with the reg istry agreem ent. A standa rd

ap plic ant m ay o r ma y not ha ve a forma l relationship with

an exc lusive reg istrant o r user populat ion. It ma y or ma y


30/291



not em ploy e lig ibility or use restric tions. Sta nd ard simp ly

mea ns here tha t the a pp lic ant ha s not d esigna ted the

ap plic ation a s c omm unity-ba sed .

1.2.3.2 Implications of Application Designation

Ap plica nts should und erstand how their designa tion asc omm unity-ba sed or stand ard w ill affec t a pp lic ation

proc essing a t p a rticular stage s, and , if the ap p lica tion is

successful, execution of the registry agreement and

sub seq uent o b liga tions as a gTLD registry op erator, as

de sc ribed in the follow ing pa rag rap hs.

Obje c tion / Dispute Resolution All ap p lic ants shou ld

understand that a forma l objection ma y be filed ag ainst

any a pp lica tion o n c omm unity grounds, even if the

app lic ant has not d esignate d itself as c om munity-ba sed or

de c lared the gTLD to be aimed at a pa rtic ular co mmunity.

Refer to Mod ule 3, Objec tion Proc ed ures.

String Contention Resolution o f string c ont ent ion ma y

include o ne or more co mp onents, de pe nding on the

c omp osition of the c ontention set a nd the elections ma de

by c omm unity-ba sed ap plic ants.

A settlement be tween the p arties ca n occ ur at any

time a fter cont ent ion is identified . The p a rties w ill be

enc ourag ed to me et with an objec tive to settle the

c ontention. Applic ants in c ontention a lwa ys have

the op portunity to resolve the c onte ntion

voluntarily, resulting in the withdrawal of one or

more a pp lica tions, before reac hing the c ontentionresolution sta ge.

A com munity priority evaluation will take plac e o nly

if a c omm unity-ba sed ap plic ant in a c ontention set

elec ts this op tion. All com munity-based ap plica nts

in a c onte ntion set w ill be offered t his op tion in the

eve nt tha t there is c onte ntion rem aining afte r the

ap plica tions have suc c essfully c om p leted all

previous evaluation stages.

An auction will result for ca ses of c on ten tion no t

resolved by c om munity priority eva luation or

ag reem ent b etw een the pa rties. Auction oc c urs asa con tention resolution me ans of last resort. If a

c om munity priority eva luation oc c urs but d oes not

produc e a c lea r winner, an a uction will take p lac e

to resolve the c onte ntion.

Refe r to Module 4, String Co ntention Proc ed ures, for

detailed discussions of contention resolution procedures.


31/291



Contract Execution and Post-Delegation A c om munity-

ba sed ap plic ant will be subject to c ertain po st-de leg ation

c ontrac tua l ob liga tions to ope ra te the g TLD in a ma nner

c onsistent w ith the restric tions assoc iate d w ith its

community-based designation. Material changes to the

co ntrac t, including c hang es to the c omm unity-ba sedna ture of the g TLD and any assoc iate d p rov isions, ma y only

be ma de w ith ICANNs ap prova l. The d ete rmination of

whethe r to ap prove cha nges req uested b y the app lic ant

w ill be a t ICANNs d isc ret ion. Prop osed c riteria for

ap proving such c hang es are the subjec t of p olic y

d isc ussions.

Com munity-ba sed ap plic ations are intende d to be a

na rrow c at eg ory, for ap p lica tions whe re the re a re

unamb iguo us assoc iations am ong the ap plica nt, the

c om munity served , and t he a pp lied -for gTLD string .

Eva luation of an app licant s de signation a s c om munity-

ba sed will oc c ur only in the event o f a c onte ntion situationthat results in a community priority evaluation. However,

any a pp lic ant de signa ting its ap plic ation a s c omm unity-

ba sed will, if the a pp lic ation is ap proved, be bo und b y the

reg istry agreem ent to imp lement the c om munity-based

restric tions it has spec ified in the app lic a tion . This is true

even if there a re no c ontend ing a pp lic ants.

1.2.3.3 Changes to Application Designation

An a pp lica nt ma y not c hang e its de signa tion a s stand ard

or co mm unity-based onc e it ha s submitted a gTLD

ap plica tion for proc essing.

1.2.4 Notice concerning Technical Acceptance Issueswith New gTLDs

All app lica nts should be aw are that a pp rova l of an

ap plica tion and e ntry into a registry ag reeme nt with

ICANN do not g ua rant ee tha t a ne w g TLD will immed iately

function througho ut the Internet. Past expe rienc e indica tes

tha t netw ork op erators ma y not imme diat ely fully suppo rt

new to p-level dom ains, eve n when these dom a ins have

be en d eleg at ed in the DNS roo t zone , since third-party

softwa re mo dific ation ma y be required and ma y not

happ en immed iately.

Simila rly, softw are a pp lic a tions som et imes a tte mp t to

valida te do ma in name s and ma y not rec og nize new o r

unknown top -leve l doma ins. ICANN ha s no a uthority or

ab ility to req uire tha t softwa re a c ce pt ne w to p-level

do ma ins, a lthough it does p rom inently pub lic ize w hich top -

level do ma ins are valid and has de veloped a ba sic tool to


32/291



assist a pp lic a tion p roviders in the use o f c urrent roo t-zone

data.

ICANN e nc ourages app lic an ts to fam ilia rize them selves

with the se issues and ac c ount for them in the ir sta rtup and

launc h plans. Suc c essful app lic ants ma y find them selvesexpend ing c onsiderab le efforts wo rking with p rovide rs to

ac hieve ac c ep tanc e of their new top -level doma ins.

Applicants should review

http:// ww w.ica nn.org/ en/ top ics/ TLD-ac c ep tanc e/fo r

ba c kground . IDN ap p lic ants should a lso review t he

ma terial conc erning experienc es w ith IDN test strings in the

roo t zone (see http://idn.icann.org/).

1.2.5 Notice concerning TLD Delegations

ICANN is only a b le to c rea te TLDs as deleg a tions in the DNS

roo t zone, expressed using NS rec ords with a ny

c orrespond ing DS rec ords and glue rec ords. There is no

policy e nab ling ICANN to p lac e TLDs as other DNS rec ord

types (such as A, MX, or DNAME records) in the root zone.

1.2.6 Terms and Conditions

All ap plica nts must a gree to a standard set of Terms and

Co nd itions for the app lic a tion p roc ess. The Terms and

Cond itions are a va ilable in Mod ule 6 of this guide bo ok.

1.2.7 Notice of Changes to Information

If at any t ime during the eva luation p roc ess information

previously subm itted by a n a pp lic ant be c ome s untrue o rinac c urat e, the ap plica nt must promp tly notify ICANN via

sub mission of the a pprop ria te fo rms. This inc ludes

ap plica nt-spe c ific informat ion suc h as change s in financ ia l

po sition a nd c hang es in owne rship or control of the

applicant.

ICANN reserves the right to req uire a re-eva luation of the

ap plica tion in the eve nt of a m at erial cha nge . This c ould

involve a dd itional fees or eva luation in a subseq uent

ap plic ation round.

Failure to notify ICANN of a ny change in c irc umstanc es

that wo uld rende r any informa tion p rovided in the

ap plica tion false or mislead ing ma y result in d enial of the

application.
http://www.icann.org/en/topics/TLD-acceptance/http://www.icann.org/en/topics/TLD-acceptance/http://idn.icann.org/http://idn.icann.org/http://idn.icann.org/http://www.icann.org/en/topics/TLD-acceptance/


33/291



1.2.8 Voluntary Designation for High SecurityZones

An ICANN stakeholde r group ha s c onsidered d eve lopm ent

of a possible spec ial designa tion fo r "High Sec urity Zone

Top Leve l Dom a ins ( HSTLDs ).The group s Final Rep ortca n be found at http:// www .ica nn.org/ en/top ics/ new-gt lds/ hstld-final-rep ort-11ma r11-en.pd f.

The Final Rep ort ma y be used to inform furthe r work. ICANN

will suppo rt inde pe ndent efforts tow a rd d eve loping

vo lunta ry high-sec urity TLD designa tions, which may be

ava ilab le to g TLD ap p lic ants w ishing to pursue suc h

designations.

1.2.9 Security and StabilityRoo t Zone Sta b ility: There ha s bee n signific ant stud y,

ana lysis, and c onsultation in prepa rat ion for launch o f the

New gTLD Prog ram, indica ting tha t the add ition o f gTLDs tothe root zone will not ne ga tively imp ac t the sec urity or

sta b ility of t he DNS.

It is estima ted tha t 200-300 TLDs will be deleg a ted annua lly,

and dete rmined that in no ca se w ill mo re tha n 1000 new

gTLDs be ad ded to t he root zone in a yea r. The d elega tion

rat e analysis, co nsultations with the tec hnica l co mm unity,

and anticipate d normal operational upgrad e c ycles all

lead to the conc lusion that the ne w g TLD de lega tions will

have no signific an t imp ac t on the stability of the root

system . Mod eling and rep orting will co ntinue d uring, a nd

after, the first application round so that root-scalingdisc ussions c an c ontinue and the de lega tion rat es c an b e

ma nag ed as the program go es forwa rd.

All app lic ants should be aw are that d elega tion of a ny new

gTLDs is c ond itional on the continued absenc e o f

signific ant neg at ive imp ac t on the sec urity or sta bility of

the DNS and the roo t zone system (inc luding the p roc ess

for de lega ting TLDs in the root zone). In the event tha t

there is a rep orted impa c t in this reg ard a nd p roc essing of

app lic a tions is de layed , the a pplica nts will be no tified in an

orderly and timely ma nner.

1.2.10 Resources for Applicant Assistance

A va riety of sup port resources a re a va ilab le to g TLD

app lic ants. For exam p le, ICANN is esta b lishing a me ans for

providing financ ia l assistanc e to eligible ap plica nts,

throug h a p roc ess indep end ent of this Guide bo ok. In

ad dition, ICANN will maintain a we bp ag e a s an
http://www.icann.org/en/topics/new-gtlds/hstld-final-report-11mar11-en.pdfhttp://www.icann.org/en/topics/new-gtlds/hstld-final-report-11mar11-en.pdfhttp://www.icann.org/en/topics/new-gtlds/hstld-final-report-11mar11-en.pdfhttp://www.icann.org/en/topics/new-gtlds/hstld-final-report-11mar11-en.pdfhttp://www.icann.org/en/topics/new-gtlds/hstld-final-report-11mar11-en.pdfhttp://www.icann.org/en/topics/new-gtlds/hstld-final-report-11mar11-en.pdf


34/291



informa tiona l resource fo r app lic ants see king a ssista nc e,

and organizations offering support. More information will

be ava ilab le o n ICANNs we bsite a t

http://www.icann.org/en/topics/new-gtld-program.htm .8

1.2.11 Updates to the Applicant Guidebook

As app rove d b y the ICANN Boa rd o f Direc to rs, this

Guid eb oo k forms the basis of the New gTLD Prog ram.

ICANN reserves the right to ma ke reasona ble upd at es and

c hang es to the App lic ant Guideb ook at any time,

including as the possible result of new technical standards,

referenc e d oc uments, or polic ies that m ight b e a do pte d

during the c ourse o f the a pp lic a tion proc ess. Any suc h

updates or rev isions will be p osted o n ICANNs web site.

1.3 Information for InternationalizedDomain Name Applicants

Som e a pp lied -for gTLD strings a re expec ted to b e

Inte rna tiona lized Dom a in Nam es (IDNs). IDNs are dom ain

nam es including c harac ters used in the loc a l

rep resenta tion of languag es not w ritten w ith the b asic

La tin alphabet (a - z), Europea n-Arab ic d igits (0 - 9), and

the hyphen (-). As desc ribed b elow , IDNs req uire the

insertion o f A-lab els into the DNS roo t zone.

1.3.1 IDN-Specific Requirements

An a pplica nt for an IDN string must p rovide informationindica ting c omp lianc e with the IDNA protoc ol and othe r

tec hnica l req uirem ents. The IDNA protoc ol and its

doc umentation can be found at

http://icann.org/en/topics/idn/rfcs.htm.

Ap p lic ants must p rov ide app lied -for gTLD strings in the form

of both a U-label (the IDN TLD in loc a l cha rac te rs) and an

A-label.

An A -label is the ASCII form of a n IDN label. Eve ry IDN A-

lab el be gins with the IDNA ACE p refix, xn--, follow ed by a

string t ha t is a va lid o utput of the Punycod e a lgorithm,

ma king a ma ximum of 63 tota l ASCII c harac ters in leng th.The p refix and string tog ether must c onfo rm to a ll

req uirem ents for a lab el that c an be stored in the DNS

including c onformanc e to the LDH (host na me) rule

described in RFC 1034, RFC 1123, and elsew here.

8The 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.
http://www.icann.org/en/topics/new-gtld-program.htmhttp://www.icann.org/en/topics/new-gtld-program.htmhttp://icann.org/en/topics/idn/rfcs.htmhttp://icann.org/en/topics/idn/rfcs.htmhttp://icann.org/en/topics/idn/rfcs.htmhttp://www.icann.org/en/topics/new-gtld-program.htm


35/291



A U-label is the Unic od e form o f an IDN lab el, wh ich a user

expec ts to see d isplayed in applica tions.

For exa mple, using the c urren t IDN test string in Cyrillic

sc rip t, the U-label is and the A-labe l is . An A-lab el must be c ap ab le of be ingprod uc ed by c onve rsion from a U-labe l and a U-lab el must

be ca pa ble of being produc ed by c onversion from a n A-

label.

Ap p licants for IDN gTLDs will also b e req uired to p rovide the

follow ing a t the time of the a pp lica tion:

1. Me aning or resta teme nt o f string in Eng lish. The

ap plica nt will provide a short desc ription of wha t the

string wo uld me an o r rep resent in Eng lish.

2. Langua ge of lab el (ISO 639-1). The a pp lic ant w ill

spe c ify the langua ge of the ap plied-for gTLD string,

bo th ac c ording to the ISO c od es for the representa tionof na me s of language s, and in Eng lish.

3. Sc ript of lab el (ISO 15924). The app lic ant w ill spec ify the

sc ript o f the app lied -for gTLD string, bo th a c c ording to

the ISO c od es for the representa tion of na me s of

sc rip ts, and in Eng lish.

4. Unicod e c od e p oints. The a pplica nt w ill list a ll the c od e

po ints conta ined in the U-lab el ac c ording to its

Unicod e form.

5. Ap p lic ants must further dem onstrat e tha t they ha ve

ma de rea sonab le e fforts to e nsure tha t the e nco de d

IDN string d oes not c ause a ny rend ering or op erationa l

p rob lems. For examp le, p rob lems have b ee n identified

in strings w ith cha rac te rs of m ixed right-to -left a nd left-

to-right d irec tionality when numera ls are adjac ent to

the p a th sep arato r (i.e., the d ot).9

If an app lic ant is app lying for a string w ith known issues,

it should d oc ume nt step s tha t will be ta ken to mitigat e

the se issues in app lic a tions. While it is no t p ossible to

ensure t hat a ll rend ering prob lems are a voide d , it is

imp ortant t ha t a s ma ny as po ssible a re identified ea rly

and tha t the p ote ntial reg istry operato r is aw a re o f

these issues. App lic ant s c an be c om e fam ilia r with

these issues by und ersta nd ing the IDNA p rotoc ol (see

http://www.icann.org/en/topics/idn/rfcs.htm), and b y

ac tive p artic ipa tion in the IDN wiki (see

http://idn.icann.org/) whe re som e rend ering p rob lems

are de monstrate d.

9See examples athttp://stupid.domain.name/node/683
http://www.icann.org/en/topics/idn/rfcs.htmhttp://www.icann.org/en/topics/idn/rfcs.htmhttp://idn.icann.org/http://idn.icann.org/http://stupid.doma

Gtld Registration Manual

Documents

Transcript of Gtld Registration Manual