EURid comment

["Giovanni Seppia" <giovanni.seppia@xxxxxxxx>]

Please find below the comments of EURid, the registry manager of .eu, on
the synchronized IDN ccTLDs implementation plan.

 

A PDF version of the comments is attached for your convenience.

 

Kind regards,

 

Giovanni Seppia

 

 

***

 

Following the publication of the Proposed Implementation Plan for
Synchronized IDN ccTLDs, EURid hereby submits its comments.  They take
into account the information provided in the document "Synchronized IDN
ccTLDs - Questions and Answers".

 

Background

We have adopted the notation syncTLDa and syncTLDb from the Q&A document
to refer to 2 synchronized IDN ccTLDs. 

 

End user expectations

The whole document starts from the assumption that the end-user expects to
find the same content when clicking on or typing either of the urls
www.domainname.syncTLDa or www.domainname.syncTLDb. This brings ICANN into
the area of regulating content which is far from the ICANN scope and
mandate. Moreover, identical or similar domain names (in different TLDs in
the former case and in different or the same TLD in the latter case) are
often used for completely different content even when they belong to the
same registrant. E.g. www.microsoft.com and www.microsoft.eu have
different content, taking into account the cultural and/or regional
differences the company wants to address. This would be very similar to
www.domainname.syncTLDa and www.domainname.syncTLDb where syncTLDa and
syncTLDb are clearly TLDs for different language groups with potentially
different cultural sensitivities. 

 

Requiring that a URL based on a domain name in syncTLDa results in
identical or similar webcontent in syncTLDb is much too restrictive and
clashes with high principles such as freedom of expression.  As a matter
of fact, there might be a language and/or cultural aspect that the
registrant wishes to address by having different websites.  At registry
level, this requirement implies a call for action to inspect the content
of the sites the domains are resolving into  (what is similar and what is
not - or where is the user expectation violated). 

 

EURid understands the concerns of ICANN for the end-users but this issue
can be better and more completely sorted out via the more liberal
requirement that the registrant of the synchronized IDN domain is the
same.  Therefore, it should remain the sole prerogative of the registrant
to decide whether different contents would be confusing to its public. We
are confident that the much more relaxed approach would give
satisfactorily results while being more flexible and open. 

 

Resolving of equivalent domains 

In the proposed implementation plan, it is stated that equivalent domains
". resolve to the same address or value." While it is the purpose to
"ensure appropriate user experience" the Q&A document admits that no
technical procedure exists to obtain this effect.   Indeed, requiring the
same NS and A records does not guarantee the same content of the related
websites. The opposite is even common practice today in virtual web
hosting, where completely different websites/URLs resolve to the same
machine. 

Imposing the same NS and A records requires the registrant to run all
applications on the same server, not allowing for optimization by
spreading applications over different machines in case of large
websites/applications.

 

Link to the Fast Track Process

The document considers the Fast Track process as being independent from
the synchronized TLD process : ". For string selection and validation of
synchronized IDN ccTLDs, all existing Fast Track rules and requirements
apply, .".  

 

This does not seem very consistent. The Fast Track requires the requested
string not to be confusingly similar with already existing strings
including itself as mentioned in the Q&A document: "[T]he synchronized IDN
ccTLDs cannot be confusingly similar.  They cannot be confusingly similar
to any other TLDs requested through the Fast Track Process or through the
gTLD Program, nor to any reserved words, blocked TLDs, or any TLDs
currently in the DNS root zone". 

It does not seem very logical to try to synchronize 2 versions of a TLD
while avoiding a "lookalike" extension that would emphasize the
synchronization aspect. 

Therefore, the Fast Track IDN process should not be seen as completely
independent from the implementation phase and allow for strings to be
confusingly similar:

-          If the confusingly similarity applies to the existing extension
of the requesting TLD and

-          If a synchronized approach is envisaged.

This view is completely in line with the statement provided in answer n.4
from the Q&A document: "The implementation plan for synchronized IDN
ccTLDs is intended to provide a procedure by which a very limited number
of variants of IDN ccTLDs can become eligible to initiate the String
Delegation step in the IDN Fast Track Process". Understood as "variants or
"lookalikes" are allowed if synchronized". 


The legacy

As the Fast Track Process is intended to allow for the IDN (syncTLDb)
version of an existing TLD (syncTLDa), the latter will contain many domain
names already. Even if the proposed synchronization mechanism in the Q&A
document would be satisfactory (quod non - see above), the mechanism for
the new IDN ccTLD to become synchronized with the existing (non IDN) TLD
is completely unrealistic.  It would require all registrants (in some case
millions of them) to set up new or modify their existing name servers at
the time of the start of the synchronized TLD to comply with the
synchronization rules. A much more realistic scheme would be to allow the
already existing names or the names being registered in synTLDa (existing
TLD) to be automatically reserved in syncTLDb (new IDN ccTLD) for the same
registrant.  Only when that registrant consciously "activates" the name in
syncTLDb by adding nameservers, would the TLD space remain consistent.


 

Conclusions

Taking into account the aforementioned considerations, we would like to
submit the following modifications to the Proposed Implementation Plan for
Synchronised IDN ccTLDs:

1.       To relax the definition of synchronized IDN TLDs and allow for
domain names that exist in one TLD to be reserved for the same registrant
in the remaining synchronised TLDs.

2.       To relax the requirement that domain names in the synchronized
IDN ccTLD have to resolve to the same address or value to the more logical
requirement of simply requiring the registrant to be the same for all the
versions of a domain name in the synchronized TLDs.

3.       To better link the Synchronised IDN ccTLDs implementation plan to
the IDN Fast Track process so that strings confusingly similar with the
existing string of the requesting TLD are allowed in case the synchronized
approach is chosen.

 

 

 

Giovanni Seppia

External Relations manager

 

EURid

Woluwelaan 150     

1831 Diegem - Belgium

TEL: +32 (0) 2 401 2750

MOB:+39 335 81 41 733

 <mailto:giovanni.seppia@xxxxxxxx> giovanni.seppia@xxxxxxxx

 <http://www.eurid.eu> http://www.eurid.eu

    

 

SIGNATURE

Attachment: EURidcommentstosynchronisesIDNccTLDproposal-12042010.pdf
Description: Adobe PDF document