Re: [council] Re: Regarding issues report on IDNs

[Sophia B <sophiabekele@xxxxxxxxx>]

John, All

Thank you for your response.  Marilyn, the answer to both your
questions below to me is YES.

Please allow me to present this historic perspective, as well as some
relative considerations regarding the IDNs.

1) It is my understanding that ICANN has a fully authorized TESTBED still
ongoing with VERISIGN, operating almost 200 languages under ".com".   It is
also my understanding that the author of the DNAME proposal draft (published
in Vancouver) is from VERISIGN (they are the champions of this and the
author of the document is a fellow who launched the first Versign testbed.
Is it also a fact, pls correct me if I am wrong, to state that this process
sold 1 million names in 200 languages, but really did not address the
long-term solution? uhmm.

Further. John in his document suggested 20 languages for each TLD just for
the TEST right?.  Suppose 20 languages or 200 languages may NOT be
considered EVERY language, how about when we have two million languages?
Someone mentioned that nobody is going to put every language in every
equivalent of say ".com" translated. etc. or that English is the root
language of the Internet. Can we you think here that  "WWIII" may not be a
problem.   I do.

2)- Unfortunately English is the default language of the Internet today and
it is likely to continue to be. Nobody questions that in a serious way - but
what everyone wants I believe is a reasonable usable field in every major
language today etc. for non-english speaking populations.  Without having
to be condescending to the "non-West" as I am certain they
do understand English is here to stay, what we want to do is really keep the
other languages alive.  From what I have gathered, it seem that past
discussions on this issues suggest 'Textbook thinking" without due
consideration of  is what the "non-US/West" wants.   If we out to call it
IDN and ICAAN represents a true international organization, we need to NOT
only talk the talk, but walk the walk, applying  the cornerstone of
globalization in a realistic way,  'think global, act local'.


3) I may be presumptuous, but ICANN's argument of resorting to using DNAME
seem to come  from the perspective of how ICANN failed to be responsive for
long and now "China" and others are threatening to "break the single
root".  Therefore, perhaps, we were left to a single view and a quick
solution, neglecting to entertain the CHOICES we may have for IDN.  So, the
easiest implementation approach is DNAME, which is is to just give the big
registries all the languages without having to change much in the technical
stuff - ie. just re-point.com to every language equivalent - no new TLDs
etc.

John's statement butteres this point:

If a such programmer in China were to decide that, for her users to have a
good experience, .US and .COM should be able to be referenced by using
Chinese names, there is nothing that the GNSO, ICANN, IETF, ITU, or the
Great Pumpkin could do to stop or prevent it. Even the control of the
Chinese government would be _extremely_ limited, since those Chinese names
would be visible only to users of that particular application with that
particular extension, and not "on the wire" or to either DNS servers or the
sites or hosts being reached.

I think if this is the way we have looked at it, it seem that our response
is shortsighted (because it technical-oriented only and did not consider the
business issues)  and is perhaps why ICANN has failed achieve success in the
IDN arena.  Instead of worrying about the political, policy and
cultural implications, first, we may have focused on the easy way
out...technical.   In this case, contrary to what Cary said, I think  issuing
DNAME is equally reckless as using new TLDs in IDN.
The fact that the Chinese has already launched this process (if we out to
call them reckless)  and ICANN who ought to know better, is forced to
'follow' the same (can we call ICANN "reckless") as well?  Uhmm.


4) I quote Cary's section:   If the only means that were permitted for the
registration of an IDN TLD were the assignment of a DNAME record to a
pre-existing name tree, the effect on competition might be arguably
different than would be the case if both forms of IDN TLD delegation were
implemented. *It would exclude** **transliterated and translated versions of
pre-existing TLDs from delegation to separate operators, and there would be
disputes about what might constitute adequate semantic differentiation
for a new
TLD label*

Ok...let me attempt to analyse this...If they arranged for all
transliterations and translations of ".com" and ".info" before issuing new
true IDN TLDs, would the effect not be the same..e effect would still be the
same ...Verisign will get .com and neustar .biz in EVERY language and they
will get lions's share before regional groups could get started.  Like in
'Versign's testbed'  I mentioned above...before they will implement
languages in bulk and get caught up in the web of complicated local cultures
etc.

Are we failing to see, as ICANN that "freedom" from ICANN in their
languages, is what these countries want? .  Because if they know that ICANN
is just using a 'textbook' approach and launch IDNs thru western companies -
the situation will be WORSE for them.  I suppose there is a debate via ITU,
UN, IGF etc...about the English usage in local countries are controlled by
USA etc.  Now the local culture/language will also be controlled by USA
etc..not controlled in the 'manipulated' sense but in the "neglected" sense
when there are problems...uhmmm.  very complex.  It may be the same case as
the the Cambodians lost a "character" of their alphabet for 3 decades on the
computer because a Microsoft/Unicode engineer forgot and made a mistake...it
took decades of fighting to get it back.

The potential for dispute you mentioned Cary, will always be there.  The
question is, will it escalate?  Every person who ever bought a domain name
knows that they must trademark or copyright their name in another
country.    Everyone will know that they have to try to register again in
the new language domain space.  In fact if you want even in English to
protect your brand (like "mybrand") you need to buy "mybrand.biz" and "
mybrand.com", "mybrand.net" and "mybrand.info", and "mybrand.co.uk", and "
mybrand.cn", and "mybrand.de", and more and more, in as many ccTLDs related
to the counties you are active in.   Is it an added cost – Yes, but domains
are very very cheap, and yes if you want to do biz in another country or
language you must spend more - rent new offices, hire local people to speak
language etc.   This is standard business, I suppose, but the only people
who MAY be grumbling about these MAY be the existing registries that can
make a lot of money.

*Ok, pls correct me if I am wrong when I am trying to speak DNAME
implementation approach:*  eg. CEO of mybrand.com has to be protected in
every language under a gTLD that means "com" in every language, right
?  meaning they have to come up with 200 language translations of ".com" and
ICANN can approve DNAMES.  Then these companies, like Versign, can go and
get everyone of their.com name holders (40 million in this case) names
translated / transliterated into 200 languages to everyone's satisfaction
and register them all to get 200 x 45 million DNAMES.   *I hope I am on
right track so far.*   Are they also going to charge the CUSTOMER (who has
already paid some $6 already) for the translation/transliteration
work?   Also, if the customer then is upset by the accuracy of translation
or if the customer is sued by some other third party saying that the wrong
translation now impinges on their own business, will VERISIGN pay for all
lawsuit damages? I am almost certain that these companies will NOT agree to
this - but this is the result of DNAMES.

Finally, from where I see it, *policy is to be made first in complex
situations as these.* Technology is a second - fact is these systems seem to
have been working for years already, as China seem to have has deployed it
for years on a large scale - far larger than anything ICANN has done to
date, I believe.  Sure there could still be a little specific testing like
DNAMES - but hardly any policy agreement has happened on it, if it had, we
would not have the problems of these angry policy debates of UN on ICANN
etc...  I think we need to consider that technology has gone far ahead of
policy and that's why we need to consider the POLICY now.  I understand
that the last time ICANN did a TEST without policy, (the Versign testbed
sponsored by ICANN) , it had created the technical problems as well as
ICANN's IDN credibility among interested users.

Therefore, as Avil suggested, I propose the alternatives and solution should
be explored by a joint consultation with relevant IDN circles and the
Council.

I myself recommend the POLICY option.   Go for a solution letting the people
speaking a specific language (or script as they like to say) is a part of
their culture – to take care of it.  We can talk about specific
implementation strategies once we agree with the policy option!

*My footnote: *Cary,I know you have given me the licence to carry on..thank
you...and don't take this too seriously- in the DNAME test you said "one
informed expectation is as good as the other" ...well-said academically.
 Absolutely correct too.  But that's not necessarly real-life. If that were
the case - "what's the problem with letting Iran test more nuclear
technology after all they are doing it just for reducing their energy
dependence oil " (of course never mind they have more oil than they will
ever need). * Iran is just testing!*   Incidentally I guess freedom of the
press should allow those cartoons about Mohamed published in Denmark and
other European states right (sure, I believe that, but then I also know that
not all people are that *rational).*   The point is to be sensitive and
avoid dilemmas like this.  *We cannot think that the outcome is not a
predictable one* – as seen by the demonstrations all over the world and the
activities against Danish, EU and other facilities around the Moslem
countries.  *Are we thinking o**ne cartoon is as good as another* ...uhmm
and we do have freedom of the press, right?  Ok. bottom line is, we need to
re-think, before we get surprized by WWIII.

Sincere regards,

Sophia

--On Saturday, February 04, 2006 3:19 PM +0000 Marilyn Cade
< marilynscade@xxxxxxxxxxx> wrote:

> I am much appreciative of this kind of exchange which can
> advance the understanding of many of the non technical
> councilors, and our constituency members.
>
> Sophie, I think you have identified a concern I personally
> have abt DNAMES as I understand them, but I must study
> further. Does a DNAMES approach advance an extension of
> present Latin character gTLDs into non Latin character, but do
> not expand the underlying infrastructure competition.  Or do
> more?

Siohia to Marilyn:  I say YES to both your questions.

That is correct.  And, whether one is talking about a DNAME
> approach or a "new domain" one, the questions of which names
> should be allocated and on what basis remains.  For example, the
> decision to go in the DNAME direction does not, in itself, imply
> that .COM should be any synonyms, much less 400-600 of them --
> the case is more obvious for a small number of synonyms for each
> of the ccTLDs (or each of those that doesn't use Roman-based
> characters to express at least one of the names of its country,
> or...) than it is for gTLDs.  Note that "more obvious" does not
> imply "better": I have no personal position on that, partially
> because I do not believe that either DNAMES or new domains that
> are somehow linked to existing TLDs on some sort of entitlement
> basis are the right solution to the problem as seen by users.
>
> > For instance,  when we created the policy guidance for sTLDs,
> > and unrestricted/open TLDS, my view was that to fully
> > understand and take into account the implications of whether
> > policy for non Latin character strings policy was needed to
> > determine issues such as:
>
> I am not certain I can parse the above accurately, and
> consequently am not sure what the following four points (or at
> least the first three) mean.
>
> >  1) extend operation of non Latin versions to that registry
> > operator 2) prohibit that string in non Latin character 3)
> > assume new policy that would ask these questions.  4) Address
> > non-Latin chacteri gTLDs as is presently being studied.
>
> Please remember that one recommendation of the Katoh-lead IDN
> policy committee was that IDN TLDs be considered only in the
> context of new TLD applications (sponsored, generic, or
> otherwise) and independent of any existing domain (i.e., no
> proposals for them on the basis of linkage to an existing TLD or
> its registry).   In principle, nothing would have prevented an
> applicant in the recent sponsored gTLD round from including in
> the application a request for a IDNA-based non-ASCII name.
> Personally, it is not clear to me why such an application, had
> it arrived, should have been treated any differently than any
> other.  There might have been an issue with synonyms,
> translations, or transliterations of other names, but those
> problems could, in principle, occur and require consideration in
> the ASCII-only space.  So, for me, we should have separate
> issues of policy or principle with IDN TLDs only if an
> application or request is made on the basis on "rights" or
> "entitlements" to such names based on an existing domain that is
> named in ASCII characters only.
>
> Again, with the understanding that I'm not personally enamored
> of either approach, the notion of entitlements to new TLD that
> are somehow linked to existing domains causes me to consider
> DNAMEs an attractive option: not that everyone should be
> necessarily entitled to any name they might like, since that
> probably leads to madness and some DNS operational problems as
> well as some tough policy issues, but precisely because it does
> not imply "linkage" among TLDs, which is a far more complex
> problem both operationally and from a policy standpoint.
>
> One further comment from Cary's followup to Sophia's note...
>
> >> This creates BIG problems, a political one I must say, as for
> >> eg. US would have an equivalent in Chinese, Arabic, and
> >> others managed by Neustar.  I am not sure if the Chinese or
> >> Arabs will like that. On the other hand - Iran and Syria will
> >> have a Hebrew TLD  - I am note sure the Israelis would like
> >> that.
> >
> > As long as we are immersing ourselves in policy details of the
> > internationalization of the domain namespace, we would be well
> > advised
> > to think more than twice before making any statements that
> > assume the
> > legitimacy of the notion of language ownership. Which national
> > government owns the English language?  Which owns the Latin
> > alphabet?
> >  Which owns Cyrillic?  Are the Chinese language and script any
> > easier?
> >  Arabic?
>
> Let me add to Cary's comment a cautionary note about reality.
> That third strategy --of doing nothing in the root zone but
> simply providing translations or transliterations of TLD names
> in applications software-- is something that any competent
> programmer who can assemble a browser from a toolkit or who can
> implement an appropriate extension to a browser that supports
> such extensions can implement (and similarly for any other
> Internet application that calls on the DNS).  There are tens of
> thousands, perhaps hundreds of thousands, of such programmers in
> the world, and they are distributed across the world.  If a such
> programmer in China were to decide that, for her users to have a
> good experience, .US and .COM should be able to be referenced by
> using Chinese names, there is nothing that the GNSO, ICANN,
> IETF, ITU, or the Great Pumpkin could do to stop or prevent it.
> Even the control of the Chinese government would be _extremely_
> limited, since those Chinese names would be visible only to
> users of that particular application with that particular
> extension, and not "on the wire" or to either DNS servers or the
> sites or hosts being reached.
>
> So, for the GNSO to attempt to ban _that_ solution is precisely
> a "flat earth" issue.   There are many reasons to actually like
> that solution, and many reasons to dislike it.  But, especially
> if you conclude that you dislike it, you had best start thinking
> seriously about which of the DNAME or separate TLD solutions you
> like best and start promoting it.  Unlike another one of Cary's
> comments, I'm not convinced that pushing back on IDNs in the
> root would lead to fragmentation, although it is certainly a
> risk.  But, if ICANN were to tell people who want to be able to
> reference nationally-linked TLDs in their own languages and
> scripts that they just are not going to get that, I think either
> that third approach or fragmentation and alternate roots are a
> near-certainty... probably both, involving different parts of
> the world.
>
> regards,
>     john
>
>


--
Sophia Bekele
Voice/Fax: 925-935-1598
Mob:925-818-0948
sophiabekele@xxxxxxxxx
sbekele@xxxxxxxxxxx
SKYPE: skypesoph
www.cbsintl.com