Dear Mawaki and others,
Before GNSO council decide to initiate IDN-TLD PDP, I hope my concern
would be taken into account.
First of all, I should emphasize the present issues report has not enough
discussed even in last Marrakech meeting.
In the nearest past, with regard to IDN-TLD issue, IDN Committee had
already reported to the Board in its final report as follows.
(http://www.icann.org/committees/idn/final-report-27jun02.htm) Still,
these findings and recommendations should be taken into account.
1. Six possible categories of IDN-TLD strings were identified.
A. Semantic association with Geographic Units
B. Semantic association with Languages
C. Semantic association with Cultural Groups or Ethnicities
D. Semantic association with Existing Sponsored TLDs
E. Semantic association with Existing Unsponsored TLDs
F. Everything else.
2. For selection policy, those procedures for ASCII and non-ASCII
TLD should be harmonized. At least following criteria should be taken into
account.
A. Technical competence;
B. Support from relevant community of interest;
C. Independent evaluation panels; and
D. Incumbency preference issues.
However, regardless of these findings and recommendations, in last
September, Tina Dam asked questions regarding IDN-TLD in new TLD context.
She asked
c. What naming conventions should apply to the delegation of IDN TLDs(
consider objectionable strings, trademarks, TLD spoofing)? When should
proposed strings be referred for advice or vetting?
d. What are the rights of existing TLDs regarding IDN analogues,
homophones and other equivalents?
(New gTLD Questions Paper, By ICANN Staff,
http://www.icann.org/tlds/new-gTLD-questions.pdf )
Then, these questions were basically looking at IDN TLD strings in gTLD
context, and unintentionally, all other possibilities or "naming
convention" seems to be excluded.
And in GNSO, Bruce initially asked this question in a little different way
- "Is it from a policy standpoint advisable to create internationalized
equivalents of existing gTLDs?". (IDN Policy Issues - discussion paper)
Then, after Wellington meeting, this question has changed again into
following five possible scenarios in Staff's Issues Report.
a) A gTLD registry operator wishes to introduce an IDN based string that
relates to the existing gTLD.
b) A ccTLD registry operator wishes to introduce an IDN based string that
relates to the existing ccTLD.
c) A party may wish to introduce an IDN based string that relates to a
gTLD, in competition with the gTLD registry operator.
d) A party may wish to introduce an IDN based string that relates to a
ccTLD in competition with the ccTLD.
e) A party wishes to introduce a new IDN string with no relationship to an
existing TLD.
These scenarios happened to simplify all possible IDN-TLD strings into
three categories - gTLD, ccTLD related strings and anything else. But,
still whether this simplification is appropriate is still very
questionable. At this stage, what is the status of above mentioned IDN
Committee report for IDN-TLD of 2002?
In its inception, IDN-TLD was a strong demand and request of non-ascii
language community rather than that of any ccTLD or gTLD community. Hence,
we should be very cautious to reduce this request into that of ccTLD or
gTLD communities. Unfortunately, issues report didn't touch this concern
at all.
While gTLD is responding to that TLD string related community and ccTLD is
to its local internet community, IDN-TLD is responding to its own language
community. Therefore, we should take into account another possibility that
introduce new IDN-TLD as an independent and separate naming scheme
responding each language community separated from the existing ccTLDs or
gTLDs.
Still, we could not get some appropriate feedback from ccTLD community or
GAC. And if we proceed to initiate PDP, it means that we would consult
with them only assuming that gTLD related IDN-TLD must be available - this
is still very questionable. Did we get any positive feedback for this
question from ccNSO or GAC?
Also, last IDN Committee decided that test-bed would be implemented only
for NS record addition because at the moment DNAME approach is not yet
technically feasible specifically for some root servers and regarded as
premature particularly in IETF community. Therefore, it seems to be
inappropriate to initiate PDP at this moment because the basic assumption
of two parallel approaches is not yet valid. Otherwise, we should
completely exclude DNAME approach in PDP process.
--
------------------------------------------------------------
Chun Eung Hwi
General Secretary, PeaceNet | fax: (+82) 2-2649-2624
Seoul Yangchun P.O.Box 81 | pcs: (+82) 19-259-2667
Seoul, 158-600, Korea | eMail: [log in to unmask]
------------------------------------------------------------
|
