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

[Sophia B <sophiabekele@xxxxxxxxx>]

Greetings John,

You have just revealed the extent of the complexity below, and perhaps set
the stage for the discussions, I believe.  Thank you for your time.

I like your ...analogy that  IDNs will not solve... or cure cancer.  That
was humerus.  In any case, I read your analysis with interest and believe
ICANN/GNSO would benefit and draw a lesson from many of the points you made;
I certainly did, specifically from these main comments below:  I am
continuing my dialog with you as appropriate ...

   - I also believe that effort should have f*ocused on the establishment
   of "best practices" models, not mandates and requirements*, from the
   very beginning (and independent of where and how those models are approved
   and published) and that ICANN's PDP process is inappropriate for trying to
   draw that work together. ( I see that...)
   - The ICANN PDP approach, with its model of one SO developing a
   proposal and then throwing it over the wall for review by others is, in my
   opinion, very poorly suited for developing good policies, or even good
   recommendations, in an environment that is this complex. We also *run
   the risk that poor policies or poor guidelines could effectively make IDNs
   almost useless* --or too dangerous to use-- in actual practice.  (this
   is where we have to evaluate the best approach, and it seems that we are
   perhaps applying a single standard for all... we have to think more in
   dept..uhmm)
   - We know from the original IDN testbed activities that it is easier
   to say "testbed" than it is to say *" wait until we figure this
out".*Whether that is the right answer or not typically depends on
what a testbed
   is intended to accomplish. If the idea is to give some registrants,
   registrars, or registries an advantage or if the testbed is designed in a
   way that has that effect even if it was not intended, then testbeds are
   generally a poor idea (as I think we learned from the original IDN testbed
   some years ago). They are, ultimately, nothing more than an attempt to turn
   such principles as *"make sure it is really a test, not a head-start
   or commitment to a particular strategy" and "be sure that you understand
   what you are trying to learn and how you intended to learn it "* into
   an outline of a testing procedure. ( my point, exactly John, I could
   not agree with you more on this.  This was why I raised my question during
   the meeting, although I could not articulate it as well as you. The testbeds
   seem like bet and keep strategy..in light of this and in restating what I
   asked, ..please see below) ........
   - I believe that, if we are going to do tests, we need to use them to
   examine each of the alternatives and its implications so that we can advise
   relevant parties as to what to do or not do and can advise ICANN on
   priorities and actions (is there a big challenge to another 'go-ahead'
   strategy other than testbeds?,otherwise, I agree with your point.)

If we play devil's advocate, and say there is no real technical issue with
the 'testbeds'that prevents us from going directly to the policy issue,
then, some questions that I think I want to ask, which seem to be *brought
to my attention as a concern * would be the following:

   1. Why should we do the testbed? What are the EXACT technical
   objectives of the testbed? What do you expect to achieve from the technical
   aspect? Do we have a detailed proposal and framework to work from, like  in
   any other experiment?
   2. What  do we think is going to work? Where do  we expect is it going
   to fail (from a technical point of view – like overload, resolution, etc."
   –  If we don't think anything is going to fail then its really and
   implementation and not a testbed issue?
   3. Moreover –from the DNAME perspective, there seem to be an issue
   with going for the DNAME solution, which is not recommended (not a real
   Internationalized domain name, but kind of another name to an English name.
   You can't do email on a DNAME).  In the IDN workshop at Vancouver Vint Serf
   said explicitly that DNAME is a bad solution. so "Why do they want to go
   that way?
   4. Finally, *if there is a decision to really go for a testbed before
   resolving the policy issues,* are we considering the following few
   principals?
    - The testbed must be done for a virtual TLD –- like ".xyz" - a TLD
      with no meaning in the language it is done – so it should be something
      equivalent to ".xyz" in Chinese. This will prevent from this testbed to
      become an implementation.
      - ICANN should decide on a technical group, with different
      representatives (like the PAC) to run the tesbed, and do in the
facilities
      of an objective party – like a university, etc. in any case it
must not be
      done by an existing gTLD registry.
      - BEFORE deciding and running a testbed – ICANN must have an
      open discussion about conducting it (like in the next ICANN meeting).

I hope I am going towards the right direction in my understanding of
matters.  Your guidance is always appreciated.

Kind regards,

Sophie

On 27/01/06, John C Klensin <klensin@xxxxxxx> wrote:
> Sophia,
>
> Thanks for the clarification and the kind words.  A few comments
> below...
>
> --On Thursday, 26 January, 2006 17:08 -0800 Sophia B
> <sophiabekele@xxxxxxxxx> wrote:
>
> >...
> > was specific to the 'test beds' as you can see,and comes
> > directly from the question I asked you during our Jan 17
> > meeting, on the 'test beds' while discussing the IETF Draft
> > doc on the IDN issues.
> >
> > Your response to me* interalia,* you did *not recommend
> > personally the test beds, was not personally involved in the
> > development of the guidelines except peripherally etc...*   I
> > suppose that threw me off and I was trying to confirm your
> > involvement from this specific subject and not necessarily
> > your involvement within the  'internationalization'  issues,
> > to which again, we are grateful for your input.
> >
> > I hope that shades some light of where I was coming from, and
> > provide clarification to my question.
>
> Yes, thank you.
>
> Your question actually opens up the entirety of my complex
> relationship with IDNs.   That is hard to summarize in a note of
> reasonable length, but let me try to do so.  References that
> expand on some of these issues are cited in the IAB draft (more
> in version 02 than in version 01; I now hope to have version 02
> posted on Monday).   I have always believed that IDNs are
> important and useful.  At the same time, simply going from the
> use of around 63 characters to several tens of thousands
> increases complexity on many dimensions.  Those dimensions are
> not just technical ones.  Indeed, for IDNs, implementation of
> the protocols to make them work is the easiest of the various
> issues.   If one is going to have IDNs, one must accept,
> understand, and deal with those complexities or there is danger
> of reducing the use of the DNS as an effective tool.  Unless one
> likes keeping track of and typing IP addresses --very long IP
> addresses and many of them as we move to IPv6-- we have no
> alternative to the job the DNS must do, so I don't consider
> reducing DNS effectiveness to be an option.
>
> More important, there are a series of problems that IDNs cannot
> solve.  It is important to know the difference between those and
> the ones for which IDNs are really useful and to make business,
> policy, and technical decisions accordingly.   IDNs will not
> solve Internet deployment problems, connect countries that are
> not now connected, or cure cancer.  They may contribute to the
> motivation to do those things, but our expectations should
> remain closely tied to reality, not wild claims and desires.
> The most common example of an unsolved problem is the "users
> should be able to work entirely in their own script" statement
> of  the IDN requirement.   The difficulty is that, in general,
> users don't use domain names.  Instead, they use URIs, email
> addresses, and other types of references.  That is important
> because, in something like
>
>
>
http://www.example.com/search?q=abc+def&ie=utf-8&rls=def.ghi:en-US:official
>
> going to IDNs and substituting an internationalized version of
> the URL (an "IRI"), we can get the domain name (but not the "."
> characters) into a local script and we can change the "abc" abd
> "def", into local scripts too.  By changing the server, we might
> be able to convert the keywords ("search", "q", "ie" and perhaps
> "utf-8" or "en-US" into the local script.  But we are stuck with
> "http://";, "/", and "?" and "&" although possibly not with "=",
> "+", and ":".   Getting rid of those things --getting them into
> the local script or otherwise fixing it so the end user doesn't
> see them-- requires an entirely different approach than IDNs and
> IRIs.  And, interestingly, as soon as on adopts one of those
> approaches, IDNs, for those contexts, may recede in importance.
>
> That situation takes us back to the guideline and testbed
> questions.  I don't intend to cast blame here --it would
> accomplish little and the reasons why things happened or didn't
> happen are complex -- but I believe that a serious effort to
> revise the guidelines should have been initiated very shortly
> after problems with version 1.0 were noticed, i.e., right after
> the Montreal meeting.  I also believe that effort should have
> focused on the establishment of "best practices" models, not
> mandates and requirements, from the very beginning (and
> independent of where and how those models are approved and
> published) and that ICANN's PDP process is inappropriate for
> trying to draw that work together.  Each part of that is
> important: because of the complexities of the general IDN
> situation, solutions, rules, or guidelines that are devised by
> and for the gTLDs without active consideration of the needs of
> the ccTLDs are ultimately going to fail, probably by causing
> problems for the end user.  Similarly, even if the ccTLDs and
> gTLDs were to work together, we would run significant risk of
> problems with implementations or subtle technical interactions
> for end users or with any number of international cultural or
> linguistic authorities.  The ICANN PDP approach, with its model
> of one SO developing a proposal and then throwing it over the
> wall for review by others is, in my opinion, very poorly suited
> for developing good policies, or even good recommendations, in
> an environment that is this complex.  We  also run the risk that
> poor policies or poor guidelines could effectively make IDNs
> almost useless --or too dangerous to use-- in actual practice.
>
> So I have been unhappy with the 2.0 Guideline process.  The
> people involved in developing those Guidelines did, I believe,
> an outstanding job given a too-short time schedule (from when
> they actually got started in what turned out to be a hasty job
> after years of procrastination) and the wrong objective
> (patching the 1.0 Guidelines rather than starting with a clean
> slate and an analysis of the problems to be solved).  But they
> could not, in my opinion, overcome either obstacle.
>
> When Patrik and I came on the call, we really were not expecting
> to discuss  the IDN TLD issue at all (and the IAB report does
> not address it in any significant way) so our comments were
> personal on-the-spot reflections rather than carefully
> considered positions.  For me, my issues with the testbed ideas
> have been similar to those with the Guidelines.   We know from
> the original IDN testbed activities that it is easier to say
> "testbed" than it is to say "wait until we figure this out".
> Whether that is the right answer or not typically depends on
> what a testbed is intended to accomplish.   If the idea is to
> give some registrants, registrars, or registries an advantage or
> if the testbed is designed in a way that has that effect even if
> it was not intended, then testbeds are generally a poor idea (as
> I think we learned from the original IDN testbed some years
> ago).   I started writing the notes Cary circulated while
> listening to the audiocast of the IDN, public forum, and Board
> sessions in Vancouver.  They are, ultimately, nothing more than
> an attempt to turn such principles as "make sure it is really a
> test, not a head-start or commitment to a particular strategy"
> and "be sure that you understand what you are trying to learn
> and how you intended to learn it" into an outline of a testing
> procedure.
>
> Finally, as I and others have said before, we have three
> possible ways to implement what the user will see as IDNs at the
> top level:
>
>        (i) Name aliases in applications software
>
>        (ii) DNAME-type aliases in the root, with no separate
>        domain zone files.
>
>        (iii) Actual new TLDs with IDN-style names.
>
> No one of these is "best" in any absolute way.  Instead, each
> one has its own advantages, disadvantages, and risks.  Those are
> not just technical, although the technical issues are different
> with each one, but are different in terms of approvals,
> allocation models and their implications, IPR and cultural
> appropriateness in naming, questions of who stands to profit,
> and so on.   I believe that, if we are going to do tests, we
> need to use them to examine each of  the alternatives and its
> implications so that we can advise relevant parties as to what
> to do or not do and can advise ICANN on priorities and actions.
>
> regards,
>    john
>
>
>



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