|Date of Submission
|Staff Contact and Email
|IDN Variant TLD Program – Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels
|Rinalia Abdul Rahim (APRALO)
|Comment/Reply Periods (*)
|Important Information Links
|24 September 2012
|19 October 2012
|Close Time (UTC):
|Public Comment Announcement
|20 October 2012
|To Submit Your Comments (Forum)
|9 November 2012
|View Comments Submitted
|Close Time (UTC):
|Report of Public Comments
|To receive community feedback on the first public draft of the document "Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels" [PDF, 437 KB].
|The IDN Variant TLD Program includes a project to establish the Label Generation Rules (LGR) Process for the DNS Root Zone. The project team was formed to include expert consultants and a global team of volunteers. The project team has created a first public draft document and seeks community comment and input on the proposed process and the principles that support it.
|The Label Generation Rules process (LGR) Process will be discussed at the ICANN public meeting in Toronto in October 2012. Comments received in this forum as well as community feedback during the Toronto meeting will be incorporated into the final draft and published for second round of Public Comment in November 2012.
|Section I: Description, Explanation, and Purpose
The IDN Variant TLD Program has been exploring the issues associated with the potential inclusion of IDN variant TLDs in the DNS root zone at the request of the ICANN Board and the community.
The Label Generation Rules Process is a way to develop and maintain the Label Generation Rules for the Root Zone in respect of IDNA labels. This process must be in place to enable the delegation and management of IDN Variant TLDs. The Label Generation Rules (LGR) Process project team has produced the first public draft of the LGR Process document. The team now seeks community input on the process and the principles that support it.
The IDN Variant TLD Program follows on from the publication of the final Integrated Issues Report on 17 February 2012.The Program Plan was published after two rounds of public comment. The Label Generation Rules (LGR) Process project team was formed to include expert consultants and a global team of volunteers. After discussions on-line and a two-day face-to-face session, the project team has created the first public draft of the document on the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels, and now seeks community input on the LGR process and the principles that support it.
|Section II: Background
On 20 April 2011, ICANN announced the IDN Variant Issues Project to explore the issues associated with the potential inclusion of IDN variant TLDs in the DNS root zone. This project was initiated in response to a 2010 ICANN Board of Directors resolution. The project completed with the publication of the final Integrated Issues Report on 17 February 2012.
The IDN Variant TLD Program follows on from that work. The Program consists of several projects, and continues as a multi-phase multi-year program. The Program Plan was announced – after substantial public input and comment – on 23 August 2012.
One of the first projects in the new program is to develop the Label Generation Rules (LGR) Process for the DNS Root Zone. The approach taken was to form a project team of expert consultants supported by a global group of volunteers representing multiple scripts and languages. The formation of the volunteer group was announced on 23 August 2012.
The project team has had several discussions on-line and by telephone conference, and held a two-day face-to-face session in August. The project team has created its first public draft document on the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels, and now seeks community input and comment.
|Section III: Document and Resource Links
|Section IV: Additional Information
(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.
ALAC Response to Project 2.1 of the IDN Variant TLD Program
Dear IDN Variant TLD Program Team,
First of all, we thank you in advance for your willingness to receive comments from the ALAC regarding your work on Project 2.1 outside of the general public comments forum. Internationalized Domain Names (IDNs) continue to be a topic of high interest for the ALAC because of their broad implications on internationalization and multilingualism, as well as their value in respecting and supporting the multi-cultural diversity of the Internet. Most importantly, appropriate implementation of IDNs (including IDN Variant TLDs), is paramount to the adoption and spread of IDNs, which in turn advances the aims mentioned above.
In reference to the published draft of Project 2.1: http://www.icann.org/en/news/public-comment/lgr-procedure-24sep12-en.htm on “Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels,” we commend the excellent progress of the working team since Costa Rica, and we are encouraged by the inclusion of an ALAC observer in the working team. We also commend the proposed overall framework of utilizing a 2-panel/step process in the development of the label generation rule-sets for the root. We note and agree with the distinct roles of the two panels where the first panel focuses on fulfilling linguistic and community requirements of IDN Variant TLDs and the second panel reviews and checks the impact of the first panel’s proposal towards ensuring the security and stability of the root. This is consistent with the community consensus on a bottom-up approach, which allows different IDN language and script communities to form and move at their own pace in implementing IDN Variant TLDs.
We are, however, concerned by some aspects regarding the panels, particularly pertaining to the following points on formation and accountability:
- Lack of policy expertise specified for the panels. We understand IDN Variants to be matters of policy, related particularly to implementation (i.e., they may not be technical requirements, but are demanded by users and identified/treated by operators as a matter of policy). A purely technical view of the matter may render an overly simplistic binary view (i.e., approve/reject) without enough regard to the compromises necessary to balance the strict security and stability conservativeness versus the support needed for acceptable IDN implementation from the users' point of view. The former ultimately produces a tendency to “do nothing” whereas the latter could introduce some clearly identified risks, which could then be addressed. There is a need to balance these divergent needs and the capacity for doing so needs to be in place in the panels.
- Lack of expressed accountability and review of process. The proposed processes do not have a home in any of the Supporting Organizations of ICANN (i.e., ccNSO or GNSO) and they are not subject to any accountability and review processes. More specifically, it has been proposed that the secondary-panel be composed exclusively of paid consultants of ICANN and without any review mechanism of its processes. By participating in the working team, we further understand that the global pool of experts on the matter is also very small, which in turn raises additional concerns in the ALAC regarding the sustainability of the process and its safeguard against capture.
- Insufficient explanation of how the specific process of project 2.1 fits into the wider processes regarding new gTLD and IDN ccTLD. Even though much is beyond the scope of the project team, the way in which the output of the project fits in the overall processes at ICANN is important for all those concerned, many of whom may be new gTLD (and/or new IDN ccTLD) applicants (or aspirants). A clearer description of how current (and future) applicants and the evaluation processes are impacted should be provided.
The ALAC therefore advises the project team to:
(1) Include specific provisions to ensure the transparency and accountability of the process. For example: a) Identify how the bottom-up multi-stakeholder framework of ICANN is used in the maintenance and review of the process (i.e. how the SOs are involved); b) Include policy and community expertise in the oversight of the processes (e.g., as advisors to the panels); c) Specify measures and potential remedies to detect and mitigate against dereliction of duty; and d) Ensure the transparency of the deliberations and formation of the panels.
(2) Explicitly explain the problem of limited supply of the global pool of experts required for the panels (especially the secondary panel), and provide for necessary strategies and undertaking by ICANN to ensure the sustainability of the process and its integrity against capture. Furthermore, specify in more detail the qualities and requirements of secondary panel members in addition to their contractual relationship with ICANN. In our view, the secondary panel should be constituted primarily based on expertise and it should accommodate qualified individuals regardless of whether they choose to be remunerated or unremunerated by ICANN.
(3) Publish its reports in multiple languages and ensure that the process, including the formation of panels, respects the cultural diversity of the global IDN community. More importantly, the geographical and geo-political diversity of language communities should be taken into consideration in the formation of primary panels. Concurrently, the diversity of cultural backgrounds within the secondary panel should also be taken into account.
Finally, we thank you again for your willingness to listen and to understand our concerns. We are most appreciative of the proactive measures that you have taken to ensure our community’s engagement and contribution to the processes related to the IDN Variant TLD Program and all its projects.
The At-Large Advisory Committee