On 13/03/06, Tina Dam <dam@icann.org> wrote:

Hi Sophia, I will need to take some time to go through your entire email for
a full understanding or overview of your points. However, I wanted to reply
to your email right away to provide some clarification in one area.

In the question about policy vs. technical and what comes first it is
important to understand that we don't know at this stage if DNAME or NS
records will work well and keep the DNS stable and secure. So at this stage
there is not decision that either DNAME or NS records will be an option that
the GNSO can start developing policy around.

First we will be testing DNAME and NS records with IDN labels - when we know
the result then we know what options we have for deployment and hence what
policy questions we need to answer. The GNSO obviously need to be fully
briefed on what is going on in term of the technical test.

As we are getting really close to Wellington I hope we can spend some time
to talk over these various issues while there - either within the council or
in other groups as people may be available.

Best regards,
Tina Dam
Chief gTLD Registry Liaison
ICANN

Office: +1-310-301-5838
Cell: +1-310-862-2026

________________________________

       From: Sophia B [mailto: sophiabekele@gmail.com]
       Sent: Monday, March 13, 2006 11:04 AM
       To: John C Klensin
       Cc: Patrik Fältström; Marilyn Cade; Cary Karp; Tina Dam; GNSO
Council
       Subject: Fwd: [council] Re: Regarding issues report on IDNs

       This is the revised version with "name" references for those whose
email do not allow the color option. Thanks Patrick.  I hope this will
suffice. S

       ---------- Forwarded message ----------
       From: Sophia B <sophiabekele@gmail.com>
       Date: 13-Mar-2006 07:36
       Subject: Re: [council] Re: Regarding issues report on IDNs
       To: John C Klensin < klensin@jck.com>
       Cc: Patrik Fältström <paf@cisco.com>, Marilyn Cade
<marilynscade@hotmail.com >, Cary Karp <ck@nic.museum>, Tina Dam
<dam@icann.org>, GNSO Council council@gnso.icann.org

               "Sophia"
       Greetings John:

       I hope you are keeping well.    Here I am again back on the global
info super freeway…no STOP signs, so I must continue my dialog with you.
(pls refer to my comments in GREEN)

       Thank you once again for all your comments and your efforts on the
clarification.   It really helped.   I hope my late response did not create
a gap with the momentum that started.  I have to work for my living while I
concurrently run research on a subject that probability is like riding a
bicycle for you.  I can only hope I have come back to you with something you
may appreciate.

       I have observed from your last comments and clarifications that both
of us have a proportional amount of agreements.   Dispite your pointing to
the study of DNS, which I appreciate, my finding tells me that our
differences are more of a philosophical difference and than a major
technical gap.

       On 15/02/06, John C Klensin <klensin@jck.com> wrote:

               Sophia,

               I needed to take some days to consider your note and,
perhaps,
               to let things calm down a bit (I, of course, don't know what

               discussions have occurred on the GNSO Council list in the
               interim).  I hope the clarifications and comments below are
               helpful, but suspect that we are nearing, and may have
reached
               or passed, the point at which further comments from either a

               technical perspective, or even a "best interests of Internet
               users" one, are useful.

       Sophia

       I agree with you John and that is where I was fading away.  Mind
what started it all is a view questioned by many, a question of policy
making over IDNs vs. the need to a technical testbed of a technology that is
already well established.   We need to find a way that IDN TLDs will be
launched in the same process of new gTLDs i.e free for all open bid.

       Having said that, I am no expert when it comes to the IDNs.  The
only things is I got hooked with the substance in the details, which seem
more fascinating than the form.   As it is eating away my brain cells one at
a time, I may be inclined to hire a FULL TIME research assistance to keep up
with you.  In any case, I have laid out my thoughts and some of my fact
findings  for your interest, as well as defined some of the lingua franca of
IDN to re-enforce for myslef and other interested readers.

       John:

                       I am going to respond to both your note of the 6th
and that of
               the 5th below.  My apologies in advance for the length of
this
               note, but I'm going to try to respond to a number of
               almost-separate issues while trying to reduce the fairly
obvious
               level of confusion that underlies some of the questions and
               assertions.

               --On Monday, 06 February, 2006 00:00 -0800 Sophia B
               <sophiabekele@gmail.com> wrote:

               > Great...we are making the technical difference and that
they
               > can be separate .foo and .com and that they can be owned
by
               > two differ registrars and that could be competing with
each
               > other.

       John:
       At one level, that has always been the case and is self-evident.
       At another, it is extremely important that the Council
       understand how the DNS actually works, what the four major
       internationalization options are, how different options are seen
       by the user, and what their consequences and side-effects are in
       order to discuss these topics... at least from any standpoint
       other than narrow self-interest.

       Good tutorials on DNS operations, written with policy-makers in
       mind, are available; if you haven't been given the references,
       please ask.

       >  That point made, what I am trying to address is 2
       > business issues:
       >
       Sophia> 1- if 'mybrand' is to be protected  i.e trademark in every
       > country...it is a matter of purchasing all the 'mybrand'
       > TDLs...

       John
       It is at least a matter of "purchasing" 'mybrand' in _every_ TLD
       or of convincing relevant TLDs to not permit it to be registered
       (by you or anyone else).  However, note that you may not be able
       to do this and you may not want to.  Some countries require that
       you have a business locus in those countries to register in
       their TLDs, so, unless you open an office there, you may not be
       able to "buy" that name.  In others, your ownership of a
       well-known trademark (if "mybrand" is one) may be more than
       sufficient to protect you: you may not have to actually
       "purchase" (register) the name and might actually be better off
       not doing so.   Even if you manage to control all of the
       possible second-level domains of that name, you still need to
       make a judgment as to whether you have bought yourself adequate
       protection.   If "mybrand.TLD-name " is a problem for you,
       "mybrand.some-SLD-name.TLD-name " may also be a problem.  I note
       that, some years ago, a fairly well known trademark holder in
       the US decided to take exception to names of the form
          mickey.someschool.k12.fl.us <http://mickey.someschool.k12.fl.us/>
and
          minnie.someschool.k12.fl.us < http://minnie.someschool.k12.fl.us/>

       So far, none of this has anything to do with IDNs.  It might be
       an argument for not creating any more TLDs of any flavor, but it
       is worth noting that a new TLD increases your problem by well
       under 1/2 percent if names below the second level are ignored
       and by far less than that if they are considered.

       The place where IDNs enter in depends on whether you believe
       that, if you need to have control of every instance of "mybrand"
       in the DNS, you also need control of "muybrand" and
       "meinefabrikzeichen" (both of which can be perfectly well
       expressed in ASCII characters) or "xn--80aanvhbf1a" and a huge
       variety of other synonyms and translations.  One can, of course,
       make a case that you are entitled to, or should protect, all of
       those things (of which there are many thousands) but one could
       also suggest that, at some point, silliness sets in.

       Sophia
       I do not see a big problem with this, as long as protection of say
for example an "English" trademark in different countries (in English, as
well when translated into that countries native languages) can be achieved
at a cost that is far less than what it takes to trademark these things in
the first place in each country,.   For example if one had an ascii brand
name in say USA and then a company trademarked in 30 countries, they are
likely to (a) pay 31 times for "English language" trademarking fees at as
much as $1000 or more in each country and periodic/yearly maintenance fees
at some small fraction of that and (b) inclined to translate/transliterate
(or both) that English brand name into 31 different native languages and
then trademark all of them - ie. 30 times another $1000 assuming only one
native language per country, plus periodic maintenance fees for that and (c)
pay for all those 30 or more translations in the first place - decent
translations can easily cost $1000 or more and (d) perhaps pay also having
to trademark transliterations as well as translations in each native
language in each selected country.

       Noting that in most countries only one or two native languages
dominate, while spending these hundreds of thousands of dollars
translating/trademarking initially and then tens of thousands a year
maintaining these trademarks in the 30 countries, domain names may have to
be protected. To be reasonably complete, some 31 ascii ccTLD domains will be
registered and an additional 31 (or more if more than one native language is
desired per country and if transliterated as well as translated options are
both considered) in native language IDN TLDs for that country/region will be
registered. At prevailing domain costs per year the sum total cost of
registering this amount of domains (ascii and IDN) to approximately "mimic"
the trademark protection above should not exceed a couple of thousand
dollars. In the context of trademarking, these domain costs should be
probably a 100 times less than the initial trademarking related protection.
And the "labor work" of registering already transliterated/translated and
trademarked words/phrases as domain names is far less than the labor
associated with trademarking.

       So in short, from a biz perspective, the registering of IDN TLDs in
addition to ascii TLDs in places is acceptable in view of the far greater
cost/pain of the trademarking we already do today. As to whether it is wiser
not to register domains in regions where trademark cover is already present
inherently for domains, it is probably a legal decision depending on the
strengths of the laws and the willingness of the courts of the country to
actually uphold the law in a timely fashion during litigation. In fact given
the cost metric outlined above I would think most companies would simply
register it, rather than depend on the law to save them later.

       If the need to register many domains while trying to mimic the
tradmarking activity already embarked upon reaches the point of "silliness",
the trademarking activity itself will have reached a point of far more
costlier silliness well before that.   So I am not sure if we need to worry
about "silliness".   I think the market will take care of itself just as the
market today knows not to trademark in every language and every country etc.

       Sophia

       Sophia> 2-on the other hand, if mybarnd .com is to be protected 'in
       > every language' under gTLD, then 'com' in every language over
       > 200 translation need to be protected and approved by ICANN.

       John:
       First, as I think Cary has pointed out, "every language" puts
       one somewhere in the 6000 range, not 200.  What is more
       important is that this problem exists today, with no further
       action being required on the part of ICANN.  Using the
       admittedly crude examples above, " muybrand.com
<http://muybrand.com/> ",
       " meinefabrikzeichen.com <http://meinefabrikzeichen.com/ > ", and "
xn--80aanvhbf1a.com <http://xn--80aanvhbf1a.com/> " could be
       registered tomorrow if they have not been registered already.
       The only nuance that an IDN TLD system would add is the ability
       to refer to " xn--80aanvhbf1a.com <http://xn--80aanvhbf1a.com/ >  "
as something like
       "xn--80aanvhbf1a.xn--e1aajebclaqxm4e" (if using DNAMES or local
       aliases) or to register "mybrand.xn--e1aajebclaqxm4e" and
       "xn--80aanvhbf1a.xn--e1aajebclaqxm4e " in a new domain if
       separate domains were created.

       Sophia> So the guardians of this names i.eVerisign etc.. will be
       > translating and registering them.  ARe they passing
       > the cost to the customer? Are we going to approve over 200
       > maybe thousands of translations?

       John:
       This is, again, a situation in which being very clear about how
       the DNS actually works and about what one is talking about as a
       result is very important.  For example, if the DNAME approach is
       used, and a DNAME record named .xn--e1aajebclaqxm4e is installed
       pointing to .COM, then there is no difference between
          mybrand.com < http://mybrand.com/>  and
mybrand.xn--e1aajebclaqxm4e

       they are the same set of record entries.  By contrast, whether
       or not "xn--80aanvhbf1a.com <http://xn--80aanvhbf1a.com/>  " could
be registered, and on what
       basis, is strictly a registrar issue with the standard fee
       structure -- I believe that name could be registered today and
       that, if you didn't like it, you would need to go through a
       standard UDRP procedure.

       Sophia:

       Correct me if I am wrong, but URDP does not seem to have much to do
with IDNs per se.  I believe URDP- UNIFORM DISPUTE RESOLUTION POLICY- was
developed several years ago.for the ascii domains by itu/icann/world
intellectual property association (wipo) and adopted by all for resolving
domain disputes – for clarification for all interested readers, this how it
works…if you buy Dell's name Dell.com <http://dell.com/>  and insist on
squatting on it - Dell argues trademarks on the basis of URDP to get it
back. Over the past few years URDP more less in its intact ascii form is
being used to idn as well - at least as in idn.com <http://idn.com/>
varieties and presumably will be pushed by icann for full idn tlds as well.
(incidentally the Chinese have adapted a form of the URDP for their own use
in Chinese idn tlds they have launched).

       Computers can only think in ascii/english . So even multi-lingual
domain names have to be finally represented in ascii/english gobbledygook.
So for eg. a domain in Amharic (which is an Ethiopian native language BTW)
will get converted by a set of rules (enshrined now in a IETF standard
agreed to by all called the IDNA standard) that involve a language
representation mechanism called unicode into ascii-string.  The Amharic
names gets represented in this example as say "800aavhbf1a". We can
differentiate this "Amharic encoded" string as being different from a
straight ascii string "800aavhbf1a" by tagging it with "xn--" in front of
it. All "xn--" prefixes tell you its aâ  non-ascii/english domain. (the
encoding itself tells you which of many languages the domain itself is in -
a singular appeal of the unicode language representation is that it
represents all words in all languages mostly unambiguously inherently - it
was developed by people having nothing to do with the internet over decades
- linguists). In this case the domain tld is the normal ascii gtld
".com"...so we have an "Amharic domain represented in ascii
gobbledegook".com . ".com" itself being an ascii tld need not be translated
and represented as is. If we are proposing an Amharic word as a new Amharic
gtld, then we need to convert that via unicode and idna rules to say a
string "56yi0" and then we pre-pend with "xn-nn" to get the new amharic tlds
representation in ascii as "xn--56i0" so we get the full domain "
XN--800AAVHBF1A.xn--56i0". Note today if you wish to type the Amharic
domains and you want your browser to understand it you will need a plug-in
(except or mozilla which introduced it innately a few months ago) that helps
the browser do the Amharic to "xn--" conversion via IDNA and then sends that
converted name to ICANN roots (or alternate roots if the plug-in
additionally supports such alternate roots). But if you already know the
"xn--" version of that Amharic domain name you could use ANY existing
browser without a plug-in and it will resolve it (you won't see Amharic
characters but you will go to right web-site) as long as the relevant root
is supported . In the case of the " xn-800AAVHBF1A.com" ".com" tld is
supported by ICANN root so a regular browser will resolve this "xn" version
automatically.

       Certainly this is not my authorship, but my web-engineer stands
corrected if his FACTS are wrong!

       John:
       I would hope that, were ICANN to be willing to install a
       top-level DNAME record with the label of xn--e1aajebclaqxm4e,
       that there would be some cost-recovery for doing so, but the
       amounts would not be large.  The question of which of well over
       6000 DNAMEs would be inserted pointing to COM and how they would
       be chosen is a pure policy issue.   And, were ICANN willing to
       create a separate top-level domain for xn--e1aajebclaqxm4e, the
       registration policies for that domain would be ... well,
       whatever was proposed and accepted.

       Sophia:
               I think you have precisely nailed it.   Policy first or at
least in parallel.  Experience showed in past icann launches, that
technology was far lesser problem, policy was far more important.  In the
end the technology worked, but in practice deployment, unfortunately, it
proved an abject failure 6 years later.  II think it is because ICANN did
not follow-up with the policy to ensure after deployment worked, no one
argued etc. and it might be off  to be repeated it again.

       Sophia> What are the implications above?

       John:
       The implications clearly differ with the technology chosen.  As
       I (and others) have pointed out before, few of the existing TLD
       names actually represent words in English (or any other
       language), so the matter of translations would be difficult and
       might call for some policy decisions.  If one were trying to
       minimize policy issues, the DNAMEs or are clearly the better
       approach of those involving root changes and local aliases are a
       better approach yet.  Presumably, if new names are going to be
       placed in the root (for either DNAME or delegation records),
       some procedure will need to be devised for applying for and
       registering those names and I would not predict that it will be
       easy to devise such a procedure while still being sufficiently
       fair to all language groups to minimize the risk of people
       feeling that they are forced into the development of alternate
       roots.  If we do end up with alternate roots, your ability to
       register "mybrand" in all TLDs, or even to know whether you have
       done so, would be severely compromised.

       Sophia:
       I see the very heart of the problem here – I distaste bringing up
east vs west, because personally, I love American steak and Chinese noodles,
but it is the reality and your statement is a bit of icann/west view for my
taste.  First, what you are saying is that people will fight over which new
tlds to choose in new languages, so its perhaps better to just remain with
the existing tld names in ascii and simply translate/transliterate them, of
course you also say that the existing tlds have no literal meaning ( who is
to say that .com really means commercial , it could mean ".come here
darling" OR ".CN" MEANS "CHINA" RATHER than a short-code for all "sin"
WEB-SITES), so translating them meaningless words would in my opinion be
just as problematic.

       While surely people will fight over which new language tld will be
better (ie. No different from in English trying to argue ".biz" is better
than ".com" etc or ".xxx" is better than ".sex"), there is no technical
limitation on selecting literally any of billions of idn tlds in the hundred
of languages. There is hardly likely to be any conflict. If people in
English could not agree on whether ".biz" is better or ".com" is better,
give them both and see who succeeds.  In fact this is exactly what happened
in English in a way.    There has been long a school of thought that the
internet should have an unlimited number of top-level domain names -
millions in English and otherwise.  But there is absolutely no technical
limitation and this has been shown over and over again by many experts over
decades- Karl Auberach and many early icann board directors I understand,
squealed for this - but icann has been resistance to give control with not a
lot of justifiable reasoning I gather - it sort of defuses power as in
politics.

       I was captivatingly surprised to read the recent wall street journal
article, which I have shared with you recently that a new company called
uniroot, is selling anyone a tld they want (using sort of alternate roots) -
a few years ago, I understand there was also another company that promoted
that idea that died as well.

       Second, relative to the "If we do end up with alternate roots, your
ability to register "mybrand" in all TLDs, or even to know whether you have
done so, would be severely compromised " comment, I must strongly disagree,
eg. today if i want to buy an airline ticket i cannot go to single airline
company and buy them.  A travel agent may do the job for me.  If I want a
phone in a number of countries i can go and easily buy it wherever i want.
Your statement implies a single phone vendor worldwide, which despite your
inferences of course presumes English speaking and monopoly of money by
western companies.

       Actually even in domain names today, if I want to register my names
in different cctlds i still have to go around and visit many different
registries /registrars and buy them. Many countries do not use registrars.
This is the way the world is.

       And to the extent there is a market need for a single way to buy
many different domains the 50,000 or more resellers in the world take care
of it.   Basically the proposal you mentioned is a centrally controlled,
sort of a star trek future - where the whole world is one government
controlled by one entity.    Some may think that this view is of those who
invented/controlled the internet and it fits with US political needs as well
(a convenient excuse to control a world resource).    Others would argue the
opposite actually - by limiting all language domain registrations to de
facto,  a few global western registry/companies will ensure that they will
not have the necessary local expertise in languages/culture to actually help
the global company wishing to protect mybrand in all countries correctly. By
employing different local groups to do so (which alternate roots will
necessarily suggest) will do a better job of correctly protecting customer.

       As for resellers and registrars offering everyone's products for
one-stop shopping - today registrars are contacting many different
registries in USA and all over the world cctlds registries (with all their
odd rules - in Korea only Koreans with a soc sec number can register, in
china even today individuals cannot register only companies, in Arabic
countries - pornographic names cannot be registered, etc and we pay in all
manner of local currencies over different terms - some countries only allow
10 year terms of registration) and offering them seamlessly to customers as
it stands. Just like there are different registries supplied by a registrar,
the registers will simply supply products from alternate root registries
with their own rules and prices but all using same IDNA standard and
Technology (that's what is important).   Therefore I would not subscribe at
all to the analogy of alternate roots would severely compromising mybrand
registration .  Its like saying democracy undermines order, which would be a
statement that only a dictator would use and fool believes .

       --On Sunday, 05 February, 2006 23:23 -0800 Sophia B
       <sophiabekele@gmail.com> wrote:
       >...
       > 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.

       John:
       I am no particular friend of Verisign's or their behavior, but I
       believe the explanation above is somewhat distorted.  As I
       understand it, the vast majority of the names registered under
       the testbed have been converted to IDNA names and the relevant
       fees paid for standard registrations.  More important, despite
       my use of some of them in the examples above, no one really
       wants to type in, or look at, any of these ACE-encoded names.
       In general, if I use one of the IDNA (punycode, as above) names
       in a DNS name context any modern/contemporary browser, I will
       see the native characters associated with that name.  But
       nothing contemporary supports the "RACE" names that were used in
       the testbed.  So, unless one finds a string starting with "bg--"
       and followed by an arbitrary-looking collection of characters to
       be amusing or of mnemonic value, that testbed, however badly it
       was handled, is now irrelevant.

       Sophia:

       IDNA to reinforce my own and other readers understanding is the
Internationalized Domain Names Applications standard agreed to buy IETF a
few years back.  It sets the rules for taking multilingual domains and
converting them with the help of unicode into "ascii strings" pre-fixed by
"xn--".    Everybody has agreed almost completely to this technology
including almost all the alternate root efforts (china included) and in fact
the final standard is almost identical to the original idea proposed of all
things by an ALTERNATE ROOT company - i-dns.net <http://i-dns.net/> , when
ICANN was not focusing to fulfill the need for IDN for many years.

       Having said the above, these were my findings.   The way of
translating multilingual into ascii strings can be done in several different
ways/formats (something trivial like writing left to right or right to left
- just a format agreement like driving on left or right when there is a
choice) - all these ways are called ACE encodings (ACE means ASCII
Compatible Encoding i think).  Originally i-dns.net <http://i-dns.net/>
proposed a particular ACE known as RACE as an interim standard (which
Versign launched in its testbed/deployment) while IETF looked into agreeing
to it or selecting a different one. (Launching technology with preliminary
standard while IETF or ITU develops final standards is common practice on
the Internet - example Real Networks video streaming, JPEG or 802.1g wi-fi).
The Race encoded names were tagged "BQ--" in front of translated Amharic
string. It could have been any tag - they more or less randomly chose BQ.
After 3 years of debate (the longest ietf debate ever by a factor of 3x)
IETF after discussing dozens of ACE formats had two finalists - the original
RACE or a new version called PUNYCODE. Its really a trivial part of the
whole IDN concept but one argument says that after 3 years the committee
must have something tangible and different to show (not just a few minor
unidentifiable changes in the guts of the details only) - so they went with
punycode and IDNA was released enshrining punycode - and they essentially
drew lots and randomly came up with "XN--" as the identifying tag for
PUNYCODE (another member of ACE encodings) names. All new IDN names were
tagged XN and everybody except Versign converted existing BQ to XN within a
year. Eventually Versign did it as well.

       Note:  By the way the original tag was "BQ--" and not "BG--" as you
stated John - a very trivial detail . A computer randomly was used to
generate a two-letter tag in the case of XN - they sued closing prices of
NASDAQ stocks average etc.

       John:
       Verisign has permission to register IDNA names in COM and NET
       and has had it for several years.  As far as I know, every other
       gTLD that has asked for permission to register IDNA-style IDNs
       has gotten that permission.  These are not for testbeds, they
       are for production registrations.

       Sophia:
               I would say yes to this of course, but my research tells me
that no one uses them.  The Chinese from day one in 2000 used their
ambassadors and their ministers to protest internationally and to this day
more or less block it for use within China.  All of these are two language
hybrids ie. native language.ascii-cctld. ie. half my name for eg. in Amharic
and the other half in English.   Totally offensive and does not really help
the non-English speaker who cannot type English, even worst, in most cases
the non-English speaker has to change KEYBOARD SETTINGS from one language to
another half way through typing a single domain name.  I understand - yes
some people bought them to protect their names but the average non-English
speaker who needs IDN has almost never used them.    Probably less than 1%
of names ever bought under these are actually used or usable.   And the
total number of all ICANN approved IDN names registered today is probably
less than 500,000 - mostly in .com. - after 6 years .   And most are not
hosted and the 1% or less that is hosted are actually not used, because
ICANN was not able to make them usable by the people who need it.   Wow,
contrast that with China, who after getting serious about their alterative
root (started in 2001), about two years ago, that have over 100M people
being able to use it - only 300M truly IDN needing Internet users in the
world (note French, Latin, Germans, can use ascii for the most part
happily).   I hope this are statistics that are not was off base, if so, I
would need an issues report, to contrast that, like Marylin Cade would say.

       John:
       Now, I believe that testbed was very badly handled and that the
       way it was approved and handled reflects badly on ICANN (staff,
       Board, and the then DNSO Council) and on Verisign.  My proposal
       that we be quite aggressive in being sure that "tests" are
       actually tests and not some sort of early-start mechanism was
       developed precisely because of that experience.  We should at
       least avoid making the same mistake a second time.  More on this
       below.

       Sophia:

       I think you misunderstood here. The usual differences arise when
technical people use precise meanings of words, while others are accustomed
to speaking in looser terms without loss of communication.  I understand the
testbed was initially in RACE and then it was converted to IDNA. Your answer
seems to focus on that. The RACE/IDNA difference is not the point in my
original comments.

       By suggesting that the "long-term" solution was not addressed years
ago, what I meant was, even to date (and that is years after Versign
converted to IDNA) the IDN names that launched as a testbed in 2000 and then
subsequently in 2003/4 converted to IDNA, are hardly usable anywhere where
non-English languages matter.  For the first few years there was no
resolution either by way of plug-in distribution or other server-side
solutions, then there has been a modest rise in plug-in distribution a year
or two ago and then probably a relative decline since then.

       Basically from the point of view of a non-English internet user
outside of primarily the USA, these IDNs have been hardly usable and are not
much used - and this after many other ascii TLDs have been allowed to launch
(not as testbeds).  I understand there is one argument for this is, that
browser manufacturers are not under the direct control of ICANN etc. ie.
Microsoft or left to private hands, that it costs them a lot of money to
distribute plug-ins etc. It has also not been cost effective for these
primarily Western companies to do distribute these plug-ins.

       While these market problems are very real in the West/USA etc., they
are no consolation to the multi-lingual end-user whom ICANN in my opinion
has been less successful to date in serving. De facto ICANN is and is
certainly seen as being in charge of the "Internet" and it would seem that
if after 5+ plus years there has been very little usage or progress in the
already launched IDN usability, ICANN could address the real issue –
usability,   Even if ICANN does not control the parties,  for a
comprehensive solution, it is my understanding that ICANN did not do much
more to accelerate the process.    Local efforts in countries with local
laws seem to be overcoming these problems that ICANN has made, with only
very little progress.

       My purpose in bringing the Versign tetsbed up was for me to have
some input/comments on this dead-on-arrival" status as regards usability
that has plagued ICANN IDN launches so far    How would we at ICANN avoid
these prior usability problems before we go headlong into another launch -
DNAMES or new TLDs?   I am all for doing it but wish to ensure that we do
not repeat the past.   One would imagine that this needs to be sorted out
before we experiment and launch. It is in this way of thinking that I
suggest "policy usage" issues first.  We had the technical launch before -
ie. IDN.ascii - and it worked technically but why is nobody able to use it
much in practice (yes - anyone can go to the link and download - that's not
an answer to the real problem).   The technology was successful, but the
deployment has hardly been successful, while the need is clearly there why
and how are we going to do better this time round?

       Again, I am no DNS expert and am appreciating all the school-kid
style education on the technical details of IDN but correct me if I am wrong
- the early RACE encoded IDN names carried a "BQ--" designator rather than a
"BG--" designator as you suggest above.  I would assume in any language or
script those are different?

       Further research on browser technology:   Native browsers until a
year ago could not handle IDN for two reasons.  First reason- they had to
convert multilingual to Punycode "xn--" ascii-gobbledygook strings using
IDNA standard. Second even if translated the domain name has to be sent to a
root that understands it - either ICANN or alternate root. In the case of
ICANN root, browser simply sends it to your ISP and they are set up to d
fault send it to ICANN root. If your ISP is not (and unless someone went to
every ISP and made them include alternate root information (a 2 minute
procedure) as the Chinese govt. ordered to all isps in china), then the
browser itself needs to recognize the fact that the name is an IDN and send
it to the correct alternate root (browser needs address of alternate root if
the ISP does not have it).

       It is my understanding that ICANN has now or NEVER in 6 years told
any ISP to add an alternate root location for obvious reasons. So unless you
had billions to pay ISPs or you were China govt hard to get the world's
10,000 ISPs to do the 2 minute programming that is needed. So typical ISPs
only point to ICANN root. So until a year ago no browser manufacturer did
either.  ( I think I brought this point at the DC GNSO meeting)

       As a result, plug-ins were the rule - the original plug-in was
developed by i-dns and Versign has licensed and re-branded for use and so
have virtually everyone else in the world who launched IDN, including
Chinese, Japanese, Arabs whether icann-sanctioned IDN or alternate root ones
- copied or licensed the i-dns.net <http://i-dns.net/>  one. In the case of
ICANN TLDs. the 2-language hybrid IDNS that ICANN has launched to date - ie.
IDN.com variety - the plug-in is not required to handle the alternate root
function - because you use the ICANN default root which your ISP knows
anyway. So this single-function plug-in was distributed primarily by
Verisign for their large testbed - and since. (Aflilias and Neulevel and
JPNIC launched IDNs and sold some names but did not   bother to develop
their own plug-in for distribution and simply use their competitor's
Versisgn's free plug-in to do so – that is that for innovation  - they make
money and would like to have IDN but are not spending money to make their
own product - to versign's credit, it actually is doing that - the other's
seem to be just making money on ICANN contracts - except of Versign they
pretty much do not have an R and D group, I understand of any kind,  let
alone IDN.  But it is interesting they all want DNAMEs though).

       It is believed that ICANN also did not do much effort to develop or
promote any plug-in, with anyone. Left to its own devices and with no
support, unfortunately, I understand the plug-in deployment failed over 6
years - less than 100,000 plug-ins distributed in first 4 years and since
maybe 4 million - almost all by Versisgn.   And most of the 4 million where
it is really not needed in USA and Scandinavia - no real need for IDN.
ICANN could have allowed Versign and the other IDN ICANN registries to talk
to local ISPs to alter their software even further - so that the translation
step to xn-- could also be done at ISP server end - so need for plug-ins at
all - a trivial thing that was originally proposed by IDN inventors - but
this was rejected for what many think is no good reason by IETF and ICANN
(ie. many think it was an ICANN vendetta against Verisign).   So yes ICANN
deployed but no one could use it.

       The alternate root efforts have in some cases patched the ISP side
and like in China can do without plug-in at all. ( I think this was what I
was attempting to say at the DC meeting, but I was told ISPs do not need any
patches, yes they do not   if they adher to ICANN root).   Other alternate
root efforts use plug-ins (all derived from the early i-dns.net
<http://i-dns.net/ >  one) that both translate to xn-- and also point
directly to alternate roots. But most efforts, like the Chinese, mix both
server side patch and plug-ins to achieve maximum penetration. For later IDN
email addreses, plug-ins are required - ISP patch is not enough for
technical reasons.  For example once they got serious, in 2 years, the
Chinese have pushed out over 50 million plugins and patched enough ISPs by
govt order to account for > 90% of China's 130M end-users. One alternate
root company has thru ISP patch and plug-in distribution allowed 60% of
Koreas's 36M internet population to access full Korean domains in about 2
years. Meanwhile even with Netscape being disbanded and handed over to
Mozilla non-profit and they having agreed to support at least the IDN xn--
translation function innately last year and therefore ICANN IDN not
requiring a plug-in if you use Netscape, is why I think the ICANN IDN
experiment after 6 years seem to have resulted in utter tragedy in
comparison, as far as usability.

       Sophia> 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.

       John:
       At one level, I share your concern.   I have no idea how the
       policy and approval procedures will work out when one starts
       talking about even hundreds of names that are somehow associated
       with each TLD or some set of TLDs.  I have repeatedly sought
       for, defined, and proposed mechanisms for dealing with the need
       for internationalization at the TLD level as a client-translation
problem,
       rather that trying to force those decisions to be global policy
matters.

       Sophia:
       Of course the natural attraction of DNAMEs is that each incumbent
registry selects its own translation (without being sensitive to the local
culture who have yet to be represented at ICANN .   It's implication is
those who already know best and who can profit the most can do it for you).
In every language (even ones they have never heard of or have staff to
handle) the whole problem is avoided.  I think we should be reminded here
that the internet is A GLOBAL POLICY MEDIUM. Its a GLOBAL COMMUNICATION
SYSTEM and interestingly, for the first time in history, people are
attempting to make the FIRST BOTTOM-UP GLOBALLY DESIGNED COMMUNICATIONS
NETWORK.  Phone companies are patchwork of national phone systems in
comparison.

       If Multilingual communication between people that will eventually
handle virtually every form of communication (post office is dead, VOIP is
coming) in a service-oriented (ie. data movement IS the ECONOMY - not goods)
handle increasingly as much as 90% of commercial activity in a GLOBALised,
OUT-sourced world and the addressing of one's IDENTITY and NAME in this
end-all communication/business platform is what the Internet domain name
system is about, SHOULD NOT THIS BE A GLOBAL POLICY PROBLEM.

       The whole point is the Internet is a global policy problem - and the
United Nations understands it, but most scientist or technologist so not.
I shall hope not, but I think ICANN from what I gather, seem to be seen as a
narrow minded group of scientist /technologist, who have historically
controlled the Internet since invention ( despite repeated elections of
global board of directors who are either paralyzed or nod in silence) may
find it convenient psychologically to shut the noisy world out of their
IVORY TOWER - trivialize the policy issues, turn a global issue to a private
local caucus group issue, the way they had the Internet before the
world-at-large discovered it.   I also learned there are those who think
that the US govt either thru incompetence or as a direct intended form of
manipulation of existing situation, or a mixture, exploits the
scientist/engineers' views to keep it from becoming a global issue and
rather a single nations' national issue for all the obvious political
superpower reasons.  Interesting!
       At this point, my view would be that I may have to wear a
bullet-proof vest and arrive with a contingency of US Navy Seals Team for
protection at the ICANN Conferences!!. Or maybe I should just wire the
Enterprise and ask Scotty to be ready to "beam me up" in  in ase of
emergency!
        Navy SEALs <http://www.seal.navy.mil/seal/images/splash11.jpg>
       Others again are in the view that if ICANN does not want to deal
with it as a global problem, then we let it turn into a national sovereignty
problem, with alternate roots that countries decide. The thought is that
ICANN does not want it not to be global but chose to give it to incumbents -
happens to be all the right people in the western companies, US govt, their
friends etc. - all in their comfort zone - people who having signed onto
ICANN for their bread-butter contracts can be depended upon to continue
courting them .  As such, a "not a global policy issue"  can not pass or
should not be commented as even reasonable to an ICANN BOARD - and Board
members need to wake up to this.   Ok, how does ICANN respond to this?

       Note:  My own observation for few months now, and having researched
and talked with people interested in IDNs,   I am inclined to deduce there a
number of reasons why the IDN issues have not been pursued competently as
well as why GNSO was silent:

       1.                      Lack of in-dept technical knowledge and
information to enable policy making by GNSO.   I think the technologist have
dominated the conversation.   One question like "do you know the difference
between BQ and BG" and everyone is "quite" or goes to "sleep", which could
include me in the future.
       2.                      Western companies (who are ONLY resellers
and who have never developed any new technology i.e not been innovative per
se - even AT&T continues to develop technology while selling phone service
calls),  may not have interest in IDN unless there is a profit justification
viz a guaranteed profit as a monopoly with no extra work (easy way out is
DNAMES).
       3.                      Non-West companies/people say little or
nothing because they have already bought in to the "ICANN rules the world"
concept.
       4.                       Fair-minded western types may have been
overwhelmed and "retired" at first opportunity
       5.                         Meanwhile the inventors/founders of the
Internet speak with GREAT KNOWLEDGE and in a complicated technical terms and
with GREAT ARROGANCE at times (some of our emails are evidences to that), it
silences everyone who after-all are not paid for this volunteer board.
       6.                         As a result, the board members from
non-western companies already assisting ICANN (like myself) often have to
make a living in a ICANN-independent manner - so the ones who are the least
biased tend to be the ones with the least time. (We have to hire research
assistant at our expense).
       7.                         The Board member from X country with bad
English or the guy from Timbuktu who just wants to serve the two years so
that he/she can leverage that to become Minister of IT back home may be
unmotivated and to nothing
       8.                        As such, the silence on GNSO BOARD is only
matched by the silence on the main Board on IDN and other issues.  This
level of silence, have resulted in the external threats to become REAL -
china etc.  This silence I think also led to a few, dominating to prevent
ideas they often arbitrarily did not like about something they never wanted
to do (allow multilingual domains) and then after preventing the matter, did
not helping with the actual carrying out of successfully, that which was
agreed to by default.

               John:
       While "WWIII" is probably hyperbole, I believe the most
       efficient way to get us to alternate roots and a badly
       fragmented Internet would be to respond to the perceived
       requirements for increased internationalization with a "just say
       no" attitude or one that can be interpreted as people from
       industrialized countries trying to keep populations from
       less-developed areas from using the Internet effectively.

       On the other hand, unless you succeed in persuading everyone in
       the world to adopt a writing system that uses Roman characters,
       the argument for IDNs, and IDNs at the top level (at least in
       appearance to the user) will not disappear.  If we are going to
       do such things by entering names in the root, then it is useful
       to know what will work, what will not, and, to the extent to
       which we can make estimates, what the operational impact will
       be.  I believe we should all be quite concerned about making
       root changes without at least some of that experience and
       knowledge.  If people want to run experiments, then those
       experiments should be both controlled and informative.  The
       choice of 20 was based on an estimate of the minimum number
       needed to give us some useful information.

       Sophia:
       I I see no issue with running experiments, but once again, we
launched technology that worked before. The issue is not technology one
would think. It is POLICY.   Should we not settle on some idea of how
policy-wise ICANN should delegate languages (if DNAMES) and TLDs (if new
ones) or at least have some parallel debate.   I understand the Katoh
committees studied it in the past and had recommendations, but I have not
heard any actual discussions on what the committee thought then about
Policy.    It appears to me from your comments that the Katoh-committee
(spent far more time than we have so far I would have thought this time
around) from a policy perspective (ie. bickering) had only a few
recommendations to make - and one quite clearly recommended that new TLDs
should be issued for IDN TLDs and that these TLDs should not be handed in a
grandfathered way to existing gTLDs OR ccTLDs ... correct me if I am wrong.

       That it should be brandname new "bids" by all-comers. If that
reading is right, one would imagine while the technical merits of DNAMES
were not discussed (or for that matter DNAMEs as an option was not brought
up at all) the prevailing assumption that DNAMES will be a way of awarding
existing ccTLDs and gTLDs equivalent IDN TLDs in effect would be counter to
what the Katoh-committee was presumably explicitly trying to avoid -
incumbents getting IDN TLD equivalents.  (I understand in principle that new
IDN TLDs can be deployed and DNAMES made only operational in that new IDN
TLD as you point out later but I think most people in these discussions
presume DNAMES implies incumbents eventually getting their IDN TLD
equivalents in many languages - certainly in the Versign DNAME proposal that
seems to have jump-started the current fascination with DNAMES that is their
assumption/hope).

       Again I am puzzled that after having gone to so much trouble and
time we are now ignoring even a modest discussion of the original Katoh
committee recommendations . They suggested various policies - long before
any experiment. Now we seem to be going ahead without any policy discussion
and worse ignoring the policy recommendations made earlier, straight to
experiments. I must say I am puzzled.

       Perhaps the current IDN committee should get us all upto speed on
the Katoh-committee recommendations and why they suggested what they did and
why we are proceeding along the lines of what we are doing - reasons for and
against. We can always make different decisions from the Katoh-committee
recommendations.

       John:
       > 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'.

       I think that some of us who have been working on these issues
       for many years are at least as sensitive to these issues... and
       to finding ways to make things work effectively with a variety
       of scripts and languages, as you are.   Some of us have even
       spent a good deal of time working with people in the "non-US/
       non-West" trying to accomplish that while also trying to
       preserve the integrity of the DNS as a global Internet-object
       referencing resource.  The problems are complex.  The DNS is not
       an ideal solution to many of them for reasons that have little
       to do with English or even Roman characters.  The nature of
       those problems and the range of alternatives have been rather
       extensively explored outside the ICANN and Roman-script
       contexts, especially in East and Southeast Asia.  At the same
       time, slogans may not be helpful ( e.g., the only practical way
       to realize "think global, act local" with regard to IDNs is to
       get internationalization issues entirely out of the DNS -- an
       IDN in the DNS is inherently global because the DNS is
       inherently global) and wishing the DNS, or the Internet more
       generally, worked in a way significantly different than it does
       won't make it so... any more than lamenting how much easier
       navigation would be if only the earth were flat is helpful to
       either navigation or earth-flattening.

       Sophia:

       It seems rather puzzling to me that, after 6 years or more of
activity, the best that ICANN has done to date is to being able to deliver
from "those of that have been sensitive to the needs of the non-US/non-West"
is a two-language/script domain name. ie. the IDN.ascii-tld, technical
people can make all the distinction they want but in general use you will
never see any significant change I fear.  eg. is I would not like the US
passport agency to finally recognize that there are many Arab US citizens
and that their passport should contain their personal name in the original
Arabic and then proceed to write in their passport "Ismael" in Arabic and
then "Mohammed" in English.

       The whole point is to allow non-native English speakers to skip
English in domain addressing . Making them type half in English is not
really a solution?, becomes bad-mannered, if we were not all brainwashed to
think that "English" is the "end-all".   Worse, whether you need a plug-in
or not, or if ISP or Microsoft patches it, these two-language domains will
always require end-user to switch KEYBOARD from one language to another
while typing a single domain name in a browser (in Hebrew and in Arabic also
switch direction of typing).  I gather this has been a huge problem , hardly
anyone bothers to mention - because no one is really using these things
after 6 years . But if you put IDN TLDs - alternate roots or ICANN root,
with or without plug-in, this problem goes away - you do not need to switch
keyboard settings halfway.

       I find it hard to believe that this two-language oddity is what the
non-English speaking people have wanted out of their internationalized
Internet . It would seem anyone with any sensitivity to non-English
languages using scripts far divergent from roman-like would want single
language/script domains - to push the point home, I doubt there is much of a
market for " arabic.hebrew" names.   What I mean is, "Arabic" on left and
"Hebrew" on right - two-language . Hebrew TLD and Arabic company domain
name. This is the sort of thing I believe what ICANN has been launching for
the past years - two languages, which has been criticized with the IDN
community and has not found much of a user.

       The more likely scenario would be that perhaps those who were
"sensitive to the needs of the non-West" did not understand . The real
reason might just have been technical and political convenience and
incumbent-market economic convenience - none of it necessarily helpful to
those who really need the internationalization.   Technical, because less
has to be changed (similar logic as in DNAMES for now I presume). Political,
because there was no need to introduce new TLDs way back at a time when
ICANN had other on-going battles to defend its authority and
incumbent-market economics - it benefited the major existing registries -
the early ones being commercial gTLDs or if ccTLDs, then privatized
profit-making ones.

       I bring this up not to apportion blame (even you conceded the
initial launches were terrible and we don't need anyone to tell us that the
whole IDN roll-out has been a practical failure in the general public's
minds) but rather to counter your matter-of-fact assumed suggestion that
"everything is in good hands and we have been sensitive to non-US/non-West
needs". It is said that those who do not consider the past maybe doomed to
repeat it. My real worry is that once again we may be going down a path of
technical expediency ( eg. DNAMES) all the while insisting that we are
"sensitive".

       Given the past, in my opinion, to be truly "sensitive" one needs to
consider the policy side of what we are about to before we embark headlong
into another "better testbed" directed down a channel guided by technical
expediency (possibly DNAMES) and by the identical commercial forces as
before (Verisign initiated proposal). And add to that no one seems to even
bothering to recall that a prior Katoh-led Committee spent substantial
effort coming up with guidelines for the future may have specifically
recommended against the path that things currently seem to be pointing -
incumbent awarded mappings ie. DNAMES.   If we have the same organization,
possibly some of the same sensitive people, similar technical expediency
directed technical solutions, same arguments, same commercial proposers – I
doubt if we do we expect a different outcome?

       Finally, I truly believe we need policy discussions first and should
at least consider for discussion the Katoh-committee recommendations as a
first step.

       Sophia> 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
<http://re-point.com/>
       > to every language equivalent - no new TLDs etc.

       John:
       Actually, I think you misunderstand both the situation and the
       history.  First, DNAMEs are, in Internet time, a relatively old
       proposal and protocol specification.  I didn't invent them and
       neither did Verisign.  Second, there was a proposal from the
       original ICANN IDN committee that no IDN TLDs be permitted in
       the root except on a separate application for new TLDs process.
       For an number of reasons --almost all of them consequences of
       how the DNS actually works and what is and is not possible as a
       result-- I still believe that was a wise recommendation,
       independent of anything China, Verisign, or others might "want"
       to do.   Some of those who are still on the GNSO Council will
       probably remember that, because of issues with the number of
       languages in the world, I recommended that we try to sort out
       the use of IDNs at the second level and below in relevant ccTLDs
       before permitting them to be used at all... and recommended that
       several years before China made essentially the same suggestion
       (of course, by the time they made that suggestion, it was
       already too late since several gTLDs were doing production IDN
       registrations).

       Now, there has been a good deal of pressure from a number of
       directions to create aliases for country names in national
       languages.   That pressure has actually been much more intense,
       with more threats, from other directions than from China.  If an
       alias is what is really wanted and that alias must, for
       technical or political reasons, be in the root, then DNAMEs are
       the right way to do so.  Other solutions are simply not aliases,
       they are separate domain names.  To me, for separate domain
       names, the original IDN Committee/Katoh-san recommendation
       should still apply.    As with IDNs below the top level and the
       "what languages" question, I understand the idea of an alias for
       a ccTLD in the relevant country's national language(s) much
       better than I understand what to do about gTLDs.   Indeed, if I
       could make recommendations for the GNSO, I would seriously
       consider a recommendation that, at least for the next several
       years, the top-level IDN issue is, except for possible
       completely new applications domains with IDN-style names,
       entirely a ccTLD problem and that the gTLDs should not
       participate in any way in the evaluation of what is possible and
       reasonable other than continuing to register second-level IDNs
       under existing rules.

       Sophia:
       I am aware that DNAMES has existed for a long time as a technical
part of the DNS structure. You and Patrick pointed it out in your recent
IETF document that was circulated. But you also point out DNAMEs was never
really invented with IDN in mind and in fact there is some hesitancy for
"borrowing" it for this purpose of IDN. From my crude understanding the
reasoning appears to be it would be ideal not to use something for which it
was not really intended.

       In any case in my understanding the DNAMEs approach is being
championed right now - it was not the case I believe in the previous 6 years
of ICANN IDN history. The Katon-committee didn't consider it after 3 years
of IDN history at ICANN. If this thing has been around for as long as the
Internet, then why all of a sudden this proposal is being championed -
whatever the true reasons, it certainly has the suggestions of technical
expediency in the face of potential external threats/pressure.

       Well, its great that you bring up the Katoh-committee
recommendations that you too seem to agree with , and at some level these
are against the grain of the direction in which a DNAMES like deployment
would head - awarding incumbent existing gTLD registries equivalents. Saying
that DNAMEs is just a technology and how it need not be given to existing
registries in principle is true technically. But the real issue is that's
where it is likely to head and that's why the POLICY needs to be discussed
first. Why are we not even discussing them after having invested so much
time and effort on their recommendation?

       I understand that the Versign testbed was done badly and everybody
acknowledges that . Now when China came up with a solution they liked, it
was already too late because we at ICANN had gone ahead and gone beyond "bad
testbed' to actual production registrations under a few major commercial
registries ( gTLDs and ccTLDs I guess) and it was too late to go back.
Perhaps it is no little wonder that the same China and others are now
forging their own path ahead.  So two mistakes - not just one - presumably
all driven by the stronger commercial registries wanting to increase sales
in their existing ascii TLDs by way of promoting somewhat insulting
two-language/script hybrid domain names.

       If there is pressure from other sources - other than China to move -
would it not be useful or proper for those of us who believe policy issues
are equally or more important than technical testing of fairly
well-established technology (perhaps as old as the Internet you suggested
for DNAMES) to know what these "pressures" are if we as members of various
ICANN boards have to endorse the eventual policy chosen. No matter what the
spin from wherever, it is abundantly clear that the current IDN activity
within ICANN after 2 or 3 year relative hiatus, is happening because of
considerable external pressure .  I am not sure I am speaking for all the
GNSO members, but for my part I generally viewed the pressure from China as
the biggest one while I have heard rumors of others and unhappiness from
various other quarters . If as you say the pressure from China is not the
main one and there are multiple others, it would appear that we would need
to discuss this pronto!

       Could someone please share this with us? So that our job is NOT to
simply endorse everything.

       Incidentally I would not be surprised if many of our board members
learnt of the China deployed/commercial activity while reading a recent Wall
Street Journal article. I have since learnt reliably that this activity was
launched initially in a small way with full backing by their Ministry
(published statements by Ministers) more than 4 years ago, and starting
about 18 months ago it has been extensively deployed all over China.  A
large fraction of the 130M+ Chinese Internet population is already
enabled-to use it and many tens of registrars have actually been selling
these domains (which for all external purposes look like real IDN TLDs as
described in the Wall Street Journal article) for well over a year and many
tens of thousands of names registered and in use. A quick visit to the CNNIC
web-site confirms all this.

       It would be nice to know of these things earlier and not from the
likes of the Wall Street journal.

       Sophia> 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.

       John:
       Again, please understand enough about how the DNS works, and how
       name resolution and applications on the Internet work more
       generally, to be able to understand what is said above.  The
       Chinese have not already "launched" anything along the lines of
       what I suggested.  That proposal is not "technical-oriented
       only" and does consider the business issues (even if the
       business and cultural issues it considers critical might not be
       the same ones you would choose).  That proposal was actually
       almost exclusively focused on political, policy, and cultural
       issues -- many of the technical folks, who prefer a less complex
       world, actually don't like it.  And that proposal is not, in any
       way, related to DNAMEs -- it is a third alternative.

       As to whether "issuing DNAME" is "equally reckless" as "using
       new TLDs in IDN" (whatever that means), I would, again,
       encourage you to understand what is being proposed and what its
       technical implications are, if only because doing so is
       prerequisite to talking intelligently about the business issues
       (or even most of the political and cultural ones).  The "new
       domain" issues are simply a superset (a rather large superset)
       of those associated with DNAMEs.  DNAMEs supply aliases but, as
       I pointed out long before the GNSO became actively concerned
       with this, one still needs to decide who gets which names and
       what they point to.  New domains raise the much more complex
       issues of allocations and operation, and domain-specific
       policies as well as those of name selection and assignment,
       issues that are largely invisible from the DNAME case.

       Could one adopt a DNAME model and reserve names for later
       "independent TLD" allocation?  Of course.  Could one restrict
       the DNAMEs that would be associated with gTLDs to some limited
       set, or even to zero if that were felt to be wise?  Of course.
       There is nothing that is "all languages in the world or nothing"
       about any of the proposals I have heard seriously raised.

       Sophia> *Ok, pls correct me if I am wrong when I am trying to speak
       > DNAME implementation approach:*  eg. CEO of mybrand.com
<http://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.

       John:
       No, they do not.  And the fact that they do not is actually one
       of the attractions of the DNAME approach (except to the
       registrars and registries who are anxious to mount "there is now
       another new domain in which you need to register to protect your
       brand... please send money" campaigns.  _That_ approach requires
       separate domains).

       Sophia>  Then these companies, like Versign, can go and get
       > everyone of their.com <http://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.*

       John:
       No, you are not.  Please read the comments above and, more
       important, please make an effort to understand how the DNS works
       in general and how DNAMEs work in particular.

        Sophia> 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.

       John:
       No, it is not.

       Sophia> 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.

       John:
       No, China has done something else, and only relatively recently.
       Once you understand, throughly, how the DNS works and, in
       particular, the difference between the actions of a caching
       forwarder and a different TLD, I'll be happy to try to explain
       just what they are doing, and why, to you.
       ...
       Sophia> Therefore, as Avil suggested, I propose the alternatives and
       > solution should be explored by a joint consultation with
       > relevant IDN circles and the Council.

       John:
       Sure.  As long as the capabilities and operations of the DNS are
       sufficiently well understood, and at a policy level, the range
       and scope of potential ICANN authority is reasonably well
       understood, that discussions of policies that imply flat earths
       and more convenient values of PI are avoided.  Otherwise, while
       the discussions would certainly be interesting, the GNSO will
       waste its time and the world will ignore ICANN and move forward
       on its own path.

       Sophia> 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!

       John:
       First, the proposal that comes closest to the type of solution
       you seem to propose above is one that you have rejected out of
       hand.  Second, scripts and not the same as languages and people
       don't speak scripts: not understanding the difference can only

       ;p0increase your confusion.  Third, as long as the DNS is to remain
       a global resource, a solution that involves letting those who
       speak a particular language to "take care of it" and go in their
       own direction is essentially impossible.  Or, to put it
       differently, it is possible in only two ways: with client-level
       aliasing (which you have rejected) and with different DNS roots
       for each language group.   The latter is inconsistent with both
       unambiguous global references on a global Internet and, by the
       way, with your having any possible hope of protecting your
       business name or trademark globally... except by legal action in
       each country in which a similar name might be used.

       regards,
          john