ICANN ICANN Email List Archives

[comments-rpm-requirements-06aug13]


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

In support of Verisign's RPM Requirements comment

  • To: comments-rpm-requirements-06aug13@xxxxxxxxx
  • Subject: In support of Verisign's RPM Requirements comment
  • From: Andrew Snow <asnow@xxxxxxxxxx>
  • Date: Tue, 17 Sep 2013 00:20:57 -0400

       In support of Verisign's RPM Requirements comment, I would like
to offer the following comments for consideration:
             
1.      The .com and .net gtld strings and their transliterated IDN
equivalents in various languages -as applied by Verisign- are
essentially one and the same to the end users in these language markets.
For over fifteen years, these users intuitively and naturally have been
interchangeably using .com (in ascii) and .com (transliterated in local
script) without any distinction whatsoever, and will intuitively and
naturally continue to do so going forward. Any procedure, which results
in separate registrants for any of these user-interchangeable strings
will sow significant confusion and uncertainty in all IDN applied-for
language markets.
 
2.      The market insecurity that will arise from this confusion and
the many conflicts that will emerge will delay the scale and scope of
IDN adaptation. All IDN applied-for strings, including the new IDN
strings that are not the transliteration equivalent of an existing ASCII
string, will be negatively impacted. In some language markets the
straightforward simplicity needed for IDN uptake may be significantly
impeded, yielding a result that is directly inverse to ICANN's IDN
priority implementation policy.
 
3.      A "sunrise period" is a process designed to allocate domains
that do not yet exist to approved sunrise applicants for the purpose of
conflict avoidance, and as a rights protection mechanism to those who
have yet the opportunity to assert them - since the potential
rights-impeding property (domain) is yet to exist. However, the above
process is not properly applicable in the unique case of IDN .com/net
string transliterations, where de-facto (for end-users and in the
marketplace) the property may already long exist. Conflict, instead of
being avoided - is being assured.
 
4.      Many of Verisign registrant's IDN.com and IDN.net domains and
websites have been registered and operated for over a decade (some
nearly 13 years) - a more than ample de-facto "sunrise opportunity" to
assert any IP rights thru ICANN's long-standing and properly functioning
dispute processes for any gtld domain- a process which still can be
availed of at any time going forward.
 
5.      Domain names that were long-contestable utilizing ICANN's
dispute resolution procedures by those who have had ample opportunity to
assert any claim but never bothered to do so - should not be allowed to
be de-facto taken (rendered defective) from their lawful registrants
thru a late-door procedure which may be abused due to the partially
unknowable and inherent complexities of creating and overseeing
(non-ASCII) multi-scripts rights assertions from multi-jurisdictions.
Due to the above, even long-registered generic IDNs that would otherwise
be protected by the principles and precedents long established by
ICANN's dispute resolution processes can be put in jeopardy.
 
6.      Even domains that were already contested and wherein the
contester was rebuffed by a proper panel due to the fact that the domain
was registered before the trademark, can effectively be impacted - an
absurd legal result stemming from the rigid application of a mal-fitting
standard sunrise procedure that only looks at trademark assertion and
ignores all other facts and prior rights that may be associated with a
de-facto already-existing domain.
 
As such, I urge the support and adoption of the Verisign IDN
implementation plan.
 
 
Sincerely,
 
Andrew J. Snow
Westport, CT
 
 
 
 


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

Privacy Policy | Terms of Service | Cookies Policy