[Comments-managing-idn-variant-tlds-25jul18] Comments to Recommendations for Managing IDN Variant Top-Level Domains

[Jerry Sen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/comments-managing-idn-variant-tlds-25jul18/attachments/20180904/ab3640ff/attachment-0001.html>