Re: [council] Re: Regarding issues report on IDNs (fwd)

["Sophia B" <sophiabekele@xxxxxxxxx>]

Thanks Cary, I got John's reply already.

John, thanks for the detail reply.  Please allow me few days as well to
decipher your comments and get back to you.   BTW, I  hope I do not come
across as hot headed on this issue viz you comment 'things calm down'.   I
value the dialog we are all having and think it is timely.

Being new to ICANN and IDN, I certainly may need to dig deep on both,
however, my view would always *bottom line on the risks/exposure to the
users of Internet, the constituencies* in this case, vs the technology in
itself.

As a software engineer by trade and working in the technology field for over
a decade, I assure you and have finally come to realize that *technology is
here to serve and not to master.*   But who knows, given the chaos theory,
there may be two sides of the flat earth society.  We will have to wait and
see.

I again thank your time.  I will get back to you ASAP.

Regards,
Sophia


On 15/02/06, Cary Karp <ck@nic.museum> wrote:
>
> ---------- Forwarded message ----------
> Date: Wed, 15 Feb 2006 14:33:07 -0500
> From: John C Klensin <klensin@xxxxxxx>
> To: Sophia B <sophiabekele@xxxxxxxxx>
> Cc: Patrik Fältström <paf@xxxxxxxxx>, Marilyn Cade <
> marilynscade@xxxxxxxxxxx>,
>     Cary Karp <ck@nic.museum>, Tina Dam <dam@xxxxxxxxx>,
>     GNSO Council <council@xxxxxxxxxxxxxx>
> Subject: Re: [council] Re: Regarding issues report on IDNs
>
> 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.
>
> 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@xxxxxxxxx> 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.
>
> 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:
> >
> > 1- if 'mybrand' is to be protected  i.e trademark in every
> > country...it is a matter of purchasing all the 'mybrand'
> > TDLs...
>
> 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 and
>     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.
>
> > 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.
>
> 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",
> "meinefabrikzeichen.com", and "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" 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.
>
> > 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?
>
> 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
> and
>    mybrand.xn--e1aajebclaqxm4e
>
> they are the same set of record entries.  By contrast, whether
> or not "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.
>
> 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.
>
> > What are the implications above?
>
> 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.
>
>
>
> --On Sunday, 05 February, 2006 23:23 -0800 Sophia B
> <sophiabekele@xxxxxxxxx> 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.
>
> 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.
>
> 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.
>
> 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.
>
> > 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.
>
> 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.
>
> 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.
>
> > 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.
>
> > 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.
>
> 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.
>
> > 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.
>
> 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.
>
> >...
> > *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.
>
> 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).
>
> >  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.*
>
> 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.
>
> > 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.
>
> No, it is not.
>
> > 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.
>
> 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.
>
> >...
> > Therefore, as Avil suggested, I propose the alternatives and
> > solution should be explored by a joint consultation with
> > relevant IDN circles and the Council.
>
> 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.
>
> > 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!
>
> 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
> increase 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
>
>


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