(not-exhaustive) List of specific areas for detailed review and additional work on IDN ccTLD overall pro posed policy

 

Reference Document (“Document” in the table below): Board Report – IDN ccNSO Policy Development Process, Sep 2013 ( https://ccnso.icann.org/sites/default/files/filefield_41859/idn-ccpdp-board-26sep13-en.pdf )

 

2.1.1 Overall Principles

 

Section in Document

Topic

Comment/Rationale for review/inclusion in list

2.1.1 (I)

Association of the (IDN) country code Top Level Domain with a territory. Under the current policy for the delegation of (ASCII) ccTLDs, the two letter ASCII codes associated with the territories listed in the ISO 3166- ­ 1 standard are eligible for delegation as a ccTLD. Only the territories listed in ISO3166-1 shall be eligible to select IDN ccTLD strings

Ensure consistency with the delegation procedure for ASCII ccTLDs.

 

Maintain basic principle that “IANA (ICANN) is not int her process of what is and what is not a country”.

2.1.1 (III)

Preserve security, stability and interoperability of the DNS. To the extent different, additional rules are implemented for IDN ccTLDs these rules should […].

As the DNS must remain unique and stable, ICANN must ensure full consistency of rules across all TLDs when it comes to their delegation.

2.1.1 (V)

Criteria determine the number of IDN ccTLDs. The criteria to select the IDN ccTLD string should determine the number of eligible IDN ccTLDs per Territory, not an arbitrarily set number

 

Any criteria for the selection of an IDN ccTLD must be based on the link between the IDN ccTLD and the Territory for which it is proposed.

 

Agreed: the criteria are defined in section 2.1.2 

 

 

The principle of parity between (IDN)ccTLD was raised by Ajay. Agreed that is outside scope this Review team, but could be raised as separate issue

2.1.2 Criteria for the selection of an IDN ccTLD String

Section in Document

Topic

Comment/Rationale for review/inclusion in list

2.1.2 C

The IDN ccTLD string must be a Meaningful Representation of the name of a Territory. The principle underlying the representation of Territories in two letter (ASCII) code elements is the visual association between the names of Territories (in English or French, or sometimes in another language) and their corresponding code elements. The principle of association between the IDN country code string and the name of a Territory should be maintained. A selected IDN ccTLD string must be a meaningful representation of the name of the Territory. A country code string is considered meaningful if it is: a)The name of the Territory; or b)Part of the name of the Territory that denotes the Territory; or c) A short form designation for the name of the Territory, recognizably denoting the name.

ICANN must ensure consistency between the policy to assign an ASCI ccTLD and an IDN ccTLD. In detail, the “meaningful representation” criteria should be crystal clear when it comes to territories that have multiple, official languages.

 

I am not sure for example, .me is a short form designation for the name of Montenegro, recognizably denoting the name. I understand, that it is not an example from IDN ccTLD, but anyway it happened. So for ASCII the country code is enough, but how could be recognized country code for IDN ccTLD if you don’t know this language? What about hieroglyphs?

2.1.2 E

If the selected string is not the long or short form of the name of a Territory then evidence of meaningfulness is required.

Where the selected string is the long or short form name of the relevant Territory in the Designated Language as listed in the UNGEGN Manual, Part Three column 3 or 4 version 2007, or later versions of that list it is considered to be meaningful.

Where the selected string is not listed in the UNGEGN then meaningfulness must be adequately documented […].

ICANN must make the “meaningfulness” criteria crystal clear as in the past ICANN had inconsistent approaches for the evaluation of the “adequate documentation”. This applies also to the case when one territory has more than one designated language.

Furthermore, the procedure should foresee an appeal step in case the selected string is not accepted because of not being “meaningful”.

 

2.1.2 F

Only one (1) IDN ccTLD string per Designated Language. In the event that there is more than one Designated Language in the Territory, one (1) unique IDN ccTLD for each Designated Language may be selected, provided the meaningful representation in one Designated Language cannot be confused with an existing IDN ccTLD string for that Territory.

Where a language is expressed in more than one script in a territory, then it is permissible to have one string per script, although the multiple strings are in the same language.

Notes and Comments

It should be noted that other requirements relating to non- ­ confusability are applicable and should be considered, including the specific procedural rules and conditions for cases when the same manager will operate two or more (IDN) ccTLDs which are considered to be confusingly similar.

It is recommendable that any future IDN ccTLD policy addresses carefully – and with the support of linguist experts – the option of languages that are expressed in more than one script as well as the rules to be produced in case the same registry manages the ccTLD in ASCII and ts variant in other script. At present, ICANN approach is not consistent and that may jeopardise the ultimate goal of ensuring the security and stability of the DNS.

2.1.2 G

The selected IDN ccTLD string should be non- ­ contentious within the territory. The selected IDN ccTLD string must be non- ­ contentious within the territory. This is evidenced by support/endorsement from the Significantly Interested Parties (relevant stakeholders) in the territory. Concurrent requests for two strings in the same language and for the same territory will be considered competing requests and therefore to be contentious in territory. This needs to be resolved in territory, before any further steps are taken in the selection process.

ICANN must make sure there is consistency between the delegation of an ASCI ccTLD and an IDN ccTLD. Therefore, contentious requests  should be resolved in the territory.

2.1.2 I

Confusing similarity of IDN ccTLD Strings.

As there is only one DNS environment and as domain name end-users/registrants are the same customers all over the internet eco-system – and has such have the same rights, the element of possible confusing similarity between an applied-for TLD must be treated by ICANN the same way, independently from being a cc, g or an IDN TLD.

This will ensure that the current discriminatory rules for the evaluation of IDN ccTLDs are modified and consequently, become in line with the provisions that are currently in place in other TLD environments.

Those considerations apply also to the steps detailed under 2.1.3 “Procedures and Documentation”.


 


2.1.3 Procedure and Documentation

 

Section in Document

Topic

Comment/Rationale for review/ inclusion in list

2.1.3 - 2

IDN Table

The IDN Table may already exist i.e. has been prepared for another IDN ccTLD or gTLD using the same script and already included in the IANA IDN Practices Repository. In this case the existing and recorded IDN Table may be used by reference.

Using the IDN Table prepared for another IDN cc or gTLD could be an option under specific conditions.

2.1.3 - 2

Documentation of required endorsement / support for selected string by Significantly Interested Parties

AS ICANN failed to apply consistent approaches within the IDN Fast Track history regarding “Significantly Interested Parties”, this aspect must be well drafted in any future IDN ccTLD policy.

 

It will be very interested to listen clarification who they are (I mean Significantly Interested Parties). Especially "significantly"

2.1.3 - 2

Cl assification of input

For procedural purposes the following cases should be distinguished […].

Notes and Comments

In case where additional documentation is required:

-           Unanimity should NOT be required.

-           The process should allow minorities to express a concern i.e. should not be used against legitimate concerns of minorities

-           The process should not allow a small group to unduly delay the selection process.

Any policy should have a prudent approach when it comes to “unanimity” and to the evaluation of input.

To be consistent with previously stated procedures, any issue must be sorted within the territory.


 


2.1.4 Section Miscellaneous Policy Proposals

Section in document

Topic

Comment/Rationale for review/ inclusion in list

2.1.4 C

Creation of list over time

Experience has shown that entries on the ISO 3166- ­ 1 table change over time. Such a change can directly impact the eligibility for an IDN ccTLD. In order to record these changes, it is recommended that a table will be created over time of validated IDN ccTLDs, its variants and the name of the territory in the Designated Language(s), both in the official and short form, in combination with the two- ­ letter code and other relevant entries on the ISO 3166- ­ 1 list. The purpose of creating and maintaining such a table is to maintain an authoritative record of all relevant characteristics relating to the selected string and act appropriately if one of the characteristics changes over time.

The update frequency caused issues in the past. It might be advisable to review it.

 

For example once every 1-2 years or in a special case, individual updates are possible upon request.

 

2.1.4 E

Review of policy for the selection of IDN ccTLD strings

It is recommended that the policy will be reviewed within five years after implementation or at such an earlier time warranted by extraordinary circumstances […].

It would be advisable to review the policy whenever deemed appropriate.

Considering the dynamic internet landscape, should any significant scenario change and/or arise, it would be quite challenging to wait 5 years to review the policy.

2.1.4 G

Permanent IDN ccTLD Advisory Panel Due to the complex nature of IDN’s and the sensitivities and interest involved in the selection of IDN ccTLD strings, it is recommended that under the overall policy a Permanent IDN ccTLD Advisory Panel is appointed to assist and provide guidance to ICANN staff and the Board on the interpretation of the overall policy in the event the overall policy does not provide sufficient guidance and/or the impact of the policy is considered to be unreasonable or unfair for a particular class of cases. […].

An advisory panel might have a role if it is made of true IDN experts within and outside the ICANN constituency community. Considering how challenging this could be, it would be recommendable to seek alternative channels to advise on possible issues and changes relating to the policy.

 

This advisory panel can be something like small mailing group with the appropriated e-mail address – something  like the secretariat , who knows IDN experts and will invite them to discuss any particular case when it be need discussed.

 


Section 2.2 Proposals on the inclusion of IDN ccTLD in the ccNSO

Section in document

Topic

Comment/Rationale for review/ inclusion in list

2.2  D

Voting

During any period in which an emissary is not appointed, the ccTLD manager that has been the member of the ccNSO for the longest period of time is deemed to be the emissary for that Territory.

 

It is necessary to distinguish the case when   IDN ccTLD and ccTLD managed by the same Registry (manager). Is it necessary in this case to include this IDN ccTLD as an individual member of ccNSO?

 

Voting by emissary is limited to formal votings enumerated in Artcile 10 ( was Article IX) of the ccNSO: see page 27 Board report)

2.2 A

Membership definition

It is recommended that the definition in Article IX section 4.1 (new Article 10) is updated to maintain the one-to- one correspondence between the IANA Root Zone Database and membership in the ccNSO.

 

The term variants in Bylaw definition refers to the heading “ccTLD Manager”  included in IANA root-zone database. This used to be “sponsoring organization”

For example:

Delegation Record for .AC

(Country-code top-level domain)

ccTLD Manager

Network Information Center (AC Domain Registry)
 

Administrative Contact

Internet Manager Network Information Center (AC Domain Registry)

Technical Contact

Administrator ICB Plc.
 

 

Note: Update of the membership definition is one of the items on the Council list of needed Bylaw changes. Current definition in the Bylaws does not match the text in Board report.

2.2.C

Initiation of PDP

The members of the ccNSO may call for the creation of an Issue Report by an affirmative vote of at least ten members of the ccNSO representing at least ten different Territories present at any meeting or voting by e- ­ ‐ mail. ……”

 

Although questioned the rationale is one vote per territory.


 

 


Other topics

Section in document

Topic

Comment/Rationale for review/ inclusion in list

NA

Variant management

The element of “variant management” has become quite relevant in the overall IDN environment. Therefore, it is recommendable that any IDN string selection process takes it into account.

 

NA

Retirement of IDN ccTLD

The ccTLD retirement policy should be amended to refer to the retirement of IDN ccTLD.

 

Note: the intention is that the newly to be establishedIDN PDP will discuss and recommend the criteria which will trigger the retirement process

 

Agree.  It is really important.