Home / Blogs

Suggestions on IDN Variant Management

To some applicants, ICANN's variant management policy in DAG4 has become a big obstacle to the new generic Top-Level Domain (gTLD) application. The policy is to delegate the string while reserving the variants, and these variants will not be delegated until a sound mechanism is developed and the desired variants are evaluated. But for some languages, Chinese for example, the so called string and its variant, namely simplified Chinese and traditional Chinese, are equivalent and must be simultaneously delegated.

The simplified Chinese and traditional Chinese are the two written form of Chinese language with the same meaning, which are simultaneously used by the Chinese language community. If only simplified Chinese TLD is delegated, while the traditional one is reserved,or vice versa, it means that while the internet is accessible to some people, it shuts down to some others. To address the concerns, we propose the following suggestions.

Firstly, for those ready-for-go IDN TLDs, their variants shall be configured as an equivalency to the primary TLD, i.e. one record in the root fits all.

Secondly, for those not readily prepared IDN TLDs, if the delegation of one single string is not acceptable by the applicant and the user community, one additional variant TLD is allowed to be registered in the root and resolved separately, other variants shall be reserved and blocked. The mapping of these TLDs is managed by the registry. It is the registry's duty to configure all the domain names and their relative alias or variant names registered (in TLD and SLDs) to be same or identical.

Thirdly, for those reserved variants, all desired strings shall be exclusive to the applicant, and those undesired strings shall be blocked.

We hope the suggestions will be helpful to the community facing the same variant issue and to the ongoing variant working group discussion.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Comments

looking for more details By Tina Dam  –  Sep 14, 2010 4:01 pm PDT

Hi Limei Lui, thanks for the suggestions. I completely understand the need for these variants to be delegated in order to serve the end-users best way possible. However, I am not sure I fully understand your ideas so I have some questions for you, for example you say:

"Firstly, for those ready-for-go IDN TLDs, their variants shall be configured as an equivalency to the primary TLD, i.e. one record in the root fits all. "

- how do you configure something like that equivalently, with one record in the root? As far as I am aware no such mechanism exists today.

"Thirdly, for those reserved variants, all desired strings shall be exclusive to the applicant, and those undesired strings shall be blocked. "

- do you mean that the configuration of domains and aliases/variants _across_ the two/multiple TLDs, in addition to the configurations of variants at SLD? If yes, then how do you propose that this is done for the two or more TLDs.

"Thirdly, for those reserved variants, all desired strings shall be exclusive to the applicant, and those undesired strings shall be blocked. "

- this is the intention behind the rules in both DAG4 and the Fast Track Process, namely that the indicated desired variants will be reserved for potential future delegation to the applicant - whereas all variants that are undesired will be blocked for use by anyone.

Tina Dam
Sr. Director, IDNs
ICANN

Add Your Comments

 To post your comments, please login or create an account.

Related

Topics

DNS Security

Sponsored byAfilias

Brand Protection

Sponsored byAppdetex

New TLDs

Sponsored byAfilias

Cybercrime

Sponsored byThreat Intelligence Platform

Whois

Sponsored byWhoisXML API

Cybersecurity

Sponsored byVerisign

IP Addressing

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign