- comments-managing-idn-variant-tlds-25jul18@icann.org

[Comments-managing-idn-variant-tlds-25jul18] Ratified: Recommendations for Managing IDN Variant Top-Level Domains
by ICANN At-Large Staff Sept. 21, 2018

Sept. 21, 2018

Dear All, Please find attached the ratified ALAC statement on the Recommendations for Managing IDN Variant Top-Level Domains<https://community.icann.org/display/alacpolicydev/At-Large+Workspace%3A+Rec…>. Content of the statement remains unchanged. Ratification information has been included on the cover page. Kind Regards, ICANN Policy Staff in support of the At-Large Community Website: atlarge.icann.org<https://atlarge.icann.org/> Facebook: facebook.com/icann<https://www.facebook.com/icannatlarge>atlarge<https://www.facebook.com/icannatlarge> Twitter: @<https://twitter.com/ICANNAtLarge>ICANNAtLarge<https://twitter.com/ICANNAtLarge>

1 0

[Comments-managing-idn-variant-tlds-25jul18] Comments about “Recommendations for Managing IDN Variant Top-Level Domains"
by Raed AlFayez Sept. 17, 2018

Sept. 17, 2018

Dear ICANN, Please find attached our comments pertaining the announcement for public comments: “Recommendations for Managing IDN Variant Top-Level Domains<https://www.icann.org/news/announcement-2018-07-25-en>”. Sincerely Yours, Raed Al-Fayez SaudiNIC, CITC

1 0

[Comments-managing-idn-variant-tlds-25jul18] Pending Ratification: Recommendations for Managing IDN Variant Top-Level Domains
by ICANN At-Large Staff Sept. 17, 2018

Sept. 17, 2018

Dear All, Please find attached the ALAC Statement on the Recommendations for Managing IDN Variant Top-Level Domains<https://community.icann.org/display/alacpolicydev/At-Large+Workspace%3A+Rec…>. In the interest of time, the ALAC Chair requested that the Statement be transmitted to the ICANN public comment process with a note that the Statement is pending ALAC ratification. Kind Regards, ICANN Policy Staff in support of the At-Large Community Website: atlarge.icann.org<https://atlarge.icann.org/> Facebook: facebook.com/icann<https://www.facebook.com/icannatlarge>atlarge<https://www.facebook.com/icannatlarge> Twitter: @<https://twitter.com/ICANNAtLarge>ICANNAtLarge<https://twitter.com/ICANNAtLarge>

1 0

[Comments-managing-idn-variant-tlds-25jul18] Business Constituency (BC) comment on ICANN Recommendations for IDN Variant TLDs
by Steve DelBianco Sept. 17, 2018

Sept. 17, 2018

Attached is the comment of the ICANN Business Constituency (BC) regarding ICANN Org Recommendations to manage IDN Variant Top-Level Domains. This comment was drafted by Mark Svancarek. It was approved in accord with the BC Charter. Steve DelBianco Vice Chair for Policy Coordination ICANN Business Constituency

1 0

[Comments-managing-idn-variant-tlds-25jul18] RySG comments on Recommendations for Managing IDN Variant TLDs
by Paul Diaz Sept. 17, 2018

Sept. 17, 2018

On behalf of the gTLD Registries Stakeholder Group (RySG), please find attached our input on the Recommendations for Managing IDN Variant TLDs. In the interest of time, we did not conduct a vote on these comments. We did discuss them on our mailing list and during a biweekly conference call, and no member opposed their submission. Feel free to contact me with questions or concerns. Best, P Paul Diaz Chair, RySG

1 0

[Comments-managing-idn-variant-tlds-25jul18] Comments to Recommendations for Managing IDN Variant Top-Level Domains
by liangshuo＠knet.cn Sept. 15, 2018

Sept. 15, 2018

we make the following comments to "Recommendations for Managing IDN Variant Top-Level Domains" published by ICANN at https://www.icann.org/public-comments/managing-idn-variant-tlds-2018-07-25-…: 1. In order to “avoid including variant TLDs in a manner that would create user vulnerabilities or a probability of confusion”, and to ensure the healthy and stable operation of the domain name system, we agree with ICANN recommendations: IDN variant TLDs {t1, t1v1, …} allocated to the same entity, same second level labels under IDN variant TLDs s1.{t1, t1v1, …} registered to the same entity, and Second-level variant labels under IDN variant TLDs {s1, s1v1, …}.{t1, t1v1, …} registered to the same entity. 2. According to the premise that “Active IDN variant TLDs should be minimized”, we agree to strictly manage the IDN variant TLDs, and the IDN variant TLDs should be applied by each IDN registry based on actual conditions. 3. We recommend that the registry of IDN variant TLDs should develop its own registration and price policy for the second-level domain under IDN variant TLDs, under the principle that "Same second level labels under IDN variant TLDs s1.{t1, t1v1, …} registered to the same entity". In addition, the management of the IDN variant TLDs and its second level labels follows the management of the primary domain name. It is recommended to pay only the primary domain name management fees to ICANN. For example, the primary IDN TLD is t1, and the variant TLD is t1v1, then only pay ICANN the management fee for t1. In the case of Chinese IDN variant TLDs. Chinese includes Simplified Chinese and Traditional Chinese. Without considering the simplified and traditional form of second-level domain, registrants need to register "s.t1" and "s.t1v1" two domain names, and may pay 2 registration fees. In this case, it is likely that the registrant will only select one of the domain names to register. After all, another domain name will be reserved for the same registrant. This registration policy is not conducive to the common development of Simplified Chinese domain names and Traditional Chinese domain names. 4. We agree that "IDN variant TLDs {t1, t1v1, …} allocated to the same entity", but we disagree that "each variant label in a set should be a separate TLD application". For example, Simplified Chinese is simplified from Traditional Chinese. These two Chinese characters are corresponding; And Simplified Chinese and Traditional Chinese are distributed in different regions, they are coexisting and intersecting. The simplified and traditional form of a Chinese domain name is like the capitalization and lower case of an English domain name. It should not be a separate TLD application. 5. We recommend that the IDN Variant TLD application can apply Fast Track Requests. As long as IDN TLDs and their variant labels defined by the RZ-LGR, it is eligible for application. If the existing IDN TLD operates compliance with ICANN's operating standards for registries, and promises to comply with the basic principle of "Recommendations for managing IDN variant TLDs", the application complying with RZ-LGR shall get the approval and delegation. Best Regards, Lisa Liang KNET Co., Ltd.

1 0

[Comments-managing-idn-variant-tlds-25jul18] comments from the end user perspective
by 王伟 Sept. 6, 2018

Sept. 6, 2018

I am glad to see that ICANN generated and published the recommendations for Managing IDN Variant Top-Level Domains. The recommendations give a clear guidance to the concerned parties on how to handle domain name variant properly, and to prevent the domain name confusion. However, according to my experience, most end users have few knowledge about the exact rules of variant domain names, and there is no effective tool which could help end users recognize variant domain name or remind them of the potential risk caused by the domain name similarity abuse, when they access web site, send emails or search whois information. I exchanged the concerns with some ALAC members, personally, I'd like to suggest ICANN and the community, along with the IDN project, to development a tool/service that could monitor if the registries and registrars operate strictly under the IDN variant recommendation/regulation, as well as provided to third parties and end users to improve their practice and skill. Best, Wei WANG

1 0

[Comments-managing-idn-variant-tlds-25jul18] Comments to Recommendations for Managing IDN Variant Top-Level Domains
by Jerry Sen Sept. 4, 2018

Sept. 4, 2018

We make following comments to Recommendations for Managing IDN Variant Top-Level Domains: Q1. 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? Yes. Initially there was no accepted definition for variant TLDs. The ICANN Board did not support the delegation of variants of gTLDs in 2010 yet the RZ-LGR Procedure resolved this issue. If we do not follow the standard of RZ-LGR, there must be some disputes on IDN variant string sets. In that case, it will be hard to move forward the variant TLD program. And it might not be easy to get the approval from ICANN board. Therefore, we think RZ-LGR is the premise and foundation of IDN Variant TLD program and should be strictly followed. Q2. Do the proposed recommendations appropriately address the management and implementation of the IDN Variant TLDs? By and large, the proposed recommendations appropriately address the management and implementation of the IDN Variant TLDs. In order to maintain the stability of the root zone, reduce end-user confusion, address end-user security, and help manage the variant labels in a stable manner, we totally agree to the 3 core recommendations and consider the 4 to 10 recommendations are reasonable and acceptable. a. Do any suggested recommendations need to be changed? Why? No. b. Are any additional recommendations needed? No. Q3. 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? Basically, we agree to the analysis in Part 3 of Document C. However, as mentioned in article 3.2.1, "As this study recommends that the application process (and thus the application fee) for a variant will be same as for the gTLD label, this should encourage conservative allocation of variants.", under the standard of "IDN variant TLDs {t1, t1v1, …} allocated to the same entity", it is unreasonable to apply IDN Variant TLD as a completely new gTLD and follow the full application procedure of the first round. We actually think IDN Variant TLDs are the supplements of existing IDN TLDs, which may meet the demand of minority groups. Besides, a large number of variant labels (e.g., the combination of simplified Chinese and traditional Chinese) are meaningless. Since IDN variant TLDs will be allocated to the same entity, and more strings mean more cost (at least USD 6,250 per season), it is enough to restrict irrational and massive applications. Completely following the new gTLD application process will only cost registries more on fund and manpower, also cost ICANN more on manpower. Therefore, we think it's essential to simplify the IDN Variant TLD application process, yet a full copy of new gTLD application process is meaningless. Q4. Which (if any) of the recommendations require policy consideration by GNSO and ccNSO, whereas the remaining would only have an impact on procedures? We do not suppose there is any need of policy consideration by GNSO or ccNSO. Considering the diversity of practical applications in IDN variant TLDs, and under the principal that "same second level labels under IDN variant TLDs registered to the same entity", ICANN should leave to IDN Variant TLD registries to develop their registration rules and pricing. We agree to manage each IDN variant TLD as an independent TLD and the registry operator shall pay management fees to ICANN. Q5. 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? Considering the stability of the root zone and the whole DNS system, we agree to manage IDN variants strictly. As not every IDN TLD variant has practical value, IDN TLD registries should apply on demand. Before delegation, each IDN Variant TLD should pass the PDT. It should also be managed like existing gTLDs independently. Nevertheless, since ICANN has reviewed all applicants' technical, operational and financial ability during the first new gTLD round, all existing gTLD registries have passed the evaluation and own several years' operation experience, and the recommendations limit that "IDN variant TLDs allocated to the same entity", a reduplicate application procedure is a waste of resource and will reduce the efficiency of the whole process. We recommend that application of IDN variant TLD follows a fast track similar to ccTLD applications. A IDN variant TLD applicant should promise to undertake the principal of "same second level labels under IDN variant TLDs s1.{t1, t1v1, …} registered to the same entity" and the original registry operator should comply with ICANN contract and consensus policies. In this context, applications complying with RZ-LGR shall get the approval and delegation. Meanwhile, it is unnecessary to wait for the next round to open the IDN Variant TLD applications. Also, the submission of applications should not be limited to a batch but base on the actual need of IDN registry operators. Applications of IDN Variant TLDs may be conducted on a rolling basis. Q6. Are the risks and their mitigation measures sufficiently comprehensive? Are there any additional risks? Should there be different or additional mitigation measures? Yes. We believe that the risks and their mitigation measures are sufficiently comprehensive and there is no additional risk. by Jerry Sen from Dot Trademark TLD Holding Company Limited

1 0