Re: [gnso-idn-wg] MP3 recording link for the GNSO IDN -wg teleconference 27 February 2007

[Tan Tin Wee <tinwee@xxxxxxxxxxxxxx>]

Sorry I missed this teleconf.
I had wanted to raise one additional point in the next mtg on March 6,
with at least three subpoints as follows:

Avoiding Exclusionary policies in IDN implementation.
----------------------------------------------------
GAC's specific request to GNSO on its generic gTLD policy that
is being developed right now seems to be outcome based:
namely, that whatever the policies passed and implemented,
the outcome should lead to new gTLD awardees in ASCII or IDN
that originate from "geographically diverse" regions so as
to demonstrate the globalisation of the Internet and an
equitable set of policies and processes that do not
unfairly exclude certain regions.

To be specific, if new gTLD awardees do not come from poorer
countries, there must be something wrong with our processes
or procedures. While this may be unfair to the hard work that
we put in, they do have a point.

Therefore, we should go through our policies and processes
ask, "Who, particularly in geographically diverse regions,
will be hindered or worse excluded, from having a fair
chance of winning any bids for running a gTLD?"
In the context of IDNs, "who, in the places where IDNs
will be deployed and will have the most impact, will be
excluded?"

I have pulled up the following threads which may fall into
this category of policies we have to be careful not
to make recommendations that may lead to exclusionary
policies, processes and procedures:

a. Refundable deposits
----------------------
Should not be exclusionary. Deposits are required to
ensure bona fide non-frivolous applicants are selected
and riff-raff excluded. But developing country or
poorer entities should not be asked to pay exclusionary
deposits of USD50K before they can start talking.
This upfront amount has to be reduced to a sum of
some parity to their economic situation. This can be
easily based on GDP or some World Bank formula.
Most international organisations recognise this in
their membership fees.

b. Financial Prequalifications
------------------------------
In bids to run international services, financial requirements
familiar to most transnational corporations or listed companies
in major exchanges, such as audits  IFS reporting, Sarbannes Oxley
compliance, solvency checks, etc are standard procedures and due
diligence. So the fictitious International Association for
Poor People will have to be rich enough to stand up to
such financial scrutiny if it so wishes to run a sponsored gTLD
.poor for example.
However, it is obvious that some poor country wants to run
its own .IDN gTLD in their own language for their own poor
people who are the only users of their script, then we cannot
be asking them to fulfil such requirements. Typically,
we call that being unfair.

Registries and registrars in developing countries particularly, have
shown that to greater or lesser extents, that ccTLDs can be implemented
with some degree of "stability and security" without too much
financial fuss. So long as it is commensurate with the task
at hand, operational and technical competence etc, it should
not be put off by exclusionary policies of stringent financial
prequalifications of global standards.

Local services should be allowed to be provided by
local service providers for their local communities.
So long as they do not break the Internet or fragment
the global community in so doing, localisation friendly policies
and internationalisation go hand in hand.

c. Local Selection processes
----------------------------
So long as the services to be provided are internationalised,
and do not break the Internet, services for local communities
primarily should be selected first with local considerations
foremost. So selection of IDN gTLD service providers should
require minimally, technical competence commensurate with the
level of service needed, ie if that country's power supply is
only up 90% of the time, we don't really need to force the
domain name server to be running on a power supply at 24x7
with staff constantly on duty 24x7 and force them to have
capabilities that are disproportionately overkill.
So the selection of IDN service providers should be best
done by a specfic selection committee elected/nominated for
that language bidding process with members from that community.
This local community selection committee should of course
conform to universal requirements of probity and transparency
in their processes with observers or liaison from ICANN.
It is like we should avoid selecting a political party on
behalf of a population without allowing them suffrage.

d. Non-exclusionary process for extending existing
   ASCII TLD operations
   to IDN equivalents in other languages and scripts

Yoav said Sophia stated that IDN ccTLDs should not
be automatically given to current ccTLD registries.
I think this doesn't go far enough. IDN gTLDs should
not be automatically given to current gTLD registries
on the basis that they are "translations". I am sure
Cary Karp doesn't want to have .museum automatically
given to him because some translation in Swahili or
Ancient Icelandic happens to have something close
to meaning "museum" in these languages. It adds unnecessary
burden on existing gTLDs or ccTLDs to impose something
on them whether they want it or not.

If they want it, they can simply join in and bid for
it in whatever language committee.

Besides, using the same museum analogy (sorry Cary),
not all languages may have a direct translation of
museum, or the direct translations may not be used for
an entity that functions as a "museum" as we know of it.
Now Cary will know that .museum is probably a bad example
because there is an International Council of Museums,
but I think most of you will know what I mean. ICOM
can sort it out in whatever languages they want within
their community.

However, the point remains that any incumbent TLD operator
should not exclude or presume that its claim of an
equivalent in another language/script should not exclude
local operators in that language/script from having
a fair and equitable shot at it.



bestrgds
tin wee



> Subject:
> [gnso-idn-wg] MP3 recording link for the GNSO IDN -wg teleconference 
> 27 February 2007
> From:
> "GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>
> Date:
> Wed, 28 Feb 2007 11:33:21 +0100
> To:
> gnso-idn-wg@xxxxxxxxx
>
> To:
> gnso-idn-wg@xxxxxxxxx
>
>
> [To: gnso-idn-wg[at]icann.org]
>
> Dear All,
>
> As agreed upon during the call, would all members of the working group 
> provide statements of interest to the working group mailing list 
> before the next teleconference on 6 March 2007 at 11:00 UTC.
>
> As guidance for your statements you may like to refer to other working 
> groups that have provided statements of interest.
> Reserved Names working group (RN-wg)
> http://forum.icann.org/lists/gnso-rn-wg/msg00099.html
> Working Group to Protect the Rights of Others (PRO-wg)
> http://forum.icann.org/lists/gnso-pro-wg/msg00023.html
>
> Please find the  MP3 recording of the GNSO IDN Working group
> teleconference on 27 February 2007 at 21:00 UTC
>
> http://gnso-audio.icann.org/idn-wg-20070227.mp3
> http://gnso.icann.org/calendar/#feb
>
> Participants on the call:
>
> Ram Mohan - Working Group Chair
> Marilyn Cade - CBUC
> Mike Rodenbaugh - CBUC
> Will Rodger - CBUC
> Steve Crocker - Security and Stability Advisory Committee Liaison
> Paul Diaz - Registrar c.
> William Tan- Registrar c.
> Yoav Diaz - Registrar c.
> Werner Staub - Registrar c.
> Cary Karp - gTLD Registry constituency
> Maggie Mansourkia - ISPCP
> Sophia Bekele - Nominating Committee appointee to the GNSO Council
> Avri Doria - - Nominating Committee appointee to the GNSO Council
>
> ICANN Staff:
> Kurt Pritz - Senior Vice President, Services
> Tina Dam - IDN Program Director
> Maria Farrell - GNSO Policy Officer
> Glen de Saint Géry - GNSO Secretariat
>
> Absent apologies
> Olof Nordling - Manager, Policy Development Coordination
> Alistair Dixon - CBUC
>
>
> Thank you.
> Kind regards,
>
> Glen
>
> Glen de Saint Géry
> GNSO Secretariat - ICANN
> gnso.secretariat[at]gnso.icann.org
> http://gnso.icann.org