ICANN ICANN Email List Archives

[idn-cctld-fast-track]


<<< Chronological Index >>>    <<< Thread Index >>>

Summary of Comments and Discussions Regarding The Draft Interim Report of the IDNC WG

  • To: "idn-cctld-fast-track@xxxxxxxxx" <idn-cctld-fast-track@xxxxxxxxx>
  • Subject: Summary of Comments and Discussions Regarding The Draft Interim Report of the IDNC WG
  • From: Robert Hoggarth <robert.hoggarth@xxxxxxxxx>
  • Date: Fri, 13 Jun 2008 19:29:49 -0700

Comments on
DRAFT Methodology for Fast Track
Overview (Public) Comment & Discussion

Included are the comments on and summary of public discussions on the Draft 
Interim report of the IDNC WG. The comments are inserted in the related section 
of the Report and can be distinguished through the different fonts.

The text of the draft report is in Verdana.

The reflection of the public discussions, in particular of the Dubai meeting on 
2 April 2008 is in Tahoma

The submitted comments are in Courier

1. Introduction

The purpose of the fast track is to introduce a limited number of 
non-contentious IDN ccTLDs to meet near term demand. The goal of the IDNC WG is 
to recommend a Fast Track model that contains a mechanisms for the selection of 
an IDN ccTLD string, and a mechanism to designate an IDN ccTLD manager.

The model needs to take into account the overarching requirements of stability 
and security; IDNA protocols and IDN guidelines; input of the technical 
community in respect to implementation of IDNs; and current practices for the 
delegation of ccTLDs.

The IDNC WG published for comment a draft Initial Report, to canvass the topics 
that need to be covered.

There seems to be consensus that the questions raised in the draft Initial 
Report did canvass the areas that any proposed mechanisms would need to cover. 
Comment and input was also received addressing some of the possible answers to 
the questions raised in the draft Initial Report.

Based on our understanding of the substantive input to the draft Initial Report 
we think there is a rough consensus on the following points:

A: Ongoing Process
The Fast Track should be an ongoing process, which ends when the overall IDN 
ccTLD policy has been adopted by the ICANN Board. Thus an IDN ccTLD manager can 
enter the fast track when ready. The window of opportunity has no fixed 
end-date.


RyC IDNC Comments, Chuck Gomes, 24 Apr 2008

 *   We support efforts to determine the feasibility of an interim solution 
whereby a limited number of countries or territories designated in the ISO 
3166-1 list that have special needs would be granted IDN labels in the near 
term provided that no IDN TLDs associated with countries or territories are 
introduced earlier than IDN gTLDs without prior community concurrence.

B: Non pre-emption of overall policy
The Fast Track must not pre-empt final IDN ccTLD policy so must be a simple, 
clear and limited solution.

C: Purpose of Fast Track is to meet pressing demand
The Fast Track should only be available where there is a pressing demand in the 
territory. The existence of this demand is evidenced by the readiness of the 
IDN ccTLD manager and relevant stakeholders in the territory to meet the 
requirements to introduce an IDN ccTLD under the Fast Track. The territory 
needs to be ready to use the IDN ccTLD and to demonstrate that readiness.

Summary of IDN Discussion in Dubai (2 April 2008)
Question: What is "pressing demand"?.

Answer: The concept of the methodology is that pressing demand is demonstrated 
by the meeting off the fast track criteria ie. that the registry is technically 
ready, a string has been defined and certain IANA criteria are fulfilled.

RyC IDNC Comments, Chuck Gomes, 24 Apr 2008
Any added IDN label for a country or territory designated in the ISO 3166-1 
list should be for the sole purpose of benefiting the language community (or 
communities) and country or territory designated by the new label.

D: Fast Track only for non-Latin scripts
As the Fast Track has been initiated to meet near term demand for IDNs and to 
avoid pre-empting the outcome of the ccPDP, the script has to be a non-Latin 
script.

E: The proposed string and delegation request should uncontroversial within the 
territory
The two mechanisms should only allow for the delegation of a non-contentious 
string for an IDN ccTLD and designation of a non-contentious IDN ccTLD manager.

F: The Fast Track is experimental in nature
In devising the mechanisms and the Fast Track process, the experimental nature 
of the introduction of IDN ccTLD should be taken into consideration. This 
should be reflected in the implementation of the processes for selection of an 
IDN ccTLD string and designation of an IDN ccTLD manager.

Summary of IDN Discussion in Dubai (2 April 2008)
Question: Does this imply that  there will be a roll-back if a technical flaw 
is noticed?

Answer:  The security and stability of the DNS are paramount. The delegation of 
IDNs is experimental and nobody knows what will happen when IDNs are deployed 
so, yes, it is possible that some sort of roll-back procedure will need to be 
agreed prior to delegation. Further, it is also important to note that the Fast 
Track itself is experimental also in respect to methodology used and that that 
the outcome of the fast track experience would feed into ccPDP.

Comments from the Arabic team for domain names regarding the fast track draft 
interim report (Ibaa Oueichek, 22 April 2008)
1) The report clearly identifies the Purpose of Fast Track as "to meet pressing 
demand". However, it defines its scope as "experimental in nature". Our worry 
is regarding the meaning of "experimental". "Experimental" should not mean that:
- The fast track delegations are temporary
- The registered domain names during the fast track could become invalid at a 
later stage!
- It should not discourage the application developers from putting their full 
support to IDN

SaudiNIC's comments on DRAFT Methodology for Fast Track, Abdulaziz Al-Zoman, 23 
Apr 2008
Idem comment Ibaa Oueichek (above)
ADNPP's Comments on the Discussion Draft of the Interim Report of the IDNC 
Working Group, Abdulaziz Al-Zoman, Wed, 23 Apr 2008
Idem comment Ibaa Oueichek ( above)
Comments by the National Telecom Regulatory Authority of Egypt on the Draft 
Methodology for Fast Track .
Christine Arida, 24 April 2008
*  Experimental in nature:  The report defines the scope of the fast track as 
"experimental in nature".  This should not mean that the fast track delegations 
will be temporary.  It should rather mean that all parties should 
collaboratively work together on solving any problems that may occur.

G: Limiting the number of applications
The criteria to select the IDN ccTLD string, and to designate the IDN ccTLD 
manager should determine the number of eligible IDN ccTLDs, not an arbitrarily 
set number.

RyC IDNC Comments, Chuck Gomes, 24 Apr 2008
-   There should be only one IDN ccTLD string per ISO 3166-1 entry per relevant 
script. Measures must be taken to limit confusion and collisions due to 
variants.
-   Confusingly similar strings should be avoided.


In section 2 a model is proposed that we think meets the above points and the 
guiding principles. This model is based on a four stage approach which maps and 
follows the activities, roles, and responsibilities of the actors involved. The 
model is devised to enable the relevant actors in the territory to self-asses 
and determine whether delegation of IDN ccTLD under Fast Track process is 
feasible, and enable them to prepare for a delegation request. Section 3 
contains notes on definitions and section 4 contains notes on the proposed 
testing stage (stage 3).


2. Proposed Fast Track model

Stage 1: Preparing for the Fast Track in Territory
This part of the process is performed in territory by the local actors involved.
RyC IDNC Comments, Chuck Gomes, 24 Apr 2008

 *   An IDN ccTLD string must represent an entry contained in the ISO 3166-1 
list.

1. Identify the language and script for the language
-     criteria: must be 'official' language (see section 3)
-     criteria: fast track is only for non-Latin scripts

2. Prepare language table
-     may already exist prepared by another territory using same 
language/script.
-     fast track should encourage cooperation, in accordance with IDN guidelines

3. Identify String
-     must meet technical and meaningful requirements


Public Discussion Dubai, 2 April 2008
Comment re 3. Identify String: It would be good if the IDNC group could come up 
with advice that territories should as a general rule use their short name for 
the string. Otherwise governments may try to use the full names - which would 
not be good for stability.

RyC IDNC Comments, Chuck Gomes, 24 Apr 2008

 *   IDN ccTLD strings should be meaningful to the local community and should 
represent, in scripts of the corresponding country or territory's choice, a 
meaningful representation of the country or territory's name or abbreviation of 
the country or territory's name in the selected script.

4.  Select intended IDN ccTLD registry

5. Get evidenced endorsement by actors in territory of proposed string and IDN 
ccTLD registry
-     Government, Local Internet Community, existing ccTLD manager


Stage 2: Evaluation

1. Place language table into IANA Repository

2. Have string checked/evaluated by 'Technical Committee' and 'Language 
Committee' (see section 3).


Intermediate change of Report, by Chris Disspain, 13 April 2008

Stage 2: Evaluation & Confirmation


2. Have string checked by 'Technical Committee' and confirmed by ' Committee of 
Linguistic Experts' (see section 3).


Source: Public Discussion Dubai, 2 April 2008.
Question re 2. Have string checked by 'Technical Committee' and confirmed by 
'Committee of Linguistic experts' against criteria: What is the role of the 2 
committees and how would they operate?

Answer: The Technical Committee's role is to check the string to ensure that it 
meets the IDNA Protocol and guidelines.  The Linguistic Committee's role is to 
confirm that the string meets the official language and meaningful criteria.

It is envisaged that the Technical Committee will need to check every string 
proposed. However the Linguistic Committee's role is much more limited since it 
would only need to confirm that the string meets the criteria in circumstances 
where the proposed string was not listed as the short name or formal name in 
the Technical Reference Manual for the Standardisation of Geographical Names 
(see 
http://unstats.un.org/unsd/geoinfo/ungegn%20tech%20ref%20manual_M87_combined.pdf).

It is also envisaged that the Linguistic Committee would call on linguistic 
experts in the particular language to confirm that the string meets the 
criteria.
On Stage 3: Reporting

Question: Where testing is done would that require actual registrations?

Answer: No. This refers to technical testing not registrations..


Stage 3: Testing
1. Have string.test delegated to ICANN and managed by proposed IDN ccTLD 
registry.

2. Experiment with string.test for 90 days (see section 4).

3. After 90 days complete and submit report on string.test phase (see section 
4).

4. Complete IANA request for delegation documentation.


Intermediate change of Report, by Chris Disspain, 13 April 2008

Stage 3: Reporting
1. Document experience with managing IDNs, including use of the proposed 
language table at second or higher levels & implementation of IDN guidelines 
and compliance with IDNA protocol.

2. Complete IANA request for delegation documentation.



Comments by the National Telecom Regulatory Authority of Egypt on the Draft 
Methodology for Fast Track.
Christine Arida, 24 April 2008

*      Reporting:   It should be made clear how reporting would affect the 
delegation on a IDN ccTLD.  Only technical problems should delay delegation 
until they are worked out.




Stage 4: Designation of IDN ccTLD

Request for delegation
-     In accordance with current IANA procedures
-     Insert string in the root according to appropriate procedures
-     Update Root zone file


3. Definitions

Official language:
For the purpose of the Fast Track, an 'official' language is one that has a 
legal status in the territory or that serves as a language of administration.

This definition is based on: "Glossary of Terms for the Standardization of 
Geographical Names", United Nations Group of Experts on Geographic Names, 
United Nations, New York, 2002.

For the purpose of the Fast Track a language could be demonstrated to be an 
official language:

 1.  If the language is listed as an ISO 639 language in Part Three of the 
Technical Reference Manual for the standardisation of Geographical Names, 
United Nations Group of Experts on Geographical Names (UNGEGN) < 
http://unstats.un.org/unsd/geoinfo/default.htm>;
 2.  If listed as administrative language for the relevant territory in ISO 
3166-1 standard under column 9 or 10; or
 3.  It is demonstrated/evidenced that the language is used in official 
communications of the relevant public authority in the territory and serves as 
a language of administration.

Comments from the Moroccan National Telecommunications Regulatory Agency (ANRT) 
regarding the DRAFT Methodology for Fast Track EL MAAYATI Afaf, 24 April 2008,
The link between point "a" and "b" is not made (if it's an "and" or an"or").
Does it indicate that we should have: condition "a" and (condition "b" or "c")?


Meaningful string:
For purpose of the Fast Track process a string is meaningful if it is:
a)   the name of the territory in the selected language; or
b)   a part of the name of the territory in the selected language denoting the 
territory in that language; or
c)    an acronym of the name of the territory in the selected language denoting 
the territory in that language.

If the proposed string is demonstrated to be listed as such in the Technical 
Reference Manual for the standardisation of Geographical Names, UNGEGN, Part 
Three column 3 or 4, it is considered to be meaningful for the purpose of the 
Fast Track. In other cases, it has to be demonstrated in another way.

Language Committee:
A small committee tasked with checking that the proposed string is in a 
language that is 'official' in the territory and is meaningful in accordance 
with the definition.

Intermediate change of Report, by Chris Disspain, 13 April 2008
Committee of Lingsuitic Experts:
A small committee tasked to confirm that the proposed string is meaningful in 
accordance with the definition.


Technical Committee:
A small committee tasked with checking the proposed string against the IDNA 
Guidelines to ensure it will not cause any technical issues (for example a 
string in Cyrillic that appears to be the same as a string of ASCII characters).


4. Testing stage

The string.test phase of the Fast Track serves the following purposes:

a) The intended IDN ccTLD manager gains experience with the IDN ccTLD;

b) The stakeholders in the territory are prepared and informed on the possible 
introduction of the IDN ccTLD and have the opportunity to demonstrate support 
and endorsement of the selected language, script and string for IDN ccTLD;

c) There can be technical testing of the language table and proposed string and 
the opportunity for the intended IDN ccTLD manager to demonstrate and evidence 
compliance with IDNA protocols and guidelines and the maintenance of security 
and stability;

d) To enable the IDN ccTLD manager, at the end of the 90 day test period, to 
provide a report which covers at least following:

(i) Compliance with IDNA protocols and guidelines and how it was demonstrated 
in string.test phase;
(ii) Community use of and any potential limitations of language/script table;
(iii) Statistics on use;
(iv) Overview of any problems using the IDN ccTLD (similar to the current wiki 
tests in example.test)
(v) Involvement in string.test phase of local internet community, relevant 
public authorities and ccTLD manager, demonstrating near term demand. (for 
instance by providing user statistics, public consultations and information 
sessions etc.)


Intermediate change of Report, by Chris Disspain, 13 April 2008

4. Reporting experience stage

The purposes of reporting is:

a) The intended IDN ccTLD manager documents its experience with IDN's;

b) The stakeholders in the territory have been prepared and informed on the 
possible introduction of the IDN and have the opportunity to demonstrate 
support and endorsement of the selected language, script and string for IDN 
ccTLD;

c) There has been testing of the language table and the opportunity for the 
intended IDN ccTLD manager to demonstrate and evidence compliance with IDNA 
protocols and guidelines and the maintenance of security and stability;

The intended report would cover at least following:

(i) Compliance with IDNA protocols and guidelines and how it was demonstrated 
in test phase;
(ii) Community use of and any potential limitations, and problems relating to 
the use of the intended language/script table;
(iii) description of potential cross-TLD registration conflicts, and intended 
resolution process, if any (for instance sunrise, dispute resolution methods);
(iv) Statistics on use;
 (v) Involvement in testing of local internet community, relevant public 
authorities and ccTLD manager, demonstrating near term demand. (for instance by 
providing user statistics, public consultations and information sessions etc.)


Comments from the Moroccan National Telecommunications Regulatory Agency (ANRT) 
regarding the DRAFT Methodology for Fast Track EL MAAYATI Afaf, 24 April 2008,
(iv) Statistics on use;

As the IDN domain names are available for an experimental use in the country, 
the statistics in this case will not be significant.


Additional Topics, not covered by methodology


Agreement with ICANN:

Source: Public discussion Dubai 2 April 2008-06-09
Paul Twomey indicated that ICANN would expect any IDN ccTLD manager to enter 
into an agreement with ICANN at the very least, specifically relating to IDN 
issues.

It was clarified that it was not the job of the Working Group to make 
recommendations to the board how to deal with this or recommend  such a legal 
arrangement.  However, the Working Group may decide to make a statement such as 
"Although delegation should be treated the same way as an ordinary ccTLD, there 
are specific IDN related issues that need to dealt with in an agreement".

The attendees were asked whether they felt that the principle of signing a 
piece of paper between the operators and ICANN was acceptable.

There seemed to be a general acceptance of the principle. One of the 
participants said that it would actually be desirable to have such a document 
in place but it would need to be provided in a translated format.

It was asked whether the ccTLD would need to sign an Accountability Framework 
for the Ascii ccTLD before the IDN ccTLD will be delegated. It was clarified 
that this would not be required.

A comment was made that in a worst-case scenario, where a delegation needs to 
be withdrawn due to technical stability issues, some sort of agreement would be 
useful.

ICANN was requested to publish a document prior to the Paris meeting setting 
out the matters and issues that would need to be covered by an agreement with 
the IDN ccTLD manager. ,


Source: Comments from the Arabic team for domain names regarding the fast track 
draft interim report (Ibaa Oueichek, 22 April 2008)
2) Regarding delegation of IDN ccTLDs
- Countries/registries should not be forced to sign documents/agreements they 
believe would limit their full control over their IDN ccTLDs
- Signing documents/agreements may involve very heavy and slow governmental 
process that contradicts the fast track concept

SaudiNIC's comments on DRAFT Methodology for Fast Track
Abdulaziz Al-Zoman, 23 Apr 2008
Idem comment Ibaa Oueichek ( above)

ADNPP's Comments on the Discussion Draft of the Interim Report of the IDNC 
Working Group, Abdulaziz Al-Zoman, Wed, 23 Apr 2008
Idem comment Ibaa Oueichek ( above)

Comments by the National Telecom Regulatory Authority of Egypt on the Draft 
Methodology for Fast Track .
Christine Arida, 24 April 2008

*      Agreements:  Countries / registries may be encouraged to sign some light 
weight agreements with ICANN, yet this should not be a condition for IDN ccTLDs 
delegation.


RyC IDNC Comments, Chuck Gomes, 24 Apr 2008


 *   Operators of top-level domain registries for IDN TLDs representing 
territories designated by the ISO 3166-1 list should be required to follow the 
ICANN IDN Guidelines in the same way as gTLD registries that offer IDNs.
 *   ICANN should have a contract or some other form of agreement with the IDN 
ccTLD operator that includes appropriate technical, operational and financial 
requirements.

( confirming position GNSO Council)


Objection Procedure: Edmon Chung ( member of the IDNC WG) suggested that such a 
mechanism should be included along with the technical evaluation or linguistic 
confirmation procedure as it would increase the integrity of the process.

Chris Disspain said that he felt that it would be very challenging having such 
a mechanism in place, as it was an outside objection mechanism, which would 
mean that another territory or a company or a registry could object to a string 
proposed by the territory even if that string met the criteria..

Manal Ismail added that if the government and the community agree that the 
chosen string denotes the name of the territory, and if necessary the 
linguistic committee confirms , there should be no further input needed.

Comments by the National Telecom Regulatory Authority of Egypt on the Draft 
Methodology for Fast Track .
Christine Arida, 24 April 2008
*       Objection procedure:  Given that,

o Each country has the right to choose the string /name that represents its IDN 
ccTLD

o Fast Track is a fast process

o Fast Track deals only with non-contentious stings / names

o Fast Track deals only with non-contentious applications

o Fast Track accepts only strings/names agreed on by all 3: Government, current 
registry and local community

o Fast Track approves only strings/names approved by the technical committee

o Fast Track approves only strings/names confirmed by the linguistic committee

There should be no need for an objection procedure seeking more confirmations 
or approvals before a string is delegated.


IANA Guidelines:

It was pointed out that IANA needs to update their guidelines for who is 
eligible to submit language tables to the IANA Repository. Currently, only 
existing registries can do so. The guidelines need to open up for language 
table submissions from registries-to-be as well.

Comments by the National Telecom Regulatory Authority of Egypt on the Draft 
Methodology for Fast Track .
Christine Arida, 24 April 2008


 *   Submission of language tables to IANA: Only current registries are allowed 
to submit language tables to IANA.  Process should consider opening up for 
registries-to-be as well.



ICANN Staff Contact:  Bart Boswinkel

Attachment: 2008-06 Summary of public Discussions on the Draft Interim Report of the IDNC WG (BB)
Description: 2008-06 Summary of public Discussions on the Draft Interim Report of the IDNC WG (BB)



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy