FINAL VERSION TO BE SUBMITTED IF RATIFIED
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
FIRST DRAFT SUBMITTED
The first draft submitted will be placed here before the call for comments begins.
Summary of ALAC Responses to Work Track 4 Questions
The ALAC agree to allow single character IDN TLDs (4.1.1.) but we also recommend the consideration of additional policy safeguards such as community and local government support, and cultural-linguistic research (4.1.2). These additional safeguards must be harmonised with ccTLDs (4.1.4). With regards to the delegation and operation of IDN variant TLDs we believe that this is a complex issues when considered from an end-user perspective. Suggestions have been made with regard to their stability and resilience, and how this might best be approached to include end-user communities and other relevant stakeholders (4.1.3).
The UAI is important to the promotion of equal and consistent domain name acceptance. As a civil society initiative, it contributes valuable information and guidance to the policy development process within ICANN (4.2).
We do not feel a need to differentiate between ASCII and IDN in terms of technical capacity of the applicant (4.3.1.1). We agree that technical evaluation should consolidate as much as possible (4.3.1.2) without any new and invasive evaluation of existing TLD operators (both gTLD and ccTLD) (4.3.1.2.1). Operational results (2012) show that templates demanded (and received) for the round were unrealistic (4.3.2.1) when the only demonstration needed should be proof of ability to maintain basic TLD operations and infrastructure (4.3.2.2). It is unclear why there was a requirement for financial plans when there was no penalty for wrong planning (4.3.2.3).
As no new risks or failure modalities are expected with regard to name collisions, existing policy safeguards may be sufficient (4.4.1). In general, a per-label security and stability review may not be required (4.5.1). While it is generally felt that the diversity of the root system can handle the additional load caused by "normal" new TLDs, special TLDs may require additional measures to maintain stability (4.5.2).
Please reference the "Work Track 4 Questions" document above for detailed questions asked
| Work Track 4 Question # | Joint Comment from Andrei Kolesnikov & Satish Babu |
|---|---|
| 4.1 Internationalized Domain Names | |
| 4.1.1 | We agree with the proposal to allow single-character IDN TLDs. For some language and cultural communities, the single character IDN TLD may be an option. This should not be applicable for a “mono-scripts”, such as Latin, Russian or Greek. But might work for China or neighboring countries, where a single hieroglyph might carry complete meaningful description. There are no major technical issues in single character IDN TLDs, but the potential for user confusion, in general, would be higher in these cases. It would be safer, from a confusability perspective, to permit such TLDs only on a case-to-case basis for particular languages, rather than by default. |
| 4.1.2 | For single-character IDNs, it would be prudent to consider additional policy safeguards such as the requirement for one or more of: 1) community support; 2) cultural-linguistic research paper(s); 3) local government support. |
| 4.1.3. | We believe that this is a complex issue when considered from an end-user perspective. Besides variants, there are also multiple options such as idn.ascii, ascii.idn, idn.idn and also the left-to-right and right-to-left variations. We suggest that this issue must be addressed taking through a participator process that includes end-user communities and other relevant stakeholders. Considerations include:
From a purely end-user centric position, priority should be given to IDN TLD in case of competing variant applications (such as IDN city name vs. ASCII city name in non-Latin language communities). On the matter of variant TLDs, from a stability and resilience perspective, we make the following suggestions:
|
| 4.1.4 | ccTLDs are generally an integral part of most IDN communities, and the local ccTLD plays significant role at the operational level as well as at the governance level. ccTLDs are thus an important stakeholder as any other SO/ACs for single char IDN TLDs and IDN variant TLDs. Therefore, the process of allowing single-character IDNs must be harmonized with ccTLDs, and single-letter TLDs should only be allowed in consultation with relevant ccTLDs. |
| 4.2 Universal Acceptance (UA) | |
| 4.2.1 | The Universal Acceptance Initiative (UAI) plays a significant role in the promotion of the equal and consistent domain name acceptance. However, this must not be mixed with policy development work within ICANN in order to keep the complexity of the things under control. For instance, the issue of similarity and confusability can be professionally reviewed by the UA group members, but only in form of participation of individual experts in appropriate policy development working groups within ICANN community. UAI, which is doing very valuable work, is a civil society initiative and not a direct ICANN initiative. As such, UAI cannot make binding policy, which has to be under ICANN. UAI can inform and guide the policymaking process in ICANN, but the policy process should proceed as a regular ICANN process. |
| 4.3 Application Evaluation | |
4.3.1 Technical Evaluation | |
| 4.3.1.1 | We feel that there is no need to differentiate between ASCII or IDN in terms of technical capacity of the applicant. The main required option for IDN applicant might be full UA compliance in terms of SRS front-end and Web. Since technical operations of the TLD is no more a new thing, only new technical centers/operators need to demonstrate capacity and operations prior to contract signing. One additional aspect that may need to be considered under technical capability maybe the need to collect, maintain, transliterate and translate IDN RDS/Whois information. |
| 4.3.1.2 | We agree that evaluation should consolidate as much as possible. |
| 4.3.1.2.1 | We agree that there is no reason to bring in new & invasive evaluation of existing TLD operators (both gTLD and ccTLD). One aspect that could be added in the case of currently-operated TLDs may be to check on history of quality-of-service issues with the applicant which would reflect the technical capability. |
4.3.2 Financial Evaluation | |
| 4.3.2.1 | Operational results from the 2012 round show that the templates demanded (and received) for the round were not realistic. ICANN should concern itself only about availability of funds to maintain the minimum/basic operations in order to keep TLD alive and not anything overly elaborate. |
| 4.3.2.2 | The only demonstration needed for financials should be the proof of ability to maintain basic TLD operations and infrastructure. |
| 4.3.2.3 | Business plans presented by applicants in 2012 did not really work. Since there is no penalty for wrong planning, it is unclear why there should be a requirement for financial plans. Therefore these can be dropped. |
| 4.3.2.4 | |
| 4.3.2.5 | |
| 4.3.2.6 | |
| 4.3.2.7 | |
| 4.3.2.8 | |
4.3.3 General Questions | |
| 4.3.3.1 | |
| 4.4 Name Collision | |
| 4.4.1 | In general, no new risks or failure modalities are expected vis-a-vis name collisions. Consequently, the existing policy safeguards may be sufficient. |
| 4.4.2 | |
| 4.4.3 | |
| 4.4.4 | |
| 4.5 Security and Stability | |
| 4.5.1 | In general, per-label review may not be required. |
| 4.5.2 | It is generally felt that the diversity of the root system can handle the additional load caused by “normal” new TLDs through the usual scaling up process followed by root server operators, assuming that names are gradually delegated. For special TLDs (which prove to be very successful in driving DNS traffic), additional measures may be required to maintain stability. |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
