Idn Cctld Implementation Plan 30sep09 En

8/14/2019 Idn Cctld Implementation Plan 30sep09 En

1/59

1

Proposed Final

Implementation Plan for

IDN c cTLD Fast Track

ProcessPlease no te tha t this is a p roposed fina l plan. Potential IDN cc TLD req uesters shou ld no t rely on anyof the p ropo sed de tails in the information c onta ined he re as the p lan remains sub jec t to furtherc onsultation, inc lud ing ICANN Boa rd c onsiderat ion.

30 September 2009


2/59

2

Table of ContentsModule 1 General Introduction .................................................................................................... 3

Module 2 Participation Eligibility Requirements ........................................................................... 4

2.1 ISO 3166-1 Representation ................................................................................................ 4

2.2 Requester of an IDN ccTLD ................................................................................................. 4

Appendix 1 to Module 26

Module 3 TLD String Criteria and Requirements.7

3.1 General String Criteria..7

3.2 Language and Script Criteria.7

3.3 Meaningfulness Requirement...8

3.4 Number of Strings per Country or Territory....9

3.5 Technical String Criteria.10

Appendix 1 to Module 3.13

Module 4 DNS Stability Panel..15

4.1 DNS Stability Panel Function....15

Module 5 Request Submission for String Evaluation ................................................................... 17

5.1 General Fast Track Process Overview ............................................................................... 17

5.2 Submission of an IDN TLD Fast Track Request .................................................................. 19

5.3 ICANN Staff Support and Contact Functions .................................................................... 20

5.4 Termination Process for Submitted Requests .................................................................. 21

5.5 Contention Issues .............................................................................................................. 22

5.6 Processing of a Track Request .......................................................................................... 22

Appendix 1 to Module 5 ............................................................................................................. 26

Appendix 2 to Module 5 ............................................................................................................. 32

Module 6 Delegation Process ..................................................................................................... 33

6.1 IANA Function ................................................................................................................... 33

6.2 ICANN Board Review Process ........................................................................................... 34

6.3 US Government Authorization .......................................................................................... 35

Module 7 Relationship IDN ccTLD and ICANN ............................................................................ 36Appendix 1 to Module 7 ............................................................................................................ 37

Module 8 Fee Structure and Model ............................................................................................ 53

Appendix 1 to Module 8 ............................................................................................................ 55

Module 9 Process Review and Revision ...................................................................................... 57

Module 10 Background Information ........................................................................................... 58


3/59

3

Module 1General Introduction

This is the p roposed Final Imp lementa tion Plan for the IDN c c TLD Fast Trac kProc ess.

The p lan is based on recomme ndat ions p rovided by the IDNC Working Group(WG) in its Final Report, a s we ll as on p ublic c omme nts p rovided througho ut theIDNC WG s online a nd pub lic c omm ent fac ilit ies, and on p ublic c omm entsrec eived on the p revious d raft versions of the p lan. For a full overview ofc onsulta tions and review see Mod ule 10.

The p lan is p resented in modules as follow s:

Module 1: General Introd uc tion

Mo dule 2: Fast Trac k Elig ibility Req uirem ents

Mo dule 3: TLD String Criteria a nd Req uirem ents

Mo dule 4: DNS Sta b ility Pane l

Mo dule 5: Req uest Sub mission & String Eva luat ion

Mo dule 6: Req uest Submission fo r Delega tion Eva luation

Mo dule 7: Rela tionship b etwe en IDN c c TLD and ICANN

Module 8: Fee Struc ture a nd Mode l

Mo dule 9: Process Review and Revision

Module 10: Bac kground Informa tion

The plan is pub lished for co mm unity informa tion a nd ICANN Boa rd c onsiderationin prep ara tion for the ICANN m ee ting in Seo ul, Korea , 26-30 Oc tob er 2009.
http://www.icann.org/en/announcements/announcement-15jul08-en.htmhttp://www.icann.org/en/announcements/announcement-15jul08-en.htmhttp://www.icann.org/en/announcements/announcement-15jul08-en.htmhttp://www.icann.org/en/announcements/announcement-15jul08-en.htmhttp://www.icann.org/en/announcements/announcement-15jul08-en.htmhttp://www.icann.org/en/announcements/announcement-15jul08-en.htm


4/59

4

Module 2Eligibility Requirements

Particip at ion in the IDN cc TLD Fast Trac k Proc ess is limited in ac c orda nc e with t heIDNC WG rec om me nda tions, and as d isc ussed in this mo dule. Therec omme ndat ions and their inherent limitations we re a rrived a t throughc om munity co nsultat ions, as desc ribed in Mod ule 10. The p rima ry rea sons forimplementing limitations are that the process is experimental1

2.1 ISO 3166-1 Representation

in nature a ndshould no t pre-emp t the outc om e o f the ong oing IDN cc NSO Polic yDeve lopme nt Proc ess. Limitat ion aspec ts rela ted to the string c riteria andreq uirements are p resented in Mod ule 3.

To b e e lig ible to en te r the IDN cc TLD Fast Trac k Proc ess, the c ount ry or te rritorymust b e listed in the Inte rna tiona l Sta ndard ISO 3166-1 (Cod es for therep resent a tion o f na me s and c ount ries and the ir subd ivisions Pa rt 1: Country

Codes). The e xcep tion to this requireme nt is the a dd itiona l eligibility of theEurop ea n Union, whic h has an e xcep tionally reserved c od e d esignate d b y theISO 3166 Ma intena nc e Ag enc y (seehttp://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EU) and has also b een d eem ed eligible under ICANNpo lic y for a c ountry-c od e top -level dom ain.

A c ountry or territory rep resented on the ISO3166-1 list is eligible t o pa rticipa te inthe IDN c c TLD Fast Trac k Proc ess and to request a n IDN c c TLD string tha t fu lfills thead ditional requirem ents set forth in Mo dule 3.

2.2 Requester of an IDN ccTLD

The Fast Trac k Proc ess is d ivided into three d istinc t sta ges, as d isc ussed in morede ta il in Mod ule 5:

Sta ge 1: Prep a ra tion Sta ge; Sta ge 2: Req uest Sub mission for String Eva luation ; and Sta ge 3: Req uest Sub mission for Delega tion Eva luation .

The e ntity ac ting a s the req uester, and tha t submits the req uest for an IDN cc TLDto ICANN for stage 2, c an be the ide ntified IDN cc TLD ma nage r (prop osedsponsoring organiza tion), or the relevant go vernment or pub lic authority, or theirde signa ted rep resenta tive.

If the req ueste r is the IDN cc TLD ma na ge r (this ma y be the existing c ount ry-codetop -level d oma in manag er for the ISO 3166-1 co de, or a d ifferent e ntity) orgo vernment d esignat ed rep resenta tive, it must ha ve the supp ort from thec ount ry or territory co rrespond ing to the releva nt ISO 3166-1 entry, and must

1 It is impo rtant to note tha t by experimental, the w orking group w as co mme nting on the p olicy aspe cts of IDNintrod uction a nd no t the tec hnical aspe cts. IDNs have b een te sted in the roo t zone a nd te chnic al implic ations of theintroduction are generally well understood. All studies will be completed to ensure there is a full understanding that IDNswill have no delete rious effe c ts on DNS interop erab ility, stability and sec urity.
http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EUhttp://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EUhttp://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EUhttp://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EUhttp://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EU


5/59

5

sa tisfac torily and c learly d oc ume nt this supp ort. The doc ume nta tion of suppo rtmust evidenc e support from the releva nt go vernme nt or pub lic a utho rity. This isdefined as a signed let ter of support, from the M iniste r w ith the portfolioresponsible for dom ain name administration, ICT, foreign a ffairs or Office of thePrime Minister or President; or from a senior rep resent a tive o f the agenc y ordep artment responsible for do ma in nam e a dministration, ICT, Foreign Affairs orthe Office of the Prime Ministe r.

The let ter should c lea rly express the gove rnment or pub lic autho ritys support for

the request and de mo nstrate the government s or pub lic a uthoritysund ersta nd ing of the string b eing req uested a nd its intend ed use. The lettershould a lso d em onstrat e the go vernments or pub lic authority unde rstand ing tha tthe string is being sought throug h the IDN c c TLD Fast Trac k Proc ess and tha t thereq uester is willing to ac c ep t the c ond itions unde r which t he string w ill beava ilab le, i.e., as out lined in this Final Imp leme nta tion Plan.

If there is reason fo r doub t of the a uthenticity of the lette r, ICANN w ill consult withthe releva nt dip loma tic authorities or membe rs of the G AC for the go vernment o rpub lic authority co nce rned.

To further assist the req ueste r in de termining w ho the relevant g ove rnment orpub lic authority ma y be for a reque st, the req uester ma y wish to c onsult w ith the

releva nt GAC rep resent a tive. Seehttp:// ga c .ic ann.org/ inde x.php ?name =Rep resentatives&mo de =4

An exam ple o f a supp ort lette r is included in App end ix 1 to this Mod ule 2.
http://gac.icann.org/index.php?name=Representatives&mode=4http://gac.icann.org/index.php?name=Representatives&mode=4http://gac.icann.org/index.php?name=Representatives&mode=4


6/59

6


Sample: Documentation of support for the request from the government or relevantpublicly authority for the country or territory.

The IDN c cTLD req uest must be e ither from the gove rnment or releva nt p ub lic autho rity, or support from thego vernment or pub lic autho rity must be included in the request.

This is a guiding e xamp le of w ha t such d oc ume nta tion of supp ort ca n look like:

To: ICANN4676 Ad mira lty Way, Suite 330Ma rina del Rey, CA 90292-6601USA

At tent ion: IDN cc TLD Fa st Trac k Request

[loc ation, da te]

Sub jec t: Let te r of Support for [U-lab el/ A-lab el] req uest to ICANN Fast Trac k Process:

This lette r is to c onfirm tha t the [p ub lic authority for c ountry/te rritory] fully supports the Fast Track request

to ICANN co nd uc ted b y [Req ueste r] for the string(s) [A-label/ U-label] to b e used as an IDN cc TLD

rep resenting [c ountry/ territory na me ] o n the Internet.

It is furthe r co nfirme d tha t the name is being soug ht th roug h the ICANN IDN cc TLD Fast Trac k Process

and that t he [Req uester], is willing to ac c ep t the c ond itions unde r whic h the string will be a vailable a s

outlined in the Final Imp lementa tion Plan for the IDN cc TLD Fast Trac k Proc ess.

Sinc erely,

Signat ure from relevant p ublic authority

Name of individua lTitle of individua lName o f dep artment or officePosta l AddressTelep honeEma il ad dress


7/59

7

Module 3TLD String Criteria and Requirements

A c onservative app roa c h for pote ntial IDN cc TLD strings has be en a do pt edbec ause o f the Fast Trac k Proc ess limited introd uc tory nature and t o sa feg uardag ainst pre-emp ting the outc om e of the ong oing IDN c c NSO Polic yDeve lopme nt Proc ess. Limitat ions in this mo dule a re foc used on c riteria a ndrequirem ents set for the TLD string.

3.1 General String Criteria

The follow ing c onta ins som e c larifica tions ab out the ge neral c riteria for arequested IDN c c TLD string:

1. the string must b e a minimum of tw o c ha rac ters long (U-lab el),2. cha rac ters are c ounted as ba sic Unic od e c omp onents,3. the string does not ne ed to b e the entire c ountry or territory nam e, nor do es it

nee d to be a n ac ronym , as long as the string fulfills the me aningfulness c riteriade sc ribed further below ,

4. the string must no t b e longer tha n 63 cha rac ters (A-label).ICANN is no t responsible for IDN usab ility issues in a pp lica tions. The usab ility o f IDNsma y be limited , as not a ll app lication softwa re is capa ble o f wo rking w ith IDNs. Itis up to ea c h ap plic ation deve lop er to dec ide whethe r or not they wish tosup port IDNs. This c an inc lude, for examp le, brow sers, em a il c lien ts, and siteswhe re you e nlist for a service o r purcha se a prod uc t a nd in tha t p roc ess need toenter an ema il address. Suc h usab ility prob lems c urrent ly exist tod ay with theASCII TLDs in som e situa tions where the TLD string is long er than three c ha rac te rs.

Furthe r acc ep ta b ility and usab ility issues ma y oc cur as the IDNA protoc olsta nda rd is revised and as the IDN protoc ol for em a il ma na ge me nt is finalized inthe Inte rnet Eng inee ring Task Force (IETF). The result o f the IDNA p rotoc ol rev isionwill be that som e c harac ters previously not p ermitted within IDNs will be c om eva lid . ICANN will ac c ep t req uests for strings w ith these newly-va lid c ha rac ters,but until the new , revised stand ard is imp leme nted and broad ly ad op ted byrelevant app lica tion d eve lope rs, users ma y expe rience p rob lems with using theIDN. This ma y have d ifferent results in different a pp lic at ions, and in som einstanc es a user ma y exp erienc e no func tionality at a ll. It would b e a pp rop riatefor all IDN TLD ma nagers to p rovide t heir users w ith informa tion a bout thelimita tions of use o f IDNs and a t the same time prom ote the use o f IDNs toac hieve glob a l IDN imp leme nta tion ac ross app lic a tions. ICANN supp orts suc h

efforts but is not a ble to enforce or req uire the m.

3.2 Language and Script Criteria

The c ond itions for allow ab le languag es and sc ripts to be used for the reque stedTLD string a re a s fo llow s:


8/59

8

The languag e must be a n offic ial langua ge in the c orrespond ing co untry orterritory, and ha ve leg a l sta tus in the c ount ry or territory, or serve a s a lang ua geof administration.

The language requirem ent is c onsidered verified as follows:

If the lang uage is listed for the releva nt c ount ry o r territory as an ISO 639lang uage in Part Three o f the Tec hnica l Refe renc e Ma nual for thestandardization of Geographical Names,United Nat ions Group of Experts onGeographical Nam es(UNGEGN Ma nual )(http://unstats.un.org/unsd/geoinfo/default.htm); or

If the langua ge is listed as an a dministrative lang uag e fo r the relevant c ountryor territo ry in the ISO 3166-1 sta nd ard und er colum n 9 or 10; or

If the relevant pub lic authority in the c ount ry or territory c onfirms tha t thelang uage is used or served as follows, (either by lette r or link to the releva ntgo vernment c onstitution or othe r online doc umenta tion from a n offic ialgovernment website):

a . used in offic ial com munica tions of the relevant p ublic a uthority; andb . serves as a language of administration.

Language s based on the La tin sc ript a re not eligible fo r the Fast Trac k Process.Tha t is, the req uested string must no t c onta in the c ha rac ters (a,,z), either in the irbasic fo rms or with d iac ritic s.

An exam ple o f a lette r c onfirming tha t the lang uag e used is official is included forguida nc e; see Appe nd ix 1 to this Module 3.

3.3 Meaningfulness Requirement

The IDN cc TLD string (s) must b e a me aningful rep resenta tion o f the na me of thec orrespond ing c ount ry or territory. A string is dee med to b e m ea ningful if it is in

the offic ial lang uag e o f the c ountry or territory and if it is:

The na me of the c ount ry or territory; or A pa rt of the name o f the co untry or territory deno ting the c ountry or

te rritory; or

A short-form de signa tion for the na me of the c ountry or territory tha t isrec og nizable a nd denot es the c ountry or territory in the selec tedlanguage.

The m ea ning fulness requirem ent is verified as follow s:

1. If the requested string is listed in the UNGEGN M anua l, the n the string fulfills themeaningfulness requirement.

2. If the req uested string is not listed in the UNGEGN M anua l, then themeaningfulness must be substantiated by the requester providingdoc ume nta tion from a n internationally rec og nized expe rt or organizat ion.

ICANN will rec og nize the following as internationa lly rec og nized expe rts ororganizations:


9/59

9

a ) Nationa l Naming Authority a g overnment recog nized Nationa l Geo grap hicNaming Autho rity, or other organizat ion pe rforming the same function, for thec ountry or te rritory for whic h the IDN cc TLD Fast Trac k req uest is p resented . TheUnited Nat ions Group of Experts on Geo graphica l Name s (UNGEGN) ma inta inssuc h a list o f orga niza tions a t:http :// unsta ts.un.org/ unsd / geo info/ Autho rities_listJan09.pd f

b ) Nat iona l Linguistic Autho rity a gove rnment rec og nized Nat iona l LinguisticAuthority, or other orga niza tion performing the sam e func tion, for the c ountry

or te rritory for which the IDN cc TLD Fast Trac k req uest is p resented .

c ) ICANN agreed expert or organiza tion in the case w here a c ountry or territorydo es not have a c cess to either of the a bo ve, it may req uest a ssista nce fromICANN to iden tify and refe r a rec og nized experts or organiza tion. Any expe rtisereferred from or agreed to b y ICANN will be c onside red ac ce pta ble a ndsufficient to determine whether a string is a meaningful representation of acountry or territory name.

This assistanc e c an be requested by c onta c ting ICANN a [email protected]

An exam ple o f a lette r from an interna tiona l rec og nized expert or orga niza tion,c onfirming the meaningfulness of the req uested string is atta c hed for guidanc e;see Appe ndix 1 to this Module 3.

3.4 Number of Strings per Country or Territory

The num ber of strings tha t a c ount ry or territory c an app ly for is not limited to aspec ific num be r (in ac c orda nc e w ith Guiding Principle G in the IDNC WG FinalRep ort). How ever, the follow ing m aximum limitation ap plies:

One string per official language or script per country or territory.This limita tion m ay cause issues for some c ount ries and te rritories which ha ve

expressed the imp ortanc e of ha ving variant TLDs a lloc at ed and delega ted in theDNS.

The to p ic o f de lega tion of va riant TLDs and ma na ge me nt of va riant TLDs hasbe en d isc ussed b roa dly in the c om munity. ICANN sta ff has p rop osed a fewmod els, none of which we re a greeab le ac ross the p olicy a nd te c hnic alc omm unity review ing the top ic.

In orde r to sta y within ICANN s ma nd ate fo r ensuring a sta b le and sec ureop erat ion of the Internet, the follow ing w ill be t he c ase for the Fast Trac k Process

launch:

Variant TLDs de sired by the req uester for de lega tion must b e indica ted bythe req uester

Desired va riant TLDs will be a lloc a ted t o the req ueste r (if suc c essfullyeva lua ted ). This does not mean tha t the variant TLD will be de lega ted inthe DNS roo t zone . It w ill be alloca ted to the req uester in orde r to b ereserved to the entitled ma nage r for potential future d elega tion in theDNS root zone.

A list of no n-desired variants will be ge nerated ba sed on the rec eived IDNTab les. Non-desired va riants will be p lac ed on a b loc ked list by ICANN.
http://unstats.un.org/unsd/geoinfo/Authorities_listJan09.pdfmailto:[email protected]:[email protected]:[email protected]://unstats.un.org/unsd/geoinfo/Authorities_listJan09.pdf


10/59

10

Subseq uent ap p lic ation or req uest for non-desired variant s will be denied .

The c om munity is expec ted to c ontinue working on m ore c lear definitions ofva riants, solutions or methods for de lega tion o f variants, and any nec essa rydispute me c hanisms relate d to d isagreem ent rega rd ing desired and non-de siredva riants. For the p urp ose o f includ ing ne w deve lopme nt in the Fast Trac k Proc ess,it is sc hed uled for revision. See Mo dule 9 for m ore d eta ils.

3.5 Technical String Criteria

This sec tion d esc ribes tec hnic a l c rite ria fo r IDN c cTLD strings. Othe r technic a lrequirements related to delegation (such as name server requirements) arec onsidered in Mod ule 6.

Meeting all the te chnica l string requirem ents in this sec tion d oes not gua ranteeac c ep tanc e o f a p rospe c tive top -leve l string, since the follow ing subsec tions donot c onta in an exhaustive list o f a ll req uirem ents or restric tions. Tec hnica lrequirem ents for IDN c c TLD strings and IDN gTLD strings a re eq uiva lent and a reesta b lished by tec hnica l sta nda rds deve loped by the IETF.

The IETF is c urren tly fina lizing a revised spec ific a tion for the IDNA p rotoc ol. Thisma kes c hang es to the list of charac ters tha t ma y be inc luded in an IDN,reflect ing ad ditions ma de to Unicod e since the relea se of the o riginal protoc ol,and eliminating a numb er of symb ols and othe r marks tha t a re no t used forwriting wo rds in any lang uag e (and w hich we re invalid c ha rac ters in an IDN perthe IDN Guide lines). The fo llow ing rema rks a re intended to c larify for prospec tivereq uesters the key differenc es betw ee n the o riginal and revised versions of theprotoc ol, pa rticu larly a s they relate to TLDs.

The m a in technica l deta il that a nam e ho lder need s to a dd ress is the c onversionof a name from its U-label form (as d isp layed using Unico de c ha rac ters) to its A-lab el form (as stored in the DNS with a seq uenc e o f ASCII cha rac te rs). ICANNrequires bot h suc h strings in a req uest for an IDN cc TLD. Tools a re ava ilab le tha tpermit this c onve rsion to be d one for the initia l version of the p roto c ol (IDNA2003)The deve lopment of simila r tools for the revised p roto c ol version (IDNAbis aka

IDNA2008) is in prog ress b ut no ne are ye t a va ilab le for ge neral use. In the inte rim,assessing the c onfo rmity of a string to t he revised p roto c ol can req uire som ead ditional d evelopme nt a nd evaluation effort. One p artic ularly notew orthyd istinct ion is tha t IDNA2003 c an change a U-label during the round -tripconversion from U-label to A-label and back to U-label, whereas IDNA2008 never ma ps any c harac ter in a U-lab el to some other charac ter.

The d eve lopm ent o f supp ort for IDNA2008 in the b roa de r softwa re a pplica tionsenvironm ent will oc c ur grad ually. During tha t time , TLD lab els tha t a re valid und erIDNA2008, b ut no t und er IDNA2003, w ill have limited func tiona lity. Conversely,

lab els tha t a re va lid under IDNA2003 but not under IDNA2008 ma y ultima telybe c om e entirely dysfunctiona l. Lab els of the latter type will therefore not bepermitted for TLDs and requests for suc h strings w ill be d ec lined .

Labels tha t a re va lid only und er IDNA2008 will be a llow ed , but req uesters a restrong ly advised to not e tha t the d urat ion of the transition p eriod betw een thetwo p rotoc ols c annot p resently be estimat ed nor gua ran teed in any spe c ifictimeframe.

As a gene ra l rule, a label is va lid und er bo th IDNA2003 and IDNA2008 if it d oes no tinclude c ha rac ters that a re b eing remo ved from the list p ermitted by IDNA2003,and it reta ins its origina l form a fter the U-label to A-label to U-label round trip using


11/59

11

IDNA2003 c onversion to ols. No string failing this round -trip te st w ill be ac c ep ted fora TLD.

Ma nual inspe c tion of a ll labels that do p ass the t est w ill be nec essary to e xcludelabels tha t c onta in cha rac ters that are p ermitted by IDNA2003 but a re invalidunde r IDNA2008, and to va lida te lab els c onta ining c ha rac ters that a re onlyava ilab le under IDNA2008. The te rms of the IDN cc TLD Fast Trac k Proc esstherefore effec tively exc lude c ha rac ters tha t are being rem oved from theIDNA2003 list, in a ny c ase. Cha rac te rs being introd uc ed in IDNA2008, how eve r,

might ap pea r and will be a c c ep ted in IDN TLD req uests.

A full list o f cha rac te rs tha t a re jointly pe rmissible in IDNA2003 and IDNA2008 isprovided tog ethe r with a list of c harac ters be ing rem oved from the IDNA2003rep ertoire, and the c ha rac ters be ing ad de d in IDNA2008 (of which a numb er areonly ac c ep tab le in the indic at ed spe c ific c ontexts). These lists have b eenc ollate d from the m ost rec ent d ra ft version of the IETF doc ume nt, whic h is a w orkin progress, loc at ed at :

http://tools.ietf.org/wg/idnabis/

The lists a re loc a ted a thttp://www.icann.org/en/topics/idn/fast-track/

The referenc e U-lab el/ A-label conve rsion fac ility for IDNA2003 is loc a ted a t:

http://josefsson.org/idn.php/

3.5.1 Technical String Requirements

The follow ing are ge neral technica l req uirem ents that m ust be c om plied w ith forthe IDN cc TLDs in A-lab el2

The A-label (i.e., the lab el as transmitted on the w ire) must be va lid a s spec ified intec hnica l standards for Doma in Nam es: Imp lem entation a nd Spe c ific ation(RFC1035); and Clarifica tions to t he DNS Spec ific a tion(RFC 2181). This inc lud es:

format.

The la bel must ha ve no m ore tha n 63 cha rac ters. This includ es the p refix(the four initial cha rac te rs xn-- ).

Upp er and lowe r c ase c ha rac ters a re c onsidered to b e syntac tica lly andsem antica lly ide ntica l.

The A-lab el must b e a va lid host na me , as spe c ified in tec hnic al stand ard DODInte rnet Host Tab le Spec ific at ion(RFC 952) ; and Req uirem ents fo r Internet Hosts App lication a nd Supp ort(RFC 1123). This inc lud es:

The la bel must c onsist en tirely of let te rs, d igits and hyp hens.The req ueste r is expec ted t o b e fa miliar with the IETF IDNA sta nd ards, Unic od estandards, and IDN terminology.

The string m ust be a va lid inte rna tiona lized dom ain nam e, as spec ified intec hnica l standards http:/ / ww w.ic ann.org/ en/ top ics/ idn/ rfcs.htm or any revisionsof this technica l sta nda rd c urrent ly under c onside ra tion b y the IETF as d isc ussed

2 A domain name consists of a series of "labels" (separated by "dots"). The ASCII form of an IDN label is termed an "A-label". All operations defined in the DNSprotocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a "U-label".
http://tools.ietf.org/wg/idnabis/http://tools.ietf.org/wg/idnabis/http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/http://josefsson.org/idn.php/http://josefsson.org/idn.php/http://josefsson.org/idn.php/http://www.icann.org/en/topics/idn/fast-track/http://tools.ietf.org/wg/idnabis/


12/59

12

ab ove . The following is presente d as guide lines only and a re no t a c om pletesta teme nt o f the requireme nts for IDNA spec ific a tions. The string :

Must co nta in only Unicod e c od e points tha t are defined a s Protoc olValid and be ac c omp anied b y unamb iguous c ontextual rules wherenecessary.

Must be fully co mp liant w ith Norma liza tion Form C, as d esc ribed inUnicod e Sta nd ard Annex # 15: Unico de Norma liza tion Forms. Examplesap pea r in http://unicode.org/faq/normalization.html

The string must c onsist entirely of c ha rac te rs w ith the same d irec tiona lp rop erty. This req uirem ent ma y change a s the IDNA protoc ol is beingrevised to a llow for cha rac ters having no d irec tional property (as defineda t http:/ / unic od e.org/ Pub lic / UNIDATA/ extrac ted / DerivedBidiClass.txt ) tobe a vailab le a long w ith either a right-to-left or a left-to-right d irec tionality.

The string must no t beg in or end with a d igit (in any sc ript).The string must mee t the c riteria of the c urrent or any subseq uent ve rsions of theICANN Guide lines for the Implem enta tion of Internat ionalized Doma in Nam es. Thisincludes:

All c od e p oints in a single string must be ta ken from the same sc rip t asde termined b y the Unicod e Sta nd ard Annex # 24: Unicod e Sc ript Prop erty

Exceptions to this guide line a re permissible fo r lang uage s w ith esta b lishedorthograp hies and c onventions that require the c om mingled use of m ultip lesc ripts. How eve r, eve n w ith this excep tion, visua lly c onfusab le c ha rac ters fromdifferent sc ripts w ill not b e a llow ed to c oe xist in a single set of p ermissible c od epo ints unless a c orrespo nd ing po lic y and c harac ter tab le are clea rly defined.Furthe r, the IDN Guidelines c onta in a req uirem ent for IDN reg istries to d eve lop IDNTab les. The IDN Tab le(s) must be submitted to ICANN with a req uest for an IDNc cTLD.

The IDN ccTLD req ueste rs a re e nc ourag ed to :

1. Use and refe r to a lrea dy existing IDN Tab les2. Coop erate in de velopme nt of the IDN Table(s).
http://unicode.org/faq/normalization.htmlhttp://unicode.org/faq/normalization.html


13/59

13


Sample: Documentation that the selected language(s) is considered official in thecountry/territory.

The IDN ccTLD string(s) tha t is requested throug h the Fast Trac k Proc ess must be in an offic ial lang ua ge o f thec orrespond ing co untry or territory. A lang uag e c an be d emonstra ted to b e official if the relevant p ublic

autho rity in the c ountry or territory c onfirms tha t the langua ge is used in offic ial co mm unic a tions of the relevant

pub lic autho rity and serves as a langua ge of a dministration.

This is a guiding exam ple of w ha t such c orrespond enc e c an look like:

------------------------------------------------------------------------------------------------------------------------------------------------------------------

To: ICANN

4676 Ad mira lty Way, Suite 330

Marina del Rey, CA 90292-6601

USA

[loc ation, da te]

Sub jec t: Confirma tion o f Officia l Language fo r ICANN Fast Track

This lette r is to c onfirm tha t language X (ISO 639 c od e = XX) in c onjunc tion w ith sc ript Y (ISO 15924 cod e

= ZZYY) is used in offic ial com munica tions by the g ove rnment of c ountry 1 (ISO3166-1 cod e = AA) and

serves as a language of administration.

Sincerely,

Signat ure from relevant p ublic authorityName of individua lTitle of individua lName o f dep artment or offic ePosta l AddressTelep honeEma il ad d ress


14/59

14

Sample: Documentation that demonstrates the requested string(s) is a meaningfulrepresentation of the corresponding country/territory.

The IDN ccTLD string(s) tha t is requested throug h the Fast Trac k Proc ess must be a mea ning ful rep resenta tion o f

the correspond ing c ountry or territory name .

A string c an be dem onstra ted to b e m ea ningful ba sed on a rep ort from an internationa lly rec og nised linguistic

expe rt(s) or internationa lly rec og nised orga nisa tion tha t the selec ted string m ee ts the c riteria

This is a guiding exam ple of w ha t such c orrespond enc e c an look like:

------------------------------------------------------------------------------------------------------------------------------------------------------------------

To: ICANN

4676 Ad mira lty Way, Suite 330

Ma rina del Rey, CA 90292-6601

USA

[loc ation, da te]

Sub jec t: IDN cc TLD string me aningfulness rep ort deve loped for [A-label/ U-label]

This rep ort has bee n de velop ed for:

[insert co nta c t deta ils for the req uester]

In the experts opinion the string [A-label/U-label] constitutes a meaningful representation of the

count ry/ territory nam e [insert na me ]. The deta iled informa tion relat ing to this assessme nt is as follows:

Country/territory na me = [insert]

ISO 3166-1 cod e = [insert]A-label = [insert]

U-lab el = [insert]

Meaning of the name (string) in Eng lish = [list]

ISO 639 lang uage c od e = [insert]

ISO 15924 sc rip t c od e = [insert]

In the expe rt s op inion, the req uested IDN cc TLD string is c onsidered a me a ningful

[ac ronym/ ab breviation/ othe r] of the c ountry/ territory name. In the eva luation of the mea ningfulness of the

string the following justifica tion ha s been used :

The string is offic ially rec og nized as the na me of the c ountry by the g overnment/ pub lic autho rity per thefollowing decrees: [insert explanation]

The string is used as a sec ond level d om ain name und er the ISO3166-1 cc TLD for Co untry 1 and is reg istered tothe g overnment o f Country 1.

[insert other justific at ions as app lic ab le]

[Insert signa ture from linguistic expert(s)/ orga niza tion]


15/59

15

Module 4DNS Stability Panel

The role a nd responsibility of the DNS Sta b ility Pane l is to p rovide externa l andindep ende nt ad vic e to the ICANN Boa rd a bo ut whether, ba sed on thedo c ume nta tion p rovided by t he IDN cc TLD req uester, a selec ted string me ets thereq uired technica l crite ria. If the DNS Sta b ility Panel finds tha t the selec ted stringdo es not me et one or more o f the c riteria, the request for the IDN c c TLD w ith tha tpa rticu lar selec ted string is not eligible und er the Fast Trac k Proc ess. How ever, thePanel c an seek further clarific a tion from the req uester, if dee me d nec essa ry b ythe Panel, be fore p roviding its findings on the requested string .

ICANN w ill sec ure the servic es of a c om pete nt DNS Sta b ility Panel to ma ketec hnica l sta b ility eva luations. In their ac tions and sta teme nts as Panel me mb ers,these experts do no t represent either the ir a ffilia ted orga niza tions or the c ount ry inwhic h they reside in any w ay.

ICANN ha s c ont rac ted with Interisle Consulting Group (http://www.interisle.net/)to coo rdina te the DNS Sta b ility Panel. The Pane l will consist o f six experts, with theab ility of the Panel to c a ll upon linguistic e xpertise in consultat ion with ICANN.

Panel mem be rs will be expe rts in the d esign, ma nage me nt and implementa tionof the c om p lex system s and sta nd ards-protoc ols utilized in the Internetinfrastructure a nd DNS. Panel me mb ers must ha ve expertise in the tec hno logyand prac tica l imp leme ntation and de ployment o f the DNS in the Internet, andknowled ge of Internationalized Doma in Nam es and the IDNA Protoc ol.

The DNS Sta b ility Pane l will co nd uc t the review of req uested strings in the FastTrac k Proc ess for con formity w ith the TLD String Criteria. The Pane l will a lso reviewrequested strings for con fusab ility w ith existing TLDs, other TLDs requested in theIDN cc TLD Fast Trac k Proc ess, and app lied -for strings in the new gTLD Proc ess.

ICANN w ill c rea te ba tc hes of strings rec eived for the Fast Trac k Proc ess on amo nthly ba sis, sta rting one m onth follow ing the launc h of t he p roc ess, and deliverthe b atc hes to the Panel for review .

4.1 DNS Stability Panel Function

A c ore piec e o f the IDNC WG Final Rep ort is tec hnica l rec om me nda tions toensure sta b le and sec ure op erat ions of the DNS. These te c hnica l req uirem ent sare outlined in Mo dule 3. All req uests in the Fast Trac k Proc ess must suc c essfullypass a DNS Sta b ility Pane l rev iew for the requested IDN cc TLD string to c on tinuethrough the Fast Trac k Proc ess.

The ent ire DNS Sta b ility Panel c ond uc ts an initia l eva luation on a ll stringssub mitted in the Fast Trac k Proc ess.

If the Panel ide ntifies tha t a reque sted string ma y raise significant sec urity andsta b ility issues, or is c onfusing ly simila r to an existing TLD or app lied -for TLD, a three -mem be r extended review tea m (RT) may be c rea ted to co nduc t a mo re

de tailed evaluation of the string. Such d eta iled review ma y be co nduc ted whenthe e ntire Panel lac ks sufficient expertise to determine whether the requestedstring raises sign ific ant sec urity a nd sta b ility issues, but th is is no t expe c ted to be a
http://www.interisle.net/http://www.interisle.net/http://www.interisle.net/http://www.interisle.net/


16/59

16

rare oc c urrenc e. The RT ma y dec ide the need for ad ditional expertise a nd m ayselec t a new ind ividua l expert to take p a rt in the extende d review .

None of the RT me mb ers sha ll have a n existing c ompetitive, fina nc ial, or leg a lc onflic t of interest, and me mb ers shall be selec ted with due rega rd to thepa rticu lar tec hnical issues ra ised by the refe rra l.

In the eve nt tha t a nee d for linguistic expertise is iden tified , the Panel w ill consultwith ICANN staff on linguistic resources.

Usua lly the Pane l will conduc t its review within 30 days and deliver a rep ort toICANN sta ff.

The Pane l may seek cla rific a tion from the req uester if nec essary. A more d et a iledreview is likely not to be nec essary for a string tha t fully c om p lies w ith the stringrequirements referenced in Module 3. However, the string review processprovides an a dd itiona l sa feg ua rd if unant icipa ted sec urity or sta b ility issues a risec onc erning a req uested IDN cc TLD string .

If the Panel dete rmines that the req uested string d oes not c om ply with releva ntstandards or c rea tes a c ond ition tha t ma y ad versely affec t the throug hput,response time , consistenc y or c ohe renc e of responses to Internet servers or endsystem s, then the find ings will be c om munica ted to ICANN sta ff and from ICANN

Sta ff to the req uester.

The req uest fo r an IDN cc TLD c annot p roc eed through the Fast Trac k Proc ess ifthe Panel ident ifies tha t a req uested string ra ises signific ant sec urity a nd stab ilityissue s.


17/59

17

Module 5Request Submission for String Evaluation

This mod ule c onta ins deta ils of the p rocess for requesting an IDN ccTLD stringund er the Fast Trac k Proc ess, inc luding instructions for com pleting and submittingreq uired supp orting d oc umenta tion and othe r nec essary ma teria ls.

This mo d ule a lso e xplains how to req uest a ssista nc e c onc erning the p roc ess, andthe c ircum stanc es under which a subm itted req uest c an be withdraw n orterminated.

5.1 General Fast Track Process Overview

An overview of the en tire IDN c c TLD Fast Trac k Proc ess is p resented in Figure 5.1.The stage s rep resent the three -stage me thod ology:

Sta ge 1: Prep a ra tion; Sta ge 2: Req uest Sub mission for String Eva luation; Sta ge 3: Req uest Sub mission for Delega tion Eva luation .

These three sta ges a re desc ribed b riefly in the fo llow ing sub sec tions 5.1.1 to 5.1.3.The rem aining sec tions in this Mo dule 5 are foc used on Sta ge 2: Req uestSubmission for String Evaluation.

5.1.1 Preparation (Stage 1)

In the Prep aration Stage , the req uester unde rtakes p rep arato ry work to ent er theFast Trac k Proc ess. Prima ry p rep a ra tion ac tivities include identifica tion, selec tion,and d evelopm ent of:

The langua ge(s) and sc rip t(s) for the IDN cc TLD string(s), Selec tion o f the string(s) rep resent ing the name of c ount ry or territory for

the IDN cc TLD(s), and

The d evelop me nt of the assoc iated IDN Tab le(s) and identific ation o f anypote ntial va riant c ha rac ters. The IDN ta b le(s) must be submitte d to ICANNas part of the req uired supp orting d oc umenta tion for the reque st.

In ad dition, at this time the requester deve lops the required doc umenta tion ofend orsem ents. Docum enta tion of e ndo rsem ents must include :

- Doc ume nta tion of supp ort for the request from t he relevant government orpub lic ly authority for the c ountry or territory (if ap plica b le)

o See M od ule 2 for de ta ils and a g uid ing examp le- Doc ume nta tion that the selec ted langua ge (s) is c onsidered o ffic ial in the

country/ territory (if ap plica ble) and in which way it is c onsidered o ffic ial

o See M od ule 3 for de ta ils and a guiding examp le- Doc ume nta tion tha t d emo nstra tes the req uested string(s) is a me aningful

rep resenta tion of the c orrespo nding c ountry/territory (if ap p lic ab le),


18/59

18

o See M od ule 3 for de ta ils and a g uid ing examp le- Doc ume nta tion that the selec ted string(s) and IDN cc TLD ma nag er is

supp orted by the loc al co mm unity,

o The invo lveme nt o f the releva nt stakeho lders in the c ount ry or territoryshould b e d oc umented in a ma nner similar to tha t req uired for asta nd ard c cTLD de lega tion request, by the req uester. Thedo c umenta tion should de monstrate that there has be en c omm unitydia logue regarding w hich string is the a pp rop riate rep resenta tion ofthe c ountry, and tha t ap p rop riate stakeholders have been involved inthe de c ision ma king proc ess.

o Seehttp://www.iana.org/domains/root/delegation-guide/for moreguida nce for the co mm unity supp ort of the IDN cc TLD ma nag er.

o A g uiding desc ription for co mm unity string supp ort is a ttached to thisModule 5, App end ix 2.

The IDN cc TLD ma nag er need not b e a pp ointed until the reque st ha s rea c hedSta ge 3: Req uest fo r Delega tion Eva luation (see Figure 5.1). Req uests can b esubm itted by e ither the ide ntified IDN c c TLD ma na ge r, by the relevantgo vernment o r pub lic autho rity, or by or their designa ted rep resenta tive.

To support the req ueste rs in prep aring req uests, ICANN w ill be launc hing asupp ort func tion for guida nc e a nd supp ort for prep aration or launc h of IDNrela ted ma tte rs. See this Mo dule 5, sec tion 5.3 for mo re d eta ils.

5.1.2 Request Submission for String Evaluation (Stage 2)

In Sta ge 2: Req uest Sub mission for String Eva luation, the requeste r submits areq uest for the selec ted string(s) to b e ve rified by ICANN a s eligible to be arep resent a tion o f the c ount ry or territory. The req uest is review ed through thede fined valida tion step s, inc luding:

Request Completeness Validation Lingu istic Proc ess Va lida tion DNS Stability String Evaluation Pub lishing of Va lida ted Strings

The steps in Sta ge 2 a re desc ribed in further de ta il in sec tion 5.6.

5.1.3 Request Submission for Delegation Evaluation (Stage 3)

Afte r a request has suc c essfully passed Sta ge 2: Req uest Sub mission for StringEva luation, it c an ente r the Sta ge 3: Req uest Submission fo r Deleg a tionEvaluation.

In this pha se, the sta nd ard ICANN IANA proc ess for de lega tions is followe d, asa lrea dy exists for ASCII count ry-code top-leve l dom ains. The ICANN Boa rdap proves the d elega tion.

The process for the Req uest fo r Deleg a tion Eva luation is desc ribed in de ta il inMod ule 6.

Onc e the deleg a tion p roc ess is c onc luded suc c essfully, the string (s) is deleg a tedin the DNS roo t zone , a fter which the d om ain is ac tive and t he IDN c c TLD
http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/


19/59

19

ma nage r can co mm enc e op erations such as ac c ep ting reg istrations within thenew IDN c c TLD.

5.2 Submission of an IDN TLD Fast Track Request

Forma l req uests for IDN cc TLDs c an b e submitte d to ICANN sta rting 16 Novemb er2009. The submission syste m fo r the string eva luation sta ge (Sta ge 2) is a web -based form tha t ident ifies the informa tion nec essa ry. The w eb -ba sed form isava ilab le at http://www.icann.org/en/topics/idn/fast-track/

Figure 5.2 illustrat es the sub mission of a request.

By subm itting the req uest the req uester must a c knowled ge that they und erstandthat usab ility of IDNs ma y be limited in tha t som e softwa re a pplic a tions ma y notbe c apab le of wo rking w ith IDNs. Furthe r, som e a c cep ta b ility and usab ility issuesma y oc c ur as the IDNA p roto col standa rd is revised and the IDN protoc ol forem ail ma nagem ent is finalized in the IETF. Until standa rds a re imp leme ntedbroa dly ad op ted by releva nt applic ation software writers, users ma y experienc edifferent results in different a pp licat ions and ma y expe rience no func tionality a tall.

By subm itting the req uest the req uester ag rees to the terms and cond itionspresented in the online req uest system . The req ueste r ha s the add itiona l op tionsto selec t further a rrangem ents w ith ICANN. See Mo dule 7 for c op ies of a ll suc hmaterial.

The nec essa ry supp orting doc ume nta tion for the string evaluation must b euploa de d in electronic form to the online req uest system and subm itted tog ethe rwith the request to ICANN. In addition supp orting d oc ume nta tion must beprovided in original form to ICANN in signed hard c op y forma t a t the followingaddress:

ICANN4676 Ad mira lty Way Ste 330Ma rina d el Rey, CA 90292USA

Attn: Req uest fo r an IDN cc TLD Fast Trac k

All informa tion p rovided in a req uest must be p rovided in Eng lish or with anac c om panying offic ial Eng lish translation of a ny non-Eng lish informa tion. Anyinformat ion and supp orting d oc ume nta tion not provide d w ill delay processing.

The request submitte d o nline m ust a lso b e p rinted and signed. A signed hard-c op y must b e p ostal ma iled to ICANN at the ab ove a dd ress.

Req uesters tha t a re unab le to utilize the online req uest system for submitting the irreq uest should c onta c t ICANN direc tly [email protected]

The e nd da te fo r submission o f a Fast Trac k req uest w ill be announc ed as soon a sit is known. It is expec ted to last through the a do ption a nd implementa tion of theIDN c cTLD polic y deve lopm ent reco mm end a tions.

Req uests for IDN cc TLDs will be p rocessed ma nua lly due to the e xpec ted limitednumber of req uests. The e xpec ted number of req uests is based on the rep liesICANN rec eived to a req uest for informa tion (RFI) from pote ntial partic ipa nts inthe Fast Trac k Proc ess. A d eta iled ove rview of the responses to t his outrea chac tivity can b e found at:http://www.icann.org/en/announcements/announcement-10feb09-en.htm
http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/mailto:[email protected]:[email protected]:[email protected]://www.icann.org/en/announcements/announcement-10feb09-en.htmhttp://www.icann.org/en/announcements/announcement-10feb09-en.htmhttp://www.icann.org/en/announcements/announcement-10feb09-en.htmmailto:[email protected]://www.icann.org/en/topics/idn/fast-track/


20/59

20

5.3 ICANN Staff Support and Contact Functions

To sup port c ountries and te rritories in pa rticipa ting in the Fast Trac k Process, anICANN po int of conta c t and supp ort function is availab le. The supp ort function,de sc ribed in greate r deta il in the follow ing, is ava ilab le to p rospe c tive req uestersin their prepa ra tion p ha se a s well as a fter the reque sted IDN cc TLD(s) a redelegated.

During the en tire string eva luat ion (Sta ge 2, Figure 5.1), requeste rs will have no

verba l conta c t with any ICANN sta ff member, any ICANN Boa rd m em be r, or anyperson associated with the evaluation process, including any evaluators, experts,exam iners, or review ers reta ined by ICANN. If suc h cont ac t is a ttemp ted , thereq ueste r w ill be red irec ted to submit the ir inquiry to the system tha t is in plac e fo rsuc h inquiries (see the desc ription for the w eb -ba sed reque st system, ab ove). Theexce pt ion to this c ase would b e w hen or if a reque ster is app roa c hed by ICANNor its age nts for cla rific a tion of informa tion in the submitte d req uest. In add ition,som e c ommunica tion will oc c ur d uring the standa rd ICANN function forde lega tion of the IDN cc TLDs and for provid ing root m ana ge me nt servic es (Stage3, Figure 5.1).

5.3.1 General Contact Details

ICANN IDN Sta ff w ill be ava ilab le to assist p rospec tive IDN ccTLD mana gers inarea s relate d to IDN p rep a rat ions, de velopme nt, and implementa tion.

All req uests for assista nc e o r any inq uiries about the Fast Trac k proc ess must b esubm itted to [email protected]

Answers to the mo st c om mo n q uestions about the Fast Track Proc ess a reava ilab le in an FAQ o n the Fast Track website a thttp://www.icann.org/en/topics/idn/fast-track/

5.3.2 Specific IDN Support Details

To support the req uesters in their prep ara tions, ICANN will make a supportfunc tion a vailab le that provide s guidanc e a nd informa tion in the develop mentof e leme nts rela ted to req ueste rs IDN reg istration policy. This support func tion w illbe availab le in the Prep a rat ion Stage and aga in to a n IDN c c TLD mana ge rfollowing d eleg a tion of the req uested IDN cc TLD(s).

The fo llow ing elem ent s will be inc luded in the IDN support proc ess:

1. Req uest for linguistic sup port to d em onstrate the m ea ningfulness of a ndesired IDN c c TLD string :

1.1.Upo n request ICANN will p rovide rec om me ndat ions for experts tha t c anproduce such repo rts.

1.2.The recom me nda tions will in som e c ases be b ased on a dvic e from theUNGEGN. For non-UN mem bers a sep ara te p roc ess w ill be used foride ntifying a n ad eq uate e xpe rt.

2. Review and implementa tion of IDN Guide lines, inc luding supp ort forunde rstand ing the de tails of the follow ing requirem ents:

2.1. Imp lementa tion of IDNA p rotoc ol req uirem ents2.2. Defining sc ript o r lang uag e and sets thereof2.3. Deve lopme nt of IDN Tab le(s), includ ing identifica tions of va riants
mailto:[email protected]:[email protected]:[email protected]://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/mailto:[email protected]


21/59

21

2.4. Posting of IDN Tab le(s) in the IANA rep ository2.5. Ma king a ll informa tion ava ilable o nline2.6. Identific ation of stakeholders tha t need to b e c onsulted

3. Supp ort and de sc ription of various availab le op tions for dec ision-ma king onimplementation issues, such as:

3.1. How to d ete rmine w hich c harac ters to supp ort (protoc ol validity, usersurvey, va riants)

3.2. Deve lopme nt o f gene ra l reg istration policy (suc h a s first-com e-first-servegrandfathering or other preregistration rights or intellectual propertyrights)

3.3. Development of variant registration policy (such as bulk vs. blockregistrations)

3.4. Definition of ne c essa ry too ls and support func tions rela ted to reg istrarcommunication, support needs, and implementation topics in general.

3.5. Supp ort for de velopme nt of more tec hnica l too ls neede d , such asWHOIS capab ilities, IDNA c onversions, and mo re.

In d eve lop ing IDN Tab les and assoc iate d reg istrations po lic ies, req uesters a reenc ourag ed to w ork with other lang uag e c omm unities that a re using the sam e(or simila rly looking) sc ript(s) as the basis for the lang uage s they p lan to support.

ICANN w ill provide support and gene ra l assista nc e in the se m atte rs. ICANN willnot p rovide leg a l or business advice to c ountries or territories, or any pote ntial orexisting registry managers.

5.4 Termination of Submitted Requests

Severa l of the steps in the Req uest Sub mission fo r String Eva luation (Sta ge 2) allowfor a req ueste r to w ithdraw a req uest. It is a lso p ossible tha t ICANN will termina te

a req uest if the req uest c onta ins c erta in errors.

Errors resulting in possible termination include the following:

1. The req uested string is a lrea dy a string deleg a ted in the DNS, or app rove d forde lega tion to a nother pa rty.

2. The c ount ry or territory of the req uest d oes not c orrespond to a listing in theISO3166-1 list or the European Union.

3. The req uested string c onsists of o ne or mo re c ha ra c te rs from the La tin sc ript.4. The lang uag e rep resente d does not fulfill the langua ge c riteria for the

corresp ond ing c ount ry or territory.

If such e rrors a re disc ove red , the reque ster will be c onta c ted by ICANN andprovided an op po rtunity to a me nd its req uest. Alternatively the reque ster mayde c ide to w ithdraw the req uest.

Other issues a rising from a submitte d req uest ma y de lay the d etermina tion ofwhe ther the req uested string should b e d elegat ed . Such de laying fac tors couldinc lude: (1) the requested string is a lrea dy ap p lied for in the Fast Trac k Proc ess, (2)the req uested string is a lrea dy app lied for in the gTLD p rocess, (3) the req uestdo es not c onta in supp ort from the c orrespond ing c ountry or territory, and (4) the


22/59

22

req uested string is not included in the UNGEGN m anua l and it is not otherwisesubstantiated that the string is a me aningful rep resenta tion o f the c orrespo ndingc ount ry or territory na me . In a ll suc h c ases the req uester will be c onsulted forc larifica tions be fore a ny d ec ision on t he request is ma de.

5.5 String Confusion and Contention

String c on fusion exists where a string so nea rly resem b les ano the r visua lly tha t it islikely to d ec eive o r ca use c onfusion. For the likelihood of c onfusion to exist, it must

be probable, not me rely po ssible tha t c onfusion will a rise in the mind of theaverag e, rea sona b le Internet user. Mere assoc iation, in the sense tha t the stringbrings anot her string to mind , is insufficient to find a likelihoo d of c onfusion.

String c onfusion issues ca n involve tw o or mo re strings tha t a re identica l or are soc onfusingly simila r that they c annot c oexist in the DNS, suc h a s:

Req uested IDN c c TLD strings ag a inst e xisting TLDs and reserved na mes; Req uested IDN c c TLD strings ag a inst o the r req uested IDN cc TLD string s;

and

Req uested IDN c c TLD strings ag a inst app lied -for gTLD strings.

Contention situat ions betw ee n Fast Trac k req uests and new gTLD ap p lic a tions a rec onsidered unlikely to oc c ur. Assessme nts of whether strings a re c onsidered inc onflict with existing or app lied -for new gTLD strings a re ma de in the DNS Sta b ilityString Eva luat ion fo r Fast Trac k req uests and in the Initial Eva luat ion step forne wgTLD app lica tions. The following supp leme nta l rules p rovide the t hresholds forsolving a ny ide ntified c ontent ion issues:

A. A gTLD ap plica tion that is app roved by the ICANN Boa rd will be c onsideredan existing TLD in inter-proc ess c on tention unless it is w ithd rawn. Therefore, anyothe r later ap plica tion for the same string will be d enied .

B. A va lida ted req uest for a n IDN c c TLD will be c onsidered an existing TLD ininter-p roc ess c ontent ion unless it is w ithdraw n. Therefo re, any other late rap p lic ation for the same string will be d enied .

For the purpose of the above cont ent ion rules, an IDN cc TLD string reque st isreg a rde d as valida ted onc e it is c onfirme d t hat the string is a me aningfulrep resent a tion of the c ount ry or territory and tha t the string ha s passed the DNSSta b ility Panel eva luation.

5.6 Processing of a Fast Track Request

Req uests for IDN ccTLD(s) sub mitted to ICANN will be sub jec ted to a series ofma nual eva luation reviews by ICANN sta ff and b y outside a pp ointed expe rtswhere required . Figure 5.1 outlines the ove ra ll p roc ess, while the deta iled

proc esses a re d esc ribed in the follow ing subsec tions and assoc iate d figures.

5.6.1 Request Completeness Validation

The first a c tivity a fter ICANN rec eives a req uest fo r an IDN cc TLD(s) is a c hec k tha tthe request is c om p lete . This is illustrated in Figure 5.3.

ICANN will verify that a ll req uired fields have b een ente red and that theinforma tion p rovided is suffic ient to initiate the string e va luation.
http://icann.org/en/topics/new-gtld-program.htmhttp://icann.org/en/topics/new-gtld-program.htmhttp://icann.org/en/topics/new-gtld-program.htmhttp://icann.org/en/topics/new-gtld-program.htmhttp://icann.org/en/topics/new-gtld-program.htmhttp://icann.org/en/topics/new-gtld-program.htm


23/59

23

ICANN w ill verify tha t:

- The req uested string (A-label) doe s not exist in the DNS, is not app rove d forde lega tion to a nothe r pa rty, and it (U-lab el) is not identica l to a n entry in theReserved Names list.

- The req uested string (U-label) do es not c onta in La tin cha rac te rs.- The req uested string (U-label) is a t lea st 2 c ha rac ters long .- The follow ing required elem ents a re in a greeme nt: the req uested string (s) (U-

lab el), the id ent ified ISO 3166-1 co rrespond ing c od e, the ide ntified UNGEGNMa nua l ent ry (if ap p lic ab le), and the language (s) or sc rip t(s) listed in the IDNTab le.

- The fo llow ing requ ired elem ents a re in ag reeme nt: the requested string (U-label), the ide ntified sc ript(s), and langua ge (s).

- The follow ing required elements are in a greem ent: the req uested A-lab el, U-label, and c orrespo nding Unico de co de po ints.

- All conta c t d etails provide d a re a c c urate and usab le- If the string reque st is not c om ing from the go vernment, forma l

doc ume nta tion from the releva nt go vernment or ad ministration supp ortingthe req uester as sponsor is includ ed . (ICANN will verify tha t the rec eiveddoc ume nta tion of supp ort is from an authorita tive source .)

o ICANN Sta ff ma y see k assista nc e from the GAC in ve rifying tha t thedo c umenta tion is from an autho ritative source .

This chec k identifies req uests as c om plete or incom p lete. ICANN sta ff w ill informthe req ueste r of any m issing e leme nts or errors in the req uest, and the requesterwill be a b le to either provide add itiona l informa tion a t this time, or withd raw thereq uest (and p otentially resubm it at a later time ).

If no e rrors a re e nc ountered , ICANN sta ff will not ify the requester tha t the Req uestComp leteness Va lida tion is passed suc cessfully and tha t the Linguistic Proc essValidation ha s be en initiated .

5.6.2. Linguistic Process Validation

The Lingu istic Proc ess Va lida tion is g rap hica lly described in Figure 5.4.

In this step ICANN sta ff is verifying tha t the following a re sa tisfac tory:

That the selec ted langua ge (s) a nd sc ript(s) a re c onsidered offic ial in thecountry/territory of the request.

o If the la nguage is listed for the releva nt c ount ry or territory as anISO 639 lang uage in Part Three of the Tec hnica l Referenc e Ma nualfor the sta nda rdization of Ge og raphic al Name s,United NationsGroup o f Expe rts on Ge og raphic al Names(the UNGEGN Ma nua l)(http://unstats.un.org/unsd/geoinfo/default.htm ); or

o If the languag e is listed as an a dministrative langua ge for thereleva nt c ount ry or territory in the ISO 3166-1 sta nda rd undercolumn 9 or 10; or
http://unstats.un.org/unsd/geoinfo/default.htmhttp://unstats.un.org/unsd/geoinfo/default.htmhttp://unstats.un.org/unsd/geoinfo/default.htmhttp://unstats.un.org/unsd/geoinfo/default.htm


24/59

24

o If the relevant p ub lic authority in the c ount ry or te rritory hasc onfirme d tha t the langua ge is (i) used in offic ial com munica tionsof the relevant p ublic authority; and (ii) serves as a langua ge ofadministration.

Tha t the rec eived doc ume nta tion of c om munity supp ort for the string(s) issatisfactory.

o This should b e d em onstrated in a simila r manner as required fordelega tion req uests, see Module 5, Appe ndix 2 for guidinginformation.

Tha t the string (s) req uested is a me aningful representa tion o f thec orresp ond ing c ountry/ territory nam e b y verifying that either

o the string is ma tc hing a n en try (/ ent ries) in the UNGEGN Manua l, oro the rec eived expert d oc umenta tion stat es that the string(s) is a

me an ingful rep resenta tion of the c ountry/ territory nam e.

For the purpose of the Fast Track Proc ess the req uested string is a me aningfulrep resent a tion o f the c orrespond ing c ountry or territory name if it is listed as thelong o r short form na me of tha t c ount ry or territory in Part Three o f the Tec hnica l

Reference M anual for the standa rdiza tion of Ge og raphic a l Nam es, UnitedNations Group of Experts on Ge og raphic al Name s (the UNGEGN M anua lhttp://unstats.un.org/unsd/geoinfo/default.htm ) in an official langua ge of thec ount ry o r territory.

If the requested string is not listed for the country or territory in the UNGEGNMa nual the requester must provide d oc umenta tion which include s a report froman internationally recognized expert(s) in a relevant field of expertise.

See Module 3 for mo re d eta ils and guiding e xam ples.

If no e rrors a re e nc ountered , ICANN sta ff will not ify the requester tha t theLinguistic Proc ess Va lida tion is passed suc c essfully and tha t the DNS Sta b ility

Evaluation has been initiated .

5.6.3 DNS Stability Evaluation

The DNS Sta b ility Eva luation p roc ess is g rap hica lly desc ribed in Figure 5.5.

The request and assoc iate d m aterial will be p rovided to the DNS Sta b ilityTec hnica l Panel (see Mo dule 4 for de ta ils) and the string eva luation w ill begin. Thiseva luat ion co nsists of two m a in com po nents:

i. a d eta iled tec hnic al chec k in which c omp lianc e with all the technica lstring req uirem ents refe renc ed in Module 3 is verified , and

ii. an eva luation of confusab ility with a ny Reserved Nam es, existing TLDs(bot h c c TLDs and gTLDs), or po tentia l future TLDs.

If the DNS Sta b ility Pane l find s tha t a dd itiona l linguistic exp ertise is nec essa ry tosa tisfy the latte r com ponent o f the eva lua tion, suc h can be req uested throug hICANN. ICANN will in return request assistance, specific information, or a fullc onfusability review. The spec ific e xpertise ne ed ed will pa rtly dep end on t heac tual string in que stion, but co uld fo r exam ple, imp ly a full review c ond uc ted bythe String Simila rity Pane l. This is a pane l assessing string pairs for confusingsimilarity, following the rules set forth in section 5.5, and as established for the newgTLD Program (http://www.icann.org/en/topics/new-gtld-program.htm ).
http://unstats.un.org/unsd/geoinfo/default.htmhttp://unstats.un.org/unsd/geoinfo/default.htmhttp://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://www.icann.org/en/topics/new-gtld-program.htmhttp://unstats.un.org/unsd/geoinfo/default.htm


25/59

25

If any issues w ith the selec ted string a re d isc overed in this review the DNS Sta b ilityPanel c an req uest c larifica tion from the req uester through ICANN.

If c larifica tions a re insufficient or cannot b e p rovided , the Termina tion Proc ess w illbe initiated . See sec tion 5.4.

If the DNS Sta b ility Pane l rev iew revea ls no technic a l issues the requeste r isnot ified tha t the DNS Sta b ility String Eva luation is suc c essfully c om pleted and tha tthe req uested string(s) w ill be que ued for pub lic po sting.

5.6.3 Publishing of Requested String(s)

Following a suc c essful outc om e o f the String Confirma tion Proc ess, the req uestedIDN ccTLD string(s) will be posted pub lic ly.

The ICANN Fast Trac k web site http://www.icann.org/en/topics/idn/fast-track/willc onta in an a rea de d ica ted to presenting strings tha t reac h this step in the FastTrac k Proc ess. RSS feeds of c hanges to this a rea w ill be ma de a va ilab le.

5.6.4 IANA Delegation Readiness

Following the pub lic posting o f the requested string , a ll Sta ge 2 proc ess

req uirem ent s a re c onside red suc c essfully com pleted . The req ueste r w ill be

notified that the stand ard IANA d elegation p roc ess c an be gin and wha t furtherac tions a re ne c essary. The IANA deleg a tion p roc ess is desc ribed in Mod ule 6.
http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/http://www.icann.org/en/topics/idn/fast-track/


26/59

26


Ap p end ix 1: Figure 5.1: Ge neral Overview o f the Fast Trac k Proc ess; Sta ge 1: Preparat ion; Sta ge 2: Req uestSubmission fo r String Eva luation; Sta ge 3: Req uest Submission fo r Deleg a tion Eva luation

Figure 5.2: Sta ge 2: Sub mission of a Req uest fo r String Eva luation

Figure 5.3: Sta ge 2: Req uest C om p leteness Va lida tion

Figure 5.4: Sta ge 2: Lingu istic Proc ess Va lida tion

Figure 5.5: Stage 2: DNS Stability Evaluation


27/59

27

IDN Fast Track Implementation Process

Stage1

Stage3

Stage2

Requ

estSubmission

fo

rDelegation

Evaluation

IANADelegationEvaluation

DNS StabilityEvaluation (see

Figure 5.5)

RequestSubmissionfo

r

StringEvaluation

RequestCompletenessValidation (see

Figure 5.3)

Documentendorsement from

country/territory

Identifyscript(s) andlanguage(s)

Select thestring(s)

Develop IDNtable(s)

Document endorsement fromcountry/territory (per IANA

function)Select TLDManager(s)

Enter

LinguisticProcess

Validation (see

Figure 5.4)

Country/Territory

Preparations

Publish StringSubmission ofRequest (see

Figure 5.2)

Submission ofRequest

RootImplementation

ICANN Boardconsiderations

RequestCompleteness

Validation

Figure 5.1: General Overview of t he Fast Trac k Proc ess; Sta ge 1: Prepa ration; Sta ge 2: Req uest Sub mission fo rString Eva luat ion; Sta ge 3: Req uest Sub mission fo r Delega tion Eva luation.


28/59

28

Submission of Request- via online web-based form

Status: Request Received, Request

Completeness Process Initiated

Notification with ticket # is submitted to theRequesters identified point of contact

The web-form will ensure that required fieldshas been filled in, alternatively the requestor

will get on-screen errors that must becorrected before the request can be

submitted succesfully.

gTLD interface: All strings received areprovided for input in the String Similarity/

Contention Process check.

Dashboard interface: showing stats overnumber of requests in the various statuses

throughout the process.

At any time contention with a gTLDapplication or other Fast Trackrequested string is discovered,

notification will be submitted to theinvolved parties.


Figure 5.5)

RequestSubmissionfor

StringEvaluation

LingusticProcess

Validation (seeFigure 5.4)

Publish String

RequestCompleteness

Validation(see Figure

5.3)

Figure 5.2: Sta ge 2: Submission of a Req uest fo r String Eva luation.


29/59

29

Request Completeness

Validation

- conducted by ICANN Staff- validation to identify obviousadministrative errors in request

Validation of:- basic string composition- all identified and supplied material with linguistic aspects- basic IDN string criteria check- provided government support is adequate (if applicable)- contact data usability

A). If the request is verifiedto contain all information

required:

Status Change: RequestAdmissibility Complete,

Request Process ValidationInitiated

Notification is submitted toRequestor

B). If the request is notverified to contain allinformation required:

Staff (w/legal support ifneeded) prepare and

submits clarifying email torequestor.

Requestorsubmits

additionalinformation

Requestordecides to

cancel therequest

RequestAdmissibilityProcess re-

initiated

StaffManager

closes ticketin system

Notification is submitted toRequestor


Figure 5.5)

R

equestSubmissionfor

StringEvaluation

LinguisticProcess


Publish StringSubmission ofrequest (seeFigure 5.2)

Figure 5.3: Sta ge 2: Req uest C om pleteness Va lida tion.


30/59

30

Linguistic Process Validation DNS StabilityEvaluation (see

Figure 5.5)

RequestSubmissionfor

StringEvaluation

Submission ofRequest (seeFigure 5.2)

Publish String

RequestCompleteness

Validation(see Figure

5.3)

1) That the selected language(s) andscript(s) are considered official in thecountry/territory of the request, by verifyingeither:

2) That the string(s) requested ismeaningful representation of thecorresponding country/territory name byverifying either:

3) That the received documentation ofcommunity support for the string(s) isacceptable.

a) the language is listed for therelevant country or territory as an

ISO 639 language in theUNGEGN Manual

b) the language is listed as anadministrative language for the

relevant country or territory in theISO 3166-1

c) the relevant public authority inthe country or territory confirmsthat the language is (i) used in

official communications ; and (ii)serves as a language of

administration.

This should be demonstrated in asimilar manner as required fordelegation requests: http://www.iana.org/domains/root/

delegation-guide/

a) the string is matching an entry(/entries) in the UNGEGN Manual

b) the received expertdocumentation states that the

string(s) is a meaningfulrepresentation of the country/

territory name

Figure 5.4: Sta ge 2: Linguistic Proc ess Va lida tion .


31/59

31

DNS Stability Evaluation

LinguisticProcess


Requ

estSubmissionfor

S

tringEvaluation

Submission ofRequest (seeFigure 5.2)

Publish String

RequestCompletenessValidation (see

Figure 5.3)

Staff Manager submits list of strings andassociated documentation to the DNS

Stability Panel.

Panel conducts initial evaluation on allrequested strings

Evaluation successful

and no issuesencountered

Status Change: DNSStability Technical

Evaluation Complete,Public Posting Initiated

Notification issubmitted toRequestor

Staff (w/legal support ifneeded) prepare andsubmits request forclarifying material to

requestor.

Requestor submitsadditional information

Requestor decides tocancel the request

Information is providedDNS Stability Panel

and the review iscontinued

Staff Manager closesticket in system

Notification is submitted toRequestor POC and Staff

Manager (Manual)

gTLD interface: A Fast Trackrequested string reaching this stage

is considered Validated and for

contention purposes an existingTLD.

Evaluation not

successful, issuesencountered

3-member panel isformed and requestlisted for extended

evaluation

Figure 5.5: Stage 2: DNS Stability Evaluation.


32/59

32


Sample: evaluation criteria for string selection community support

Sample Requirement

The selec tion o f the string to rep resent a c ount ry or territory need s to be in the interests of the Internetuser co mm unity of the c ount ry or territory. There should b e d ialog ue in the c ount ry or territory aboutwha t string(s) should be selec ted to be st supp ort the loc al Internet c om munity.

Requesters should explain how consensus was reached (among relevant stake-holders in the localInternet c om munity) on the string (s) tha t is req uested , includ ing the c onsultative p roc esses tha t wereundertaken.

Any op position to the p rop osal should a lso b e d oc umented , including a lternat ives that w erec onside red , as we ll as an explana tion w hy, on b alanc e, it w as de c ide d to p roc eed with the request.

As part of this, sta tements from significant ent ities suc h a s user g roup s, Inte rnet organiza tions, ISPs,trad e groups, etc . c an be tend ered. The sta tem ents should e xpla in their views on t he p rop osal,ideally discussing what different alternatives they have considered.

Evaluation aspects

Consultations performed:

It is an imp ortant a spe ct of a req uest tha t a dialogue ha s be en c onduc ted within the loc al Internetc om munity on how the p rop osed string(s) wa s selec ted . It is not a pp rop riate tha t a to p-dow nme thod ology should b e imp osed on the Internet c om munity without op po rtunity for them to d isc ussop tions and ga in c onsensus on a n a pp rop riate ap proac h.

App rop riate level of pa rtic ipa tion:

It is expec ted that p artic ipa tion in de velop ing a p rop osa l c om es from a numb er of ac tors tha t rep resentthe loca l Internet c om munity. The o bjec tive is to ensure key p a rties we re involved , or at lea st ha d a fairop po rtunity to p articipa te, in d elibe rations c onc erning the a pp roa c h b eing presented .

Significa nt ob jection identified and disc ussed :

It is not e xpec ted there wo uld be c om p lete supp ort for any prop osal there will very likely be op po singviews. It is expe c ted , howeve r, tha t the reque ster expla ins the op posing view s, ana lyses and d istills themand explains why the requested string(s) is considered the best approach despite those views.

Spec ific view points:

Conside red c ont ributions for key Internet com munity bod ies, suc h as trad e o rga nisa tions, keyc orporations, etc . c an b e eva luat ed . They should no t be form letters t hat ha ve simply bee n signed ,but c onsidered ho nest op inions from the p erspe c tive of the organizat ion reg a rding the requestedstring(s).


33/59

33

Module 6Delegation Process

ICANN ma intains a p roc ess for de lega ting to p -level d om a ins in itsexec ution of its IANA funct ions. A guide to the delega tionp roc ed ure for existing c ountry-code top -level d om a ins isde sc ribe d a thttp://www.iana.org/domains/root/delegation-guide/. This p rocess rema ins largely a pp lic ab le to IDN c cTLDs. Theonline doc ument will be upd ate d to reflec t upda ted op erationalp rac tices for IDN c cTLDs.

Req uesters tha t ha ve suc c essfully com p leted the String Eva luationProc ess w ill rec eive a not ific a tion from ICANN tha t the selec tedstring ha s been ap proved for use b y tha t c ountry or territory, and

that they a re w elcom e to ap ply for the d elegation p roc ess (Stag e3). While the proc ess de sc ribed in Mod ule 5 is c onc erned withassessing the string , the delega tion p rocess involves assessingwhether the p rop osed sp onsoring o rganiza tion is a q ua lifiedtrustee for the loc al Internet c om munity.

As the req uirem ent s of the two p roc esses a re sep a ra te , thereq uester must subm it the qualifying do c umen ta tion fordelega tion sep arate ly. If som e d oc umenta tion is the same as forthe string eva luation p roc ess, it must be resubmitted a t this time.

6.1 IANA Function

ICANN ma nag es the IANA func tions unde r a c ontrac t with theUnited Sta tes Department of Co mm erce . The IANA functionp roc ess for de lega ting a n IDN cc TLD will rem ain co nsisten t w ith thep rocess for existing TLDs d irec tly d erived from the ISO 3166-1standa rd. The p roc ess will be augm ented only to include t hereq uirem ents in Mod ule 5.

In this p roc ess, ICANN sta ff will rec eive a req uest to deleg a te anIDN cc TLD that is c om po sed of a forma l temp late e xp laining t hedelega tion req uest tog ethe r with supp orting d oc ume nta tion. Thissupp orting d oc ume nta tion must d esc ribe how t he p rinciples inRFC1591, ICP-1, and the GAC princip les a re supported . Som e ofthese p rinc ipa ls a re:

6.1.1 Operational and Technical Skills

1.1 The prospec tive m ana ge r has the req uisite skills toop erate the TLD approp riately.

1.2 There m ust b e reliab le, full-time IP c onnec tivity to thenam e servers and elec tronic m ail conne c tivity to themanagers.
http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/http://www.iana.org/domains/root/delegation-guide/


34/59

34

1.3 The m ana ger must p erform its duties in assigning d om ainsand op erating nam e servers with technical co mp etenc e.

6.1.2 Manager in Country

1.4 The p rospec tive ma na ge r supervises and op erates thedo ma in name from within the c ountry or territoryrep resent ed by the TLD.

1.5 The p rospec tive ad ministrative c ontac t must reside in thec ount ry rep resent ed by the TLD.

6.1.3 Equitable Treatment

1.6 The Reg istry ma na ger sha ll op era te the IDN cc TLD in ama nner tha t a llow s the TLD com munity to d isc uss andpa rticipa te in the developme nt and m od ifica tion ofpolicies and p rac tices for the TLD.

6.1.4 Community/Governmental Support

1.7 The p rospec tive ma na ge r has the req uisite au thority toop erate the TLD ap p rop riate ly, w ith the de sire of thego vernme nt ta ken very seriously.

1.8 Signific antly inte rested parties in the dom ain shou ldag ree that the prospe ctive ma nag er is the a pp rop riatepa rty to rec eive the delega tion.

In a dd ition to ma terial tha t d em onstrat es the req uester suitabilityund er the se RFC 1591 c rite ria , req ueste rs must p rovide theadd itiona l spec ific ma terial relating to the e valuation desc ribed inthe Mo dule 5. This req uirem ent will be sa tisfied b y the De lega tion

Rea d iness rep ort tha t d esc ribes the IDN-spec ific fac to rs.

ICANN will perform due dilige nce on the do c umenta tion p rovidedin ac c orda nce w ith ICANNs IANA review proc ess de sc ribed inRFC 1591. If the req uest doe s no t a deq ua tely cove r a ll a rea s, theywill c onfer with the requester, who ma y p rovide furtherinformation. When ICANN de em s the IANA due d iligenc eeva luation c om p lete, it will forwa rd t he request and its assessme ntfor ICANN Boa rd review .

6.2 ICANN Board Review Process

All deleg a tions and re-d eleg a tions of c cTLDs req uire ICANN Boa rd

app rova l to p roc eed . This ap prova l is expec ted to rem ainc onsta nt w ith the introduc tion o f IDN cc TLDs.

At the c onc lusion of ICANNs IANA func tion eva luation, the ICANNBoa rd w ill assess the deleg a tion req uest.

The ICANN Board w ill eva luate whether req uests a re c onsisten tw ith governing policies and w ith ICANN s c ore va lues set out in itsbylaw s to ensure the stab le and sec ure o pe ra tion of the Internet'sunique id en tifier systems.


35/59

35

6.3 US Government Authorization

Afte r approva l of a req uest, ICANN w ill execute its regula r IANAfunc tion root zone c hang e m ana ge ment p roc ess.

This c hange involves rete sting the tec hnica l configura tion of the

delega tion da ta supp lied b y the req uester, and e nsuring thatna me servers func tion c orrec tly. Onc e sa tisfied, the req uest w ill betransmitted to the US Dep artment of Co mm erce for authoriza tion.Following this autho riza tion, it will be imp leme nted in the DNS roo tzone.


36/59

36

Module 7Relationship between IDN ccTLD and ICANN

This mo dule c onta ins a desc ription of the req uired and op tionalrelations be twe en a n IDN cc TLD ma nag er and ICANN.

The t op ics of m and at ory or voluntary relationship b etw een ICANNand the IDN c c TLD ma na gers ha ve b ee n disc ussed in seve ra lme etings and online fora.

The c om munity has expressed broad ly rang ing op inions on thisma tter. In an atte mp t to co nverge c om munity opinions variousp rop osed solutions have b ee n posted for pub lic d isc ussions andcomments.

In kee p ing w ith ICANNs sta b ility and sec urity mission the IDN cc TLDreq uester ag ree s to a basic set o f terms and c ond itions, as pa rt ofsubmitting a req uest fo r an IDN cc TLD. If the req ueste r is not theIDN cc TLD ma nag er, the req uester will be ma king such a greem enton b eha lf of the IDN c c TLD ma nag er.

In add ition one o f the follow ing three relationship op tions c an beelec ted on a voluntary basis:

Op tion 1: DoR. Doc ument a tion of Responsibility to b eexecuted by b oth p arties.

Op tion 2: EoL. Excha nge o f Let ters. A pa ir of unilate ra lwritten sta tem ent s, as a lrea dy esta b lished w ith seve ra lcc TLDs.

Op tion 3: SA. Standa rd Ag reement. A prearrang ed andrec om me nde d ge neral TLD Agreem ent.

Proposed deta ils for (i) Terms and Co nd itions, (ii) DoR, (iii) EOL, (iv)SA, are a tta ched in Ap pend ix 1 to this Module 7. They g ene rallyimp ly c omm itments to:

o op erate in a stab le, sec ure manner,o adhe re to IDNA protoc ol, other pertinent RFc s, and IDN

Guidelines,

o eng ag e in coop eration to resolve disp utes, ando not imp leme nt DNS red irec tion a nd synthesized DNS

responses


37/59

37


Ap pend ix 1: Req uired Terms and Cond itions for the IDN cc TLD Fast Trac k Sub mission

Documentation of Responsibility

Prop osed ICANN to IDN cc TLD Excha nge o f Lett er

Prop osed IDN cc TLD to ICANN Excha nge of Letter


38/59

38

Terms and Conditions of Submission Fast Track requests

General Information on Submission of Request for String Evaluation

The Internet Corpo ra tion for Assigned Nam es and Numb ers (ICANN), as the stew ard of the

g loba l, interoperab le Internet , is acc ep ting submissions for req uests for string eva luation of IDN

c c TLD strings.

By signing a nd subm itting this req uest w e (the "Req uestor") a cknowled ge and unde rstand tha t:

Usab ility Warning :

Further ac c ep ta b ility and usab ility issues ma y oc c ur as the IDNA protoc ol sta nda rd is revised and

as the IDN protocol for em a il ma na ge me nt is finalized in the Internet Eng ineering Task Force(IETF). The result of t he IDNA p rotoc ol revision w ill be tha t som e c ha rac te rs p reviously not

permitted w ithin IDNs will bec om e va lid . ICANN w ill ac c ep t reque sts for strings w ith these ne wly

valid cha rac ters, but until the new , revised standa rd is implem ented a nd b roa dly ad op ted by

releva nt a pp lic a tion d eve lopers, users ma y expe rienc e p rob lems with using the IDN. This ma y

ha ve d ifferent results in different a pp lic at ions, and in som e insta nc es a user ma y expe rienc e no

func tiona lity a t a ll. It would be a pp rop riate for all IDN TLD ma nagers to p rovide the ir users w ith

informat ion abo ut the limitations of use o f IDNs and a t the sam e t ime p romote the use o f IDNs to

achieve g loba l IDN imp lementa tion ac ross app lic a tions. ICANN supp orts suc h effo rts but is not

ab le to enforce or req uire them .

The usab ility of IDNs ma y be limited , as not a ll app lic at ion softw are is c apab le

of working with IDNs. It is up t o ea c h ap plica tion de velope r to d ec ide w hether or not they wish

to sup port IDNs. This c an inc lude, for examp le, brow sers, email c lien ts, and sites where you sign

up fo r a service o r purcha se a prod uc t a nd in that p roc ess need to e nter an em a il add ress. Such

usab ility p rob lems curren tly exist to day w ith the ASCII TLDs in some situa tions.

String Eva luation Sta ge:

Imp leme nta tion Plan fo r the IDN cc TLD Proc ess

The submission of this request initiates the "Request Submission for String

Eva luation" sta ge as set forth in the .

Payment of the p re-arrange d, rec omme nded fee (USD $26,000) for the p roc essing o f a req uest

in the String Eva

Documents

Idn Cctld Implementation Plan 30sep09 En