ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Please avoid further delays and proceed with delegating the needed variants IDN TLDs

  • To: sync-idn-cctlds@xxxxxxxxx
  • Subject: Please avoid further delays and proceed with delegating the needed variants IDN TLDs
  • From: Werner Staub <werner@xxxxxxxx>
  • Date: Fri, 16 Apr 2010 22:38:39 +0200

Dear ICANN Board members,

I urge you to avoid any further delays in delegating variant ccTLDs
under consideration as “Synchronized ccTLDs”.

It is true that, when taken literally from a purely technical
perspective, the Synchronized IDN ccTLD Plan even be
characterized as “unclear” or “unimplementable”. But we have
already seen a striking succession of misunderstandings
on this topic. We have to realize that:

 1) further delays are the biggest damage
 2) attempts to improve the plan now will cause more delays.

The variant TLDs can safely be allocated without (over)specifying
what the registries have to do. The local registries and
the local community know what is right in their language and
culture. But the registries concerned can live with Plan as it
stands. If the Synchronized cdTLD plan needs to be improved,
clarified, perfected, renamed, differentiated, etc, this can be
done later.

Here is an anecdote that illustrates how easily misunderstandings
arise, even just between Westerns.

In Nairobi, I made an Open Mic comment on this subject. This was
actually before the Plan was announced and I knew nothing about it.
I explained that controlled parallel operation of variant TLDs was
easy and straightforward. Harald Alvestrand then pointed out that it
is extremely difficult. We were both right, even though we were
saying the exact opposite. I was talking about the administrative
mechanism to achieve acceptable security, Harald was talking about
technical methods that would guarantee perfectly synchronized domain
name subtrees.

Asian experts described the best practice several years ago: the
registry (and the registrars) must treat the domains of one variant
set as one domain. This does not mean one object, but one concern
placed under the responsibility of one and the same party. That is
_much_ better than Western registries' careless treatment of variant
sets like “telefónica.com/telefonica.com”.

A practical tool for this comes with name servers and the
registrar-provided end-user credentials. The registry can impose
identical second-level name servers for the second-level domains in
the variant set. It can require registrars to give update
credentials to the same registrant for all domains in the same
variant set. This by itself does not ensure a completely
synchronized domain tree. But it offers adequate protection
against misuse. And that is the only problem to solve.


Werner Staub

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy