FINAL VERSION 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.
The ALAC thanks ICANN Organization for the opportunity to comment on the very important topic of managing IDN Variant TLDs.
General Comments
IDNs in general, and IDN Top Level gTLDs and ccTLDs specifically, form an important consideration for Internet end users in several regions of the world, in particular East Asia, South Asia, Europe and the Middle East. Further, the Internet end-users who will benefit most are those unable to use the English language and the Roman script, many of whom are first-generation Internet end users. Considering that a significant chunk of the next billion end-users of the Internet may be speakers of lesser known languages and scripts, IDN variant domain names would provide an enhanced user experience, thus enhancing their trust in the Internet.
The primary issue in the context of IDN Variants at the Top Level arises from the fact that the DNS--as well other Internet systems such as browsers and email--work with a literal interpretation of an IDN label, whereas user communities use a fuzzy interpretation where multiple labels are considered equivalent. If such an equivalence does not work, Internet end users may end up confused.
Thus, a particular language community may consider t1 and t1v1 as equivalent in their script, but the DNS system does not recognize such an equivalence (unless specifically delegated as separate labels), and nor do browsers (therefore, https://s1.t1 and https://s1.t1v1 are different URLs with different session management) or email systems (therefore, name@s1.t1 and name@s1.t1v1 are distinct email IDs).
Improper handling of such equivalence of Variant TLDs may cause significant security issues, including phishing or other malicious attacks. Further, variants bring in additional manageability issues arising out the (possibly) large number of variants and the diversity options for managing them.
In summary, the main challenge while integrating IDN variant top level domains is to balance the positive user experience provided by variant TLDs on the one hand, with ensuring the security, stability and manageability of the domain name system, and the reduction of user confusion on the other.
Background
The current round of public comment on the topic originated from a 2010 ICANN Board decision that "no Variants of gTLDs will be delegated (...) until appropriate Variant management solutions are developed". Subsequent work by the ICANN community identified two distinct issues: (a) There was no accepted definition for Variant TLDs; and (b) There was no "Variant management" mechanism for TLDs.
Solutions have been proposed for these two issues. Root Zone Label Generation Rules (LGRs), developed by the community and adopted for implementation by the ICANN Board in April 2013, addresses the issue of a formal definition of Variant TLDs, while a comprehensive set of recommendations have evolved to address the question of managing IDN Variant TLDs. Based on community inputs to these solutions (represented as a set of documents provided), the ICANN Board is likely to reconsider its decision on Variant TLDs.
Specific Comments
The community has been asked to provide comments to four specific questions, which are treated separately below.
| Question | ALAC Advice |
|---|---|
1. The rationale for the RZ-LGR requires strictly adhering to the IDN variant label sets defined by the community through the RZ-LGR. Is this a reasonable pre-requisite for implementing IDN Variant TLDs? | The ALAC considers that the Root Zone LGRs which were adopted in 2013, and derived through a community process, are the most appropriate way of arriving at IDN Variant Labels, and that strict adherence to this process is reasonable. [Question: Will abandoning the legacy IDN technology cause any issues?] |
2. Do the proposed recommendations appropriately address the management and implementation of the IDN Variant TLDs? Do any suggested recommendations need to be changed? Why? Are any additional recommendations needed? | There are ten recommendations (3 core recommendations, 5 recommendations to minimize user confusion and enhance security and stability, and 2 additional recommendations for operationalization) that have been made. Specific comments on these are as follows: A. Core Recommendations R1. Root Zone Label Generation Rules (RZ-LGR) the only source for valid TLDs and their Variant Labels. Agree (already covered in Q.1) R2 IDN Variant TLDs {t1, t1v1,...} must be allocated to the same entity or withheld. Agree, as this restricts potential abuse of Variants. R3. Same second level labels under IDN variant TLDs s1. { t1, t1v1,...} registered to the same entity or withheld (ie., s1.t1 and s1.t1v1) Agree, for the same reason as #2 above. B. Recommendations to Minimize End-user Confusion and Enhance the Security and Stability of the Internet R4. Second-level Variant labels under IDN variant TLDs {s1, s1v1,...} on a variant TLD set {t1, t1v1,...} (ie., s1.t1, s1v1.t1, s1.t1v1, s1v1.t1v1) must be registered to the same entity. Agree, for the same reason as #2 above, and also because a combination of IDN Variants at Top and Second Levels simultaneously generates many combinations that would otherwise be difficult to manage. R5. Second Level IDN tables offered under IDN Variant TLDs harmonized. Agree, as it will enable integration of legacy labels with the current policy. R6. Second Level Variant label allocatable or activated under IDN Variant TLDs need not necessarily be the same. As a fictitious example, if {québec, quebec} are Variant TLDs and {léry, lery} are Variant Second Level labels, this recommendation appears to say that léry.québec and lery.quebec can be activated whereas lery.québec and léry.quebec are left inactive by choice. While this fine by itself, the question if email IDs such as jpierre@lery.québec would cause user confusion is relevant, at it would bounce (whereas jpierre@léry.québec would not). R7. Same registry service provider to be employed for IDN Variant TLDs. Agree. This would be desirable for consistent handling of Variant labels. R8. Same nameservers to be used for IDN Variant TLDs, unless otherwise justified. Agree as a desirable situation. C. Additional Recommendations: R9. Update/adjust existing policies and associated procedures to accommodate the recommendations for IDN Variant TLDs. Agree. This is essential for several strategic and operational reasons, including UAI. R10. All other existing TLD policies and procedures apply to IDN Variant TLDs, unless otherwise identified. It may be desirable to consider if IDN Variant TLDs require special treatment or promotion, particularly those from developing economies. |
| 3. Does the analysis suitably cover the impact of the recommendations on existing procedures for IDN ccTLDs and IDN gTLDs? Is there alternate analysis for certain cases? Are there any additional impacts on the procedures not identified? | Considering the gamut of recommendations by different parts of the ICANN community on IDNs in general and IDN variants at the top level in particular--including the concerns expressed by RSSAC--there appears to be adequate analysis on the impact on existing procedures for IDN ccTLDs and gTLDs. |
4. Which (if any) of the recommendations require policy consideration by GNSO and ccNSO, whereas the remaining would only have an impact on procedures? | The following recommendations may have policy implications that require consideration from GNSO and ccNSO: R2. Variants allocated to same entity or withheld (GNSO, CCNSO) R3. Second-level labels allocated to same entity (GNSO) R4, R5, R6, R7, R8 (GNSO and ccNSO) R9, R10 (GNSO and ccNSO) |
5. To prevent the permutation issue which can be introduced by using variant labels, as identified by SSAC, how may the allocated IDN Variant TLD labels be limited? Are the mechanisms suggested in Appendix C appropriate? What other factors may also be relevant? | The current LGR procedure maximizes Variant labels of the "Blocked" disposition (by blocking the whole label if one or more code points in it are of the "Blocked" disposition), and thereby minimizes the number of allocatable labels. However, it is insufficient to limit the numbers of Variant labels to a minimum set in many scripts. The ALAC suggests a further reduction in the allocatable labels may be required for some scripts (i.e., Arabic) in order to manage the numerosity of labels. Additional work may be required to identify contextual redundancies within a script in order to restrict Variants (for example, based on regional variations, community preferences, meaningfulness, LGR/IDN rule compliance, contemporary vs historic use, or usability/keyboard input constraints) in order to limit numerosity. Similar efforts are also required for managing the numerosity of Variant IDN labels at the Second Level. For a domain name (which combines variants at the Top and Second Levels), there may still be a "combinatorial explosion" after limiting the Top and Second Level Variants individually. Automatic Variant activation may exacerbate the situation, whereas a fee-based management regime (assuming that the fees are not prohibitively high) would help to contain the numerosity. It is therefore recommended that automatic variant activation is avoided. |
6. Are the risks and their mitigation measures sufficiently comprehensive? Are there any additional risks? Should there be different or additional mitigation measures? | While the recommendations are well researched and analyzed, one of the aspects that needs further attention is to do with certain procedures that are left to the discretion of Registry Operators. For instance, when there are a large number of valid variants arising out of variant top and second level labels, ROs are encouraged to put in further restrictions to limit the number of variants. Since such procedures are optional, there is no incentive for ROs to operationalize them. Another set of issues may arise out of transitional exception handling as these guidelines come into effect. Transitional exceptions are those that are temporarily allowed, but are eventually expected to be discontinued. ALAC recommends that to minimize further risks of such kind, that ICANN Org takes the initiative to bring together language communities, ROs and related practitioners to share experiences and learnings on a periodic or ongoing basis, noting particularly that many language communities may prefer to operate in their own silos. |
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).
Initial Draft for Discussion
The ALAC thanks ICANN Organization for the opportunity to comment on the very important topic of managing IDN Variant TLDs.
General Comments
IDNs in general, and IDN Top Level gTLDs and ccTLDs specifically, form an important consideration for Internet end users in several regions of the world, in particular East Asia, South Asia, Europe and the Middle East. Further, the Internet end-users who will benefit most are those unable to use the English language and the Roman script, many of whom are first-generation Internet end users. Considering that a significant chunk of the next billion end-users of the Internet may be speakers of lesser known languages and scripts, IDN variant domain names would provide an enhanced user experience, thus enhancing their trust in the Internet.
The primary issue in the context of IDN Variants at the Top Level arises from the fact that the DNS--as well other Internet systems such as browsers and email--work with a literal interpretation of an IDN label, whereas user communities use a fuzzy interpretation where multiple labels are considered equivalent. If such an equivalence does not work, Internet end users may end up confused.
Thus, a particular language community may consider t1 and t1v1 as equivalent in their script, but the DNS system does recognize such an equivalence (unless specifically delegated as separate labels), and nor do browsers (therefore, https://s1.t1 and https://s1.t1v1 are different URLs with different session management) or email systems (therefore, name@s1.t1 and name@s1.t1v1 are distinct email IDs).
Improper handling of such equivalence of Variant TLDs may cause significant security issues, including phishing or other malicious attacks. Further, variants bring in additional manageability issues arising out the (possibly) large number of variants and the diversity options for managing them.
In summary, the main challenge while integrating IDN variant top level domains is to balance the positive user experience provided by variant TLDs on the one hand, with ensuring the security, stability and manageability of the domain name system, and the reduction of user confusion on the other.
Background
The current round of public comment on the topic originated from a 2010 ICANN Board decision that "no Variants of gTLDs will be delegated (...) until appropriate Variant management solutions are developed". Subsequent work by the ICANN community identified two distinct issues: (a) There was no accepted definition for Variant TLDs; and (b) There was no "Variant management" mechanism for TLDs.
Solutions have been proposed for these two issues. Root Zone Label Generation Rules (LGRs), developed by the community and adopted for implementation by the ICANN Board in April 2013, addresses the issue of a formal definition of Variant TLDs, while a comprehensive set of recommendations have evolved to address the question of managing IDN Variant TLDs. Based on community inputs to these solutions (represented as a set of documents provided), the ICANN Board is likely to reconsider its decision on Variant TLDs.
Specific Comments
The community has been asked to provide comments to four specific questions, which are treated separately below.
| Question | ALAC Advice |
|---|---|
1. The rationale for the RZ-LGR requires strictly adhering to the IDN variant label sets defined by the community through the RZ-LGR. Is this a reasonable pre-requisite for implementing IDN Variant TLDs? | The ALAC considers that the Root Zone LGRs which were adopted in 2013, and derived through a community process, are the most appropriate way of arriving at IDN Variant Labels, and that strict adherence to this process is reasonable. [Question: Will abandoning the legacy IDN technology cause any issues?] |
2. Do the proposed recommendations appropriately address the management and implementation of the IDN Variant TLDs? Do any suggested recommendations need to be changed? Why? Are any additional recommendations needed? | There are ten recommendations (3 core recommendations, 5 recommendations to minimize user confusion and enhance security and stability, and 3 additional recommendations for operationalization) that have been made. Specific comments on these are as follows: A. Core Recommendations R1. Root Zone Label Generation Rules (RZ-LGR) the only source for valid TLDs and their Variant Labels. Agree (already covered in Q.1) R2 IDN Variant TLDs {t1, t1v1,...} must be allocated to the same entity or withheld. Agree, as this restricts potential abuse of Variants. R3. Same second level labels under IDN variant TLDs s1. { t1, t1v1,...} registered to the same entity or withheld (ie., s1.t1 and s1.t1v1) Agree, for the same reason as #2 above. B. Recommendations to Minimize End-user Confusion and Enhance the Security and Stability of the Internet R4. Second-level Variant labels under IDN variant TLDs {s1, s1v1,...} on a variant TLD set {t1, t1v1,...} (ie., s1.t1, s1v1.t1, s1.t1v1, s1v1.t1v1) must be registered to the same entity. Agree, for the same reason as #2 above, and also because a combination of IDN Variants at Top and Second Levels simultaneously generates many combinations that would otherwise be difficult to manage. R5. Second Level IDN tables offered under IDN Variant TLDs harmonized. Agree, as it will enable integration of legacy labels with the current policy. R6. Second Level Variant label allocatable or activated under IDN Variant TLDs need not necessarily be the same. As a fictitious example, if {québec, quebec} are Variant TLDs and {léry, lery} are Variant Second Level labels, this recommendation appears to say that léry.québec and lery.quebec can be activated whereas lery.québec and léry.quebec are left inactive by choice. While this fine by itself, the question if email IDs such as jpierre@lery.québec would cause user confusion is relevant, at it would bounce (whereas jpierre@léry.québec would not). R7. Same registry service provider to be employed for IDN Variant TLDs. Agree. This would be desirable for consistent handling of Variant labels. R8. Same nameservers to be used for IDN Variant TLDs, unless otherwise justified. Agree as a desirable situation. C. Additional Recommendations: R9. Update/adjust existing policies and associated procedures to accommodate the recommendations for IDN Variant TLDs. Agree. This is essential for several strategic and operational reasons, including UAI. R10. All other existing TLD policies and procedures apply to IDN Variant TLDs, unless otherwise identified. It may be desirable to consider if IDN Variant TLDs require special treatment or promotion, particularly those from developing economies. |
| 3. Does the analysis suitably cover the impact of the recommendations on existing procedures for IDN ccTLDs and IDN gTLDs? Is there alternate analysis for certain cases? Are there any additional impacts on the procedures not identified? | Considering the gamut of recommendations by different parts of the ICANN community on IDNs in general and IDN variants at the top level in particular--including the concerns expressed by RSSAC--there appears to be adequate analysis on the impact on existing procedures for IDN ccTLDs and gTLDs. |
4. Which (if any) of the recommendations require policy consideration by GNSO and ccNSO, whereas the remaining would only have an impact on procedures? | The following recommendations may have policy implications that require consideration from GNSO and ccNSO: R2. Variants allocated to same entity or withheld (GNSO, CCNSO) R3. Second-level labels allocated to same entity (GNSO) R4, R5, R6, R7, R8 (GNSO and ccNSO) R9, R10 (GNSO and ccNSO) |
5. To prevent the permutation issue which can be introduced by using variant labels, as identified by SSAC, how may the allocated IDN Variant TLD labels be limited? Are the mechanisms suggested in Appendix C appropriate? What other factors may also be relevant? | The current LGR procedure maximizes Variant labels of the "Blocked" disposition (by blocking the whole label if one or more code points in it are of the "Blocked" disposition), and thereby minimizes the number of allocatable labels. However, it is insufficient to limit the numbers of Variant labels to a minimum set in many scripts. The ALAC suggests a further reduction in the allocatable labels may be required for some scripts (i.e., Arabic) in order to manage the numerosity of labels. Additional work may be required to identify contextual redundancies within a script in order to restrict Variants (for example, based on regional variations, community preferences, meaningfulness, LGR/IDN rule compliance, contemporary vs historic use, or usability/keyboard input constraints) in order to limit numerosity. Similar efforts are also required for managing the numerosity of Variant IDN labels at the Second Level. For a domain name (which combines variants at the Top and Second Levels), there may still be a "combinatorial explosion" after limiting the Top and Second Level Variants individually. Automatic Variant activation may exacerbate the situation, whereas a fee-based management regime (assuming that the fees are not prohibitively high) would help to contain the numerosity. It is therefore recommended that automatic variant activation is avoided. |
6. Are the risks and their mitigation measures sufficiently comprehensive? Are there any additional risks? Should there be different or additional mitigation measures? | While the recommendations well researched and analyzed, one of the aspects that need further attention are certain procedures that are left to the discretion of Registry Operators. For instance, when there are a large number of valid variants arising out of variant top and second level labels, ROs are encouraged to put in further restrictions to limit the number of variants. Since such procedures are optional, there is no incentive for ROs to operationalize them. Another set of issues may arise out of transitional exception handling as these guidelines come into effect. Transitional exceptions are those that are temporarily allowed, but are eventually expected to be discontinued. ALAC recommends that to minimize further risks of such kind, that ICANN Org takes the initiative to bring together language communities, ROs and related practitioners to share experiences and learnings on a periodic or ongoing basis, noting particularly that many language communities may prefer to operate in their own silos. |
6 Comments
Krishna Seeburn
I fully support the core discussion points raised. The stability and a confusion free IDN is very important. The core examples signify the real potential issues. There is a need to ensure this stability. If we don't find a stable way of variant it wold definitely be an issue. Further to the quebec example we are coming close to the dummies email issue. Those with no internet understanding of domain names always say is your email address with a capital alphabet or small caps.
The IDN variants should not be causing more issues to that stability and principle. If we come up with an unrealisable variant then people could also have issues potentially with email addresses or domains. We may also be facing strict issues such as this example as well: kris.seeburn@Domain.com vs kris.seeburn@domain.com or even Kris.Seeburn@domain.com / Kris.Seeburn@Domain.com there are some variants that we need not confuse or play too much with. The DNS as well may create more confusion / stability/ reliability as well. So we may start having spanish / portugueese words as well as japanese words as we go. They may definitely help in language terms but close words may definitely be an issue.
It definitely creates more opportunities but we may definitely need to ensure some level of standardisation. Perhaps we may need to adopt standards such as relational databases do.
But overall yes we need to ensure how we move along those lines.
Krishna Seeburn
So the issue would also be what is the difference : YrjöLäns or YrjoLans. In essence it would be good to have the proper language used but also creates an issue for users. But if we are to proceed it would be to ensure we train people to understand the changes. Meaning we need to go on a sensitisation work to ensure people start understanding the new changes. It is a good thing for the original use but may not be an easy take for others.
Satish Babu
Thanks for the comments Kris. Agree on both points.
Eranga Samararathna
Thanks for the draft and I am support for main discussion points. Under questions, Additional Recommendations R10. In my view IDN Variant TLDs doesn't require special treatment from other TLDs. The original statement more make sense for me.
"Unless adjusted due to recommendation 9 above or other reasons identified and agreed by the community , because each IDN variant TLD is also
another TLD, all existing TLD policies and procedures for allocation and delegation remain applicable for IDN variant TLDs as well. "
Satish Babu
Thanks for your comemnt, Eranga.
The reason why the draft proposes special treatment for IDN top level domains is because it is possible that many individuals, communities and not-for-profits that may want use IDN TLDs may not have access to finance nor to trained personnel. Applicant support is of course part of a different PDP, and is mentioned here in passing.
Please let us know if there are any specific reasons why you feel financial or non-financial support is not required for IDN TLDs.
Eranga Samararathna
Thanks for clarification. I do agree. May be a good idea to elaborate R10 little more with fact present above (ex: lack of trained personnel).