council
Threads by month
- ----- 2024 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
March 2006
- 20 participants
- 96 discussions
Dear fellow Councilors,
As you may be aware, I have put most my efforts in my short term at GNSO to
researching and reaching out to the IDN community. As such, I have had many
correspondences with *John C Klensin*, and the PAC group to understand some
of the significant issues that has slowed down the implementation of the
IDNs at a technical and policy level by ICANN. Given the upcoming meeting
in Wellington, I thought I will put forward directly to GNSO my recent
correspondence with John, to give attention to the matter. By doing so:
First, I wanted to *correct some of the confusions* that came back from the
interested readers, as to who said what in the email, because some people's
email does not read color or the authors name was not labeled
properly etc..so I have added the *word 'wrote' after the author to clarify.
*
Second, I CANNOT presume everyone is reading this emails, (they could be
quite long and tiresome) since it is not directed to GNSO, however, given
that the IDN policy making is to be our business soon, I thought I will at a
minimum share directly the substantive points with you.
Primarily, my position has been that *lack of policy in IDNs would bring a
great risk to the implementation of the technology* as it exist today:
1 - I think everyone is aware that IDN systems (with an IDN TLD root entry)
have been running for several years. That means there is a proven working
system out there, so *the technology is not a problem* and is a minor
consideration *compared to the policy issues.*
2 - If the proposed solution by ICANN is the DNAME solution, the policy
implications is far reaching. We need to know who the players in
registries, the intentions, the impact on the market, competition, the
cultural and political implication.
Finally, I hope this discussions below will help decipher the heads of key
people's thinking today that are working with ICANN as well as the IDN
community I did outreach with. At a minimum, this can give us a heads up to
prepare us for the GNSO/PAC meeting in Wellington.
Thank you for reading,
Sophia
------------
Sophia wrote:
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. * Despite your pointing to the
study of DNS, which I appreciate, my finding tells me that our differences
are more of a philosophical than a major technical gap.
On 15/02/06, *John C Klensin* <klensin(a)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 wrote:
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 myself and other interested readers.
John wrote:
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(a)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 wrote:
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 wrote:> 1- if 'mybrand' is to be protected i.e trademark in every
> country...it is a matter of purchasing all the 'mybrand'
> TDLs...
John wrote:
- Show quoted text -
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.
Sophia wrote:
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 wrote:
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 wrote:
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.
Sophia wrote:
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 wrote:
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.
Sophia wrote:
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 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 wrote:
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 wrote:
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 wrote> What are the implications above?
John wrote:
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 wrote:
*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(a)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 wrote:
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 wrote:
*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, 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 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 wrote:
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 wrote:
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 wrote:
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 wrote:
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 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 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 wrote> 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 wrote:
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 wrote:
*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 case of emergency. *
*.* *[image: Navy SEALs]*
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 wrote:
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 wrote:
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 wrote:
- Show quoted text -
> 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 wrote:
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 wrote> 3) I may be presumptuous, but ICANN's argument of resorting to
> using DNAME seem to come from the perspective of how ICANN
> failed to be responsive for long and now "China" and others
> are threatening to "break the single root". Therefore,
> perhaps, we were left to a single view and a quick solution,
> neglecting to entertain the CHOICES we may have for IDN. So,
> the easiest implementation approach is DNAME, which is is to
> just give the big registries all the languages without having
> to change much in the technical stuff - ie. just re-point.com
> to every language equivalent - no new TLDs etc.
John wrote:
- Show quoted text -
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 wrote:
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 wrote> John's statement butters 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 wrote:
- Show quoted text -
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 wrote> *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.
John wrote:
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 wrote> 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.*
John wrote:
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 wrote:
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 wrote:
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 wrote> 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 wrote:
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 wrote> 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 wrote:
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.
*Sophia wrote: *Answering each of your points in order* *
*First,* I have come to understand that technical people tend to view things
in only technically acceptable terms, and in this case multilingual domain
names serving the need for non-English speakers to reach web-sites in their
own character sets. *However, in my experience, in the real world -
particularly so in disenfranchised parts of the world - often choices are
made that cannot only be technically acceptable but they must also be
"emotionally" acceptable*. My understanding is that for IDNs the peoples of
the different languages would strongly prefer an approach where IDN TLDs in
so much as possible mirror and be "parallel" to ASCII TLDs. (and saying
ASCII is not English is a worthless argument that only the adamantly
technical people insist on - the wise accept the emotional reality and work
around it). Thus the "proposal I am to have rejected out of hand" lacks the
emotional merits of IDN TLDs that work more in a "parallel" manner. And
emotion has a lot do with it - one can build highly efficient and better
designer homes but everyone still wants a "doll house" to live in.
--
John wrote:
--Second, scripts and not the same as languages and people
don't speak scripts: not understanding the difference can only increase your
confusion.
Sophia wrote:
S*econd*, *it is refreshing to know that there are knowledgeable individuals
like you who work so hard to decrease the confusion of the less gifted like
me.** * I suppose the fact that *the Amharic script* is used for various
languages in Ethiopia and Somalia including *Amharic*, Tigre and Tigrinya by
a mere 30 million or so people, all without the benefit of the great
knowledge you have, must leave them all confused and speaking in twisted
tongues and many languages at once, *just like me.* And I can only be ever
so grateful for having escaped that many-language-to-one-script mess to
speaking the one-script-to-one-language-English (even though I hear some
rumors that some 200 million Indonesians may have borrowed it too*). *However,
I admit I must also be not so good at English, since I cannot understand the
phrase "scripts and not the same as languages" in your discussion above.
John wrote:
--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.
Sophia wrote:
*Third,* the *notion of different roots for different languages is
impossible you suggest*. But from my understanding recent reports suggest
that some 100M + people in China (maybe accounting for some half of the
world's truly IDN-needy population) have been enabled to do just that for
over a few years, with no deaths or no calamities reported. I understand
that you have been quoted in the press as suggesting that the Chinese are
solving this by "appending" .cn in English characters and thus not really
dealing with a different root. *However even the BBC quotes eminent
Internet-aware professors and Cambridge university researchers as having
tested the Chinese deployment and that there is much much, more to it than
meets the eye (see link below) *and that the long-deployed system is in
essence a different language root or very close to it. I also understand,
that in past years, many technical people have talked about so-called
multiple roots-of-authority - I believe these include prominent previous
ICANN Board of Directors like Karl Auberach etc. I am puzzled why you think
it's impossible, unless in a very very narrow sense but then again my lot in
life seems to be always confused.
As for the "tragedy" that one would have to legally protect one's business
names and trademarks as domain names in every sovereign country
independently, I think that is exactly what we do with trademarks today and
it would appear its no more onerous to protect one's domains in conjunction
with trademark protection than just trademark protection, if your business
needs that protection in country "x" (domains cost far less than trademark
protection). *And I believe that is why sovereign-nation states exist.* Of
course one can solve it all by simply globalizing the whole world into one
federated galactic empire and put Captain Kirk in charge of it. And while
at it, we could force everyone to learn English - then the problem simply
goes away.
http://news.bbc.co.uk/1/hi/technology/4779660.stm
http://news.bbc.co.uk/1/hi/technology/4767972.stm
Should have thought of that, far easier than solving these intractable
technical problems that only the Chinese and certain largest-European ISPs
like Tiscali seem to be rumored to be able to solve.
1
0
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(a)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.
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.
> 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(a)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.
>
> 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.
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.
> 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.
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 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!** *
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.
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.
> 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.
*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(a)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.
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.
**
*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, 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 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.
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.
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.
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.
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 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 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.
> 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.
*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!*
[image: Navy SEALs]
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. *
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.
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.
> 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.
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*.
> 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.
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.
> 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
;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
1
2
I think the ISPCP would also be likely to add their support for this
item. Its important we try to nail down a process that overcomes some of
the current shortfalls which impact many registrants.
Tony
-----Original Message-----
From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org]
On Behalf Of Ken Stubbs
Sent: 05 March 2006 01:53
To: 'GNSO Council'
Subject: Re: [council] Agenda Request
Marilyn's observations here are quite relevant..
there has to be basic "enforceable" safeguards built into the process to
deal with inadvertent expirations
and accidental deletions..
many companies (large & small) , have invested significant funds &
resources into their respective internet presence and
to think that it could all "evaporate" over a mistake made by someone in
the accounts payable department or a misdirected email (i.e. spam
filtered) is disconcerting to say the least... !
regards
ken stubbs
Marilyn Cade wrote:
I am interested in this topic. I chaired the Transfers TF, and we dealt
with a variety of topics in that TF...
But, the Redemption Grace Period emerged as a safeguard for registrants.
In those days, I worked for AT&T, and they had a portfolio of over 500
names, including .net; .com; .org; several dozen country codes where
they had market facing presence, and when the "proof of concept" TLDs
were introduced, they also defensively registered in info and .biz in
particular.
Managing the portfolio was part of an assignment to a particular part of
the corporation, but still, it was challenging and not simple to keep
track of.
I registered a name or two that I wanted to use, for organizing ad hoc
coalitions, and managed them myself. And, then, when I left AT&T, I
registered two names, one to use, one to defensively protect my "name".
I am now an "average registrant" -- I need all the safeguards I can
get. My registrar is extremely responsible - wait, BOTH my registrars
are responsible. BOTH of them remind me, and remind me, and REMIND me...
but you know, I travel, I have a 90 year old father and I get
distracted... and I am the CEO of a small business with a lot of other
distractions... and focusing on my domain name doesn't always rise to
the top of my agenda.... Yet, I depend on it....
So, I need all the safeguards I can get. ... :-) within reason.
I'll try not to extrapolate from my own experience and ineptness, but
still, I think about the 'average' registrant. ... and thus, consensus
policy for RGP seems fully appropriate.
Marilyn
_____
From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org]
On Behalf Of Sophia B
Sent: Saturday, March 04, 2006 7:16 PM
To: ross(a)tucows.com
Cc: GNSO Council
Subject: Re: [council] Agenda Request
I believe that the current policy is fine. It gives enough time in any
way it is implemented for registrants to renew. Many people are
irresponsible and that is why they loose their domains. I don't think
giving them more time would change it.
Choosing a better registrar that does a good job of protecting them is
more important.
Sophia
On 03/03/06, Ross Rader <ross(a)tucows.com> wrote:
Bruce, fellow Councillors,
At our next meeting, I would like to propose the initiation of a new
policy development process concerning the Redemption Grace Period and
request that this topic be added to our agenda.
It has recently come to my attention recently that the current
implementation (detailed at
http://www.icann.org/bucharest/redemption-topic.htm) is an optional
registry service which may not be meeting the needs of registrants as
originally envisaged when it was implemented. Recent press reports (see
below) and registrant complaints indicate that names are being lost
despite the implementation of this registry service.
I have spent a lot of time considering whether or not Council can afford
to take on additional work given our current workload and have come to
the view that because of the widespread support for the Redemption Grace
Period amongst the constituencies (as documented on the ICANN website)
and the pre-existence of strong policy and implementation proposals that
already have consensus support of the stakeholders, we should be able to
confirm the Redemption Grace Period proposals as consensus policy fairly
quickly and without much additional effort or contentious debate.
Because of the pre-existing consensus on this issue, I will propose to
move this forward without creating a task force per Annex A, Section 8
of the ICANN Bylaws once we have agreed to initiate a PDP and been
provided with an issues report by the staff.
(http://www.icann.org/general/bylaws.htm#AnnexA-8). i.e. the fast-track.
In the very least, creation of an issues report will gather up
substantive data on this subject and allow us to make an informed
decision regarding whether or not circumstances like those detailed
below are widespread enough to justify launching a full-fledged PDP.
Your consideration of this matter would be extremely appreciated. If you
have any questions, please don't hesitate to drop me a note (or give me
a ring).
-ross
'Drop Catchers' Buy and Sell Web Names Others Let Slip
By DAVID KESMODEL
Wall Street Journal
February 22, 2006; Page B1
Last month, Chicago real-estate agent Judy Orr discovered that a Web
site she used to showcase area homes had gone off-line. It turned out
she had failed to pay the $9 annual renewal fee for her Web address,
oak-lawn-real-estate.com.
But getting her site back online wasn't as easy as she had hoped:
Another company had snapped up the domain name and wanted nearly $2,500
to return it to her. "I was sick to my stomach," Ms. Orr says. It took
two years of work to build up the site so it would rank prominently in
Google's search results, and that time "went down the drain," she says.
The new owner of the address was Lease Domains Inc., which is run by a
21-year-old graduate student, Anthos Chrysanthou, who works out of his
parents' house in a Chicago suburb. Mr. Chrysanthou says his
two-year-old company owns more than 2,000 domain names, many obtained
through a process called "drop catching" -- snagging names owners have
let expire, either accidentally or because they no longer want them.
"I liken the whole situation to tangible real estate," says Mr.
Chrysanthou, who is pursuing his master's in business administration at
St. Xavier University in Chicago. "If you're not paying your mortgage or
your taxes on it, it's going to get taken away."
Mr. Chrysanthou is one of hundreds of drop catchers who either resell
names or use them for Web sites loaded with advertisements. (Ms. Orr's
former site now features text ads for real estate.) Many drop catchers
have learned the trade in the past year, seeking a piece of the booming
market for domains spurred by a surge in online advertising. The
practice also has gotten a lift from providers of domain services, such
as SnapNames.com Inc., Pool.com Inc. and GoDaddy.com Inc., which have
introduced tools aimed at helping people grab expiring domains.
The services circulate lists each day showing which domains are about to
go up for grabs. Auctions are held for particularly in-demand names, and
prices can go sky-high: A1.com sold for $260,250 in December, after its
previous owner let the registration lapse.
Drop catching "has pretty much changed completely in a few years' time,"
says Michael Berkens, who runs MostWantedDomains.com, owner of about
45,000 domains, which range from 4nudepictures.com to 401kplans.com, out
of his Fort Lauderdale, Fla., home. "There's more people," he says, and
"prices have just escalated."
DNJournal.com , a publication that tracks the domain industry, reported
2,291 sales of expired domains in auctions last year, with winning bids
totaling a combined $11.5 million. That was up from 885 sales totaling
$4.2 million a year earlier. Auctioneers don't report all deals to
DNJournal, and the site doesn't track deals valued at less than $500.
Roughly 20,000 expired domain names become available each day, according
to industry executives. While many were consciously discarded by their
owners, others, like Ms. Orr's, are the product of a domain-registration
system that many users don't understand well.
When a user registers a domain name, it can be reserved for as many as
10 years, typically for $80. But many choose a one-year registration
because it is less expensive, often about $10, and because they may not
want the site for a longer period. At the end of the year, the domain
registrar generally sends renewal notices to the owner, but such
messages can be missed if the owner has changed email addresses in that
time.
Under rules administered by the Internet Corporation for Assigned Names
and Numbers, the group that oversees the assignment of Web addresses,
domain registrars such as GoDaddy and Network Solutions LLC have as many
as 45 days after the expiration date to notify the official domain
registry whether a name is being renewed or deleted. Typically,
registrars have given users a grace period -- sometimes as long as 45
days -- to renew their name.
If a name is deleted, ICANN guidelines then call for a 30-day
"redemption grace period," during which the original owner can still
claim the name. If there is no claim in the redemption period, the name
is dropped from the registry after a five-day holding period, and anyone
is entitled to seek it.
For the .com and .net registries, managed by VeriSign Inc., names drop
starting around 2 p.m. Eastern each day, all year long. What follows is
a process that some in the industry call "pounding." As the names drop,
Internet companies that help users acquire expired names send rapid
computer commands to the registry, seeking to grab the most valuable
names. It is "a mad rush," says Dan Rubin, who runs justdropped.com,
which helps people identify and acquire expired domains. Registries for
other domain suffixes drop names at different times of day.
The drop process underwent a key shift starting in late 2004. That is
when SnapNames started a new service for grabbing domains. The company
has signed exclusive agreements with more than a half-dozen registrars,
including Network Solutions and Moniker.com, under which the registrars
transfer expired domains to SnapNames, and SnapNames auctions them off.
That way, names that people are interested in don't go through the
traditional drop process that is open to anyone.
GoDaddy, the largest domain registrar, has introduced its own auction
service for expired names that were registered with it, as have other
registrars, as they seek a cut of the action for expired names. They
begin auctions for names even before the names have officially expired
but warn auction participants that the original owner could still redeem
the name.
For domain owners, the new system means names can be grabbed from them
even more quickly than they could before. Instead of going through the
full deletion cycle -- which went as long as 75 days -- names are being
transferred to new owners in 30 to 45 days.
Paul Twomey, chief executive of ICANN, says some people in the domain
industry recently have raised concerns that the guidelines governing
expired names are "being utilized in ways that were not originally
intended." But Mr. Twomey says no one has proposed a formal change in
policy to address the issue.
Ms. Orr's name, oak-lawn-real-estate.com, is one of those that was
transferred before going through the full deletion process, says Jay
Westerdal, who runs Name Intelligence Inc., a Bellevue, Wash., company
that tracks the industry.
Tim Ruiz, vice president of domain services for GoDaddy, which
transferred the name, says, "We make every attempt to give ample
opportunity for registrants to renew." He says the company gives
registrants 30 days to claim a name after it has expired.
If a corporation loses a domain name that it believes is copyrighted or
trademarked, it can seek to recover the name by appealing to an
arbitration panel under ICANN's dispute-resolution policy. It also could
take the domain's new owner to court, though that can be more expensive.
Ms. Orr says she lost her site's name, which wasn't copyrighted or
trademarked, because she made the mistake of relying on her Web-hosting
company to keep track of her registration. She says she didn't see
renewal notices from GoDaddy because it had an old email address for
her. Ms. Orr plans to use another site -- oak-lawn-il.com -- to replace
the one she lost.
--
Sophia Bekele
Voice/Fax: 925-935-1598
Mob:925-818-0948
sophiabekele(a)gmail.com
sbekele(a)cbsintl.com
SKYPE: skypesoph
www.cbsintl.com <http://www.cbsintl.com>
6
12
15 Mar '06
** High Priority **
hi bruce, just a quick, if belated, note on the draft agenda you circulated. it shows the gac gnso working group meeting with the gnso council at 11 a.m. on Sunday, while our gac agenda has the meeting time as 9 a.m. to 11 a.m. i hope it doesn't create much of a problem for the council to re-arrange the morning schedule. please let me know asap if that would be the case. thanks, suz.
Suzanne R. Sene
Senior Policy Advisor
NTIA/OIA
202-482-3167 (ph)
202-482-1865 (fax)
>>> "Bruce Tonkin" <Bruce.Tonkin(a)melbourneit.com.au> 3/13/2006 6:46 PM >>>
Hello All,
Please note that I have posted two messages regarding the meetings of
the GNSO Committee on new gTLDs in Wellington to the Committee mailing
list.
The archives can be found at:
http://forum.icann.org/lists/gtld-council/
Regards,
Bruce Tonkin
1
0
Colleagues
As discussed on the Council's call last night, please find attached
the updated Initial Report which reflects the Washington DC meeting
inputs.
I have also attached, in case you haven't got it easily to hand, the
Call for Additional Information: Technical Criteria document which I
sent out last week. Could you please distribute this to your
constituencies for discussion at the Wellington meetings?
These two documents will form the basis of the discussion at the two
days of meetings on 25 & 26 March in Wellington. The final agenda
for those two days will be distributed separately.
Of course, any questions, let me know.
Kind regards.
Liz

.....................................................
Liz Williams
Senior Policy Counselor
ICANN - Brussels
+32 2 234 7874 tel
+32 2 234 7848 fax
+32 497 07 4243 mob
1
0
Extension : Public Comment Period and constituency statements on PDP-Feb06 to 30 APRIL 2006
by GNSO.SECRETARIAT@GNSO.ICANN.ORG 15 Mar '06
by GNSO.SECRETARIAT@GNSO.ICANN.ORG 15 Mar '06
15 Mar '06
[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org]
[To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org]
Extension of Public Comment Period and constituency statements on the
Terms of Reference for the PDP on policies guiding contractual
conditions for existing gTLD registry agreements, (PDP-Feb06) to 30
April 2006.
"Public comments are invited on any of the policy issues included in the
Terms of Reference for the PDP on policies guiding contractual
conditions for existing gTLD registry agreements, notably:
1. Registry agreement renewals
2. Relationship between registry agreements and consensus policies
3. Policy for price controls for registry services
4. ICANN fees
5. Uses of registry data
6. Investments in development and infrastructure
Public comments are open from 7 March 2006 to 30 April 2006.
Please note that any new policies to address these issues must be
consistent with the ICANN mission and core values, thus it would be
particularly helpful if the comments are made with reference to the
ICANN mission and core values as defined in the ICANN bylaws
http://www.icann.org/general/archive-bylaws/bylaws-08apr05.htm#I
--
Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org
1
0
[To: council[at]gnso.icann.org]
Dear Council Members,
Please find the draft minutes of the GNSO Council meeting held on 2
March 2006.
Please let me know what changes you would like made.
Thank you very much.
Kind regards,
Glen
2 March 2006
Proposed agenda and related documents
List of attendees:
Philip Sheppard - Commercial & Business Users C.
Marilyn Cade - Commercial & Business Users C.
Grant Forsyth - Commercial & Business Users C
Greg Ruth - ISCPC
Antonio Harris - ISCPC
Tony Holmes - ISCPC
Thomas Keller- Registrars
Ross Rader - Registrars
Bruce Tonkin - Registrars
Ken Stubbs - gTLD registries
June Seo - gTLD registries
Cary Karp - gTLD registries
Lucy Nichols - Intellectual Property Interests C - absent - apologies
Ute Decker - Intellectual Property Interests C - absent - apologies
Kiyoshi Tsuru - Intellectual Property Interests C.
Robin Gross - NCUC. - absent
Norbert Klein - NCUC.
Mawaki Chango - NCUC
Sophia Bekele - Nominating Committee appointee
Maureen Cubberley - Nominating Committee appointee
Avri Doria - Nominating Committee appointee
18 Council Members
ICANN Staff
Dan Halloran - Deputy General Counsel
Kurt Pritz - Vice President, Business Operations
Olof Nordling - Manager, Policy Development Coordination
Maria Farrell - ICANN GNSO Policy Support Officer
Liz Williams - Senior Policy Counselor
Tina Dam - Chief gTLD Registry Liaison
Glen de Saint Géry - GNSO Secretariat
GNSO Council Liaisons
Suzanne Sene - GAC Liaison - absent - apologies
Bret Fausett - ALAC Liaison
Quorum present at 19:08 UTC.
MP3 Recording
Bruce Tonkin chaired this teleconference.
Approval of agenda
Marilyn Cade requested the an update on the Wellington schedule under
Any Other Business
Item 1: Approval of the GNSO Council minutes 6 February 2006
Ross Rader moved the adoption of the minutes.
Motion approved.
Decision 1: The GNSO Council minutes of 6 February 2006 were adopted.
Update on GNSO Review and introduction of the reviewers
The London School of Economics (LSE) Public Policy Group has been
appointed to undertake the GNSO Review, Prof. Patrick Dunleavy, Simon
Bastow, and Oliver Pearce were invited to address the council.
The expenditure approved by the Board for the GNSO Review was $150000
USD to be expended over the period of the review process.
The group is engaged in academic and research consultancy having worked
for the United Kingdom Government, international bodies and foreign
governments with a recent work focus on e-government.
The Review would consist of several components,
- the main one being a web site with a survey for each constituency,
accessible in English, Portuguese, French, Spanish, Arabic and Russian,
with a user identity and password,
- a large outreach team at the LSE e-mailing and communicating directly
with people,
- press advertising,
- a weblog and
- discussion group to interactively solicit views.
In addition there would be:
- a comprehensive series of interviews also taking place during the
Wellington meetings,
- examination of documentation and other data focused on the areas of
representativeness, transparency, effectiveness and compliance in the
GNSO Review Terms of Reference.
The emphasis is on seeking a broad range of views.
To a question raised about the review examining the GNSO role in
registry /registrar compliance, the clarification was that it was
intended to contextualise comments on how the GNSO was viewed, rather
than quantify how GNSO enforced compliance.
Item 2: Terms of reference for PDP-Feb06
- Decide the terms of reference for the PDP (Under the provisions of
section 7(b) of Annex A of the ICANN bylaws)
Bruce Tonkin noted the gTLD Registry constituency statement concerning
the PDP Feb06 posted to the Council mailing list.
The process to date was that an initial draft Terms of Reference (TOR)
for PDP-Feb06 was produced on 8 February 2006, a conference call was
scheduled on 16 February 2006, during which some constituencies
expressed the need for more time to discuss the issue, after the call
the ICANN staff produced a revised draft TOR . At an ad hoc working
session of the GNSO council in Washington DC, on Friday 24 February
2006, (present: Bruce Tonkin, Ross Rader Registrar constituency; Marilyn
Cade CBUC; Mawaki Chango NCUC; Ken Stubbs, Cary Karp remote
participation gTLD registries constituency; Tony Holmes remote
participation ISPCPC, remote participation; Avri Doria and Maureen
Cubberley, remote participation Nominating committee appointees),the
Council members further edited the TOR. The current teleconference was
scheduled with the intention to finalise and put the Terms of Reference
to the vote.
Bruce Tonkin asked whether any councillor wished to make a statement of
interest that had not been previously declared.
Ross Rader mentioned updating his statement of interest indicating that
some of Tucows clients might be active in the GNSO or ICANN.
Bruce Tonkin clarified that pursuant to discussion with the General
Counsel's office, while the issue topic area was within ICANN's mission
and core values, any proposed policy should likewise relate to the
mission and the core values of ICANN.
Marilyn Cade, seconded by Avri Doria proposed the motion,
That Council approves the Terms of Reference for the policy development
process on GNSO policies for contractual conditions for existing gTLDs
(PDP-Feb06) as drafted with the insertion of the words "and core values"
in the paragraph on
"Goal" namely;
"The overall goal of this PDP therefore is to determine what policies
are appropriate, for the long term future of gTLDs within the context of
ICANN's mission "and core values," that relate to the issues identified
in the specific terms of reference below.
Context
The GNSO initiated a policy development process in December 2005
[PDP-Dec05] to develop policy around whether to introduce new gTLDs, and
,if so, determine the selection criteria, allocation methods, and
contractual conditions.
During 2005, ICANN commenced a process of revising the .net and .com
agreements. There has been substantial discussion amongst members of the
GNSO community around both the recently signed .net agreement (dated 29
June 2005), and the proposed .com agreements (dated 24 October 2005 and
29 January 2006).
As a result, the GNSO Council recognized that issues such as renewal
could be considered as part of the broader issue of contractual
conditions for existing gTLDs, and that it may be more appropriate to
have policies that apply to gTLDs generally on some of the matters
raised by GNSO members, rather than be treated as matters to negotiate
on a contract by contract basis.
Subsequently on the 17 January 2006, GNSO Council requested that the
ICANN staff produce an issues report "related to the dot COM proposed
agreement in relation to the various views that have been expressed by
the constituencies." This issues report is available at:
http://www.gnso.icann.org/mailing-lists/archives/council/msg01951.html
.
Section D of this issues report provides a discussion of many of the
issues that had been raised by the GNSO community in response to the
proposed revisions to the .com agreement. In the issues report the ICANN
General Counsel advised that it would not be appropriate to consider a
policy development process that specifically targets the .com registry
agreement.
At its meeting on 6 February 2006, members of the GNSO Council clarified
that the intention of the request for the issues report was to seek an
issues report on the topic of the broader policy issues that relate to
the contractual conditions of gTLD agreements, which have been
identified from the various views expressed by the GNSO constituencies
on the proposed .com agreement.
At its meeting on 6 February 2006 the GNSO Council recognised that while
the PDP initiated in December 2005 [PDP-Dec05] included within its terms
of reference the topic of contractual conditions, a possible outcome of
that PDP would be that there should be no additional gTLDs, and thus the
Council could not depend on this PDP to address the issues raised by the
GNSO community.
Thus at its meeting on 6 February 2006, the GNSO Council, by a
super-majority decision, decided to initiate a separate PDP [PDP-Feb06]
to look at specific areas of contractual conditions of existing gTLDs.
The work of PDP-Feb06 will naturally be conducted within the context of
the work on PDP-Dec05, and if it is decided that new gTLDS should be
introduced, the policy work of PDP-Feb06 will be incorporated into a
single gTLD policy.
Goal
The overall goal of this PDP therefore is to determine what policies are
appropriate, for the long term future of gTLDs within the context of
ICANN's mission and core values, that relate to the issues identified in
the specific terms of reference below.
Terms of Reference
1. Registry agreement renewal
1a. Examine whether or not there should be a policy guiding renewal, and
if so, what the elements of that policy should be.
1b. Recognizing that not all existing registry agreements share the same
Rights of Renewal, use the findings from above to determine whether or
not these conditions should be standardized across all future agreements.
2. Relationship between registry agreements and consensus policies
2a. Examine whether consensus policy limitations in registry agreements
are appropriate and how these limitations should be determined.
2b. Examine whether the delegation of certain policy making
responsibility to sponsored TLD operators is appropriate, and if so,
what if any changes are needed.
3. Policy for price controls for registry services
3a. Examine whether or not there should be a policy regarding price
controls, and if so, what the elements of that policy should be. (note
examples of price controls include price caps, and the same
pricing for all registrars)
3b. Examine objective measures (cost calculation method, cost elements,
reasonable profit margin) for approving an application for a price
increase when a price cap exists.
4. ICANN fees
4a. Examine whether or not there should be a policy guiding registry
fees to ICANN, and if so, what the elements of that policy should be.
4b. Determine how ICANN's public budgeting process should relate to the
negotiation of ICANN fees.
5. Uses of registry data
Registry data is available to the registry as a consequence of registry
operation. Examples of registry data could include information on domain
name registrants, information in domain name records, and traffic
data associated with providing the DNS resolution services associated
with the registry.
5a Examine whether or not there should be a policy regarding the use of
registry data for purposes other than for which it was collected, and if
so, what the elements of that policy should be.
5b. Determine whether any policy is necessary to ensure
non-discriminatory access to registry data that is made available to
third parties.
6. Investments in development and infrastructure
6a. Examine whether or not there should be a policy guiding investments
in development and infrastructure, and if so, what the elements of that
policy should be.
The motion carried by roll call vote with 17 votes in favour, 6 votes
against.
Votes in favour: Philip Sheppard, Marilyn Cade, Grant Forsyth, (CBUC)
Tony Holmes, Tony Harris, Greg Ruth, (ISPCPC) Norbert Klein, Mawaki
Chango, (NCUC) Maureen Cubberley, Sophia Bekele, Avri Doria, (Nominating
committee appointees) Ross Rader, Tom Keller and Bruce Tonkin,
(Registrar constituency each with a double vote)
Votes against: Cary karp, Ken Stubbs and June Seo, (gTLD registries
constituency each with a double vote).
Absent: Robin Gross; absent with apologies: Ute Decker and Lucy Nichols;
Kiyoshi Tsuru had dropped off the call at the time of the vote.
Decision 2 :
That Council approves the Terms of Reference for the policy development
process on GNSO policies for contractual conditions for existing gTLDs
(PDP-Feb06) as drafted with the insertion of the words "and core values"
in the paragraph on
"Goal" namely;
"The overall goal of this PDP therefore is to determine what policies
are appropriate, for the long term future of gTLDs within the context of
ICANN's mission "and core values," that relate to the issues identified
in the specific terms of reference below.
Context
The GNSO initiated a policy development process in December 2005
[PDP-Dec05] to develop policy around whether to introduce new gTLDs, and
,if so, determine the selection criteria, allocation methods, and
contractual conditions.
During 2005, ICANN commenced a process of revising the .net and .com
agreements. There has been substantial discussion amongst members of the
GNSO community around both the recently signed .net agreement (dated 29
June 2005), and the proposed .com agreements (dated 24 October 2005 and
29 January 2006).
As a result, the GNSO Council recognized that issues such as renewal
could be considered as part of the broader issue of contractual
conditions for existing gTLDs, and that it may be more appropriate to
have policies that apply to gTLDs generally on some of the matters
raised by GNSO members, rather than be treated as matters to negotiate
on a contract by contract basis.
Subsequently on the 17 January 2006, GNSO Council requested that the
ICANN staff produce an issues report "related to the dot COM proposed
agreement in relation to the various views that have been expressed by
the constituencies." This issues report is available at:
http://www.gnso.icann.org/mailing-lists/archives/council/msg01951.html
.
Section D of this issues report provides a discussion of many of the
issues that had been raised by the GNSO community in response to the
proposed revisions to the .com agreement. In the issues report the ICANN
General Counsel advised that it would not be appropriate to consider a
policy development process that specifically targets the .com registry
agreement.
At its meeting on 6 February 2006, members of the GNSO Council clarified
that the intention of the request for the issues report was to seek an
issues report on the topic of the broader policy issues that relate to
the contractual conditions of gTLD agreements, which have been
identified from the various views expressed by the GNSO constituencies
on the proposed .com agreement.
At its meeting on 6 February 2006 the GNSO Council recognised that while
the PDP initiated in December 2005 [PDP-Dec05] included within its terms
of reference the topic of contractual conditions, a possible outcome of
that PDP would be that there should be no additional gTLDs, and thus the
Council could not depend on this PDP to address the issues raised by the
GNSO community.
Thus at its meeting on 6 February 2006, the GNSO Council, by a
super-majority decision, decided to initiate a separate PDP [PDP-Feb06]
to look at specific areas of contractual conditions of existing gTLDs.
The work of PDP-Feb06 will naturally be conducted within the context of
the work on PDP-Dec05, and if it is decided that new gTLDS should be
introduced, the policy work of PDP-Feb06 will be incorporated into a
single gTLD policy.
Goal
The overall goal of this PDP therefore is to determine what policies are
appropriate, for the long term future of gTLDs within the context of
ICANN's mission and core values, that relate to the issues identified in
the specific terms of reference below.
Terms of Reference
1. Registry agreement renewal
1a. Examine whether or not there should be a policy guiding renewal, and
if so, what the elements of that policy should be.
1b. Recognizing that not all existing registry agreements share the same
Rights of Renewal, use the findings from above to determine whether or
not these conditions should be standardized across all future agreements.
2. Relationship between registry agreements and consensus policies
2a. Examine whether consensus policy limitations in registry agreements
are appropriate and how these limitations should be determined.
2b. Examine whether the delegation of certain policy making
responsibility to sponsored TLD operators is appropriate, and if so,
what if any changes are needed.
3. Policy for price controls for registry services
3a. Examine whether or not there should be a policy regarding price
controls, and if so, what the elements of that policy should be. (note
examples of price controls include price caps, and the same
pricing for all registrars)
3b. Examine objective measures (cost calculation method, cost elements,
reasonable profit margin) for approving an application for a price
increase when a price cap exists.
4. ICANN fees
4a. Examine whether or not there should be a policy guiding registry
fees to ICANN, and if so, what the elements of that policy should be.
4b. Determine how ICANN's public budgeting process should relate to the
negotiation of ICANN fees.
5. Uses of registry data
Registry data is available to the registry as a consequence of registry
operation. Examples of registry data could include information on domain
name registrants, information in domain name records, and traffic
data associated with providing the DNS resolution services associated
with the registry.
5a Examine whether or not there should be a policy regarding the use of
registry data for purposes other than for which it was collected, and if
so, what the elements of that policy should be.
5b. Determine whether any policy is necessary to ensure
non-discriminatory access to registry data that is made available to
third parties.
6. Investments in development and infrastructure
6a. Examine whether or not there should be a policy guiding investments
in development and infrastructure, and if so, what the elements of that
policy should be.
Item 3: Any other business
3.1 Update on Wellington
The Secretariat reported that following the proposed draft schedule
there would be an administrative session for councillors present on
Friday afternoon, 24 March 2006 in the InternetNZ's office. On Saturday
25 and Sunday 26 March 2006, the new gTLD committee would work on policy
issues related to new gTLDs.The GAC working group would meet with the
GNSO for 2 hours on Sunday morning. There is a proposed working dinner
involving the GNSO council and the ICANN board, not yet confirmed, on
Sunday night, 25 March2006. Constituency day is scheduled for Monday 27
March. The GNSO Council Public Forum is scheduled for Wednesday, 29
March followed by the GNSO Council meeting on the same day.
Bruce Tonkin thanked the council members and the London School of
Economics team undertaking the GNSO review for their participation.
The meeting ended: 21:10 UTC.
Next GNSO Council teleconference 14 March 2006 at 19:00 UTC
see: Calendar
Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org
1
0
ÐÏࡱá>þÿ prþÿÿÿqÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á` ð¿è1bjbjËsËs .B©©è)ÿÿÿÿÿÿ€xxxxxxxøøøø$á\hDDDDDD|ÀT,`\b\b\b\b\b\b\$I^h±`€\x@DD@@\xxDD\NNN@"xDxD`\N@`\NN¢\Wäxx¬YD8Ðýµ#ÚGÆøbÖ@Y6`\±\0á\vY6Ua8Ual¬Y¬Y¬UaxX[@@N@@@@@\\8@@@á\@@@@ ä xxxxxxÿÿÿÿDRAFT v1.0 (15 March 2006) GNSO Council Rules of Procedure
1. GNSO Chair
1.1 Election. The GNSO Council chair will be elected in accordance with the ICANN bylaws, Article X, Section 3, Paragraph 7. Where possible the term of the GNSO Council chair will be aligned to end at the next Annual General Meeting (AGM) of ICANN.
1.2 Meeting schedules. The GNSO Chair will finalise a schedule of meetings on a quarterly basis. GNSO members may request changes to the schedule which may be agreed upon by the Chair in consultation with the Council, subject to the minimum period of notice below.
2. Conduct of GNSO meetings
2.1 Meetings will be conducted in accordance with ICANN bylaws, Article X, Section 3, Paragraph 8.
2.2 Voting will be in accordance with ICANN bylaws, Article X, Section 5, Paragraph 2.
2.3 Quorum. In compliance with by-law Article X 3(8) ), members entitled to cast a majority of the total number of votes of GNSO Council members then in office shall constitute a quorum
2.4 Speaking at meetings Both at physical and telephone meetings the GNSO Chair will recognise three types of intervention in the following order of priority:
A point of order
A point of information
A normal substantive intervention
At a physical meeting, a GNSO Council member may raise a hand or during a teleconference an GNSO Council member may speak over the dialogue and say immediately "point of order". The Chair will suspend discussion and hear the point. Points of information and normal interventions. At a physical meeting, an GNSO Council member may raise a hand and wait to be recognised by the Chair and during a teleconference an GNSO Council member may speak in an appropriate gap and say immediately "their name to speak". This will be noted by the Chair who will invite the intervention in due course. To ensure balance, the Chair has the discretion to delay an intervention by a frequent speaker to allow others to speak. By way of guidance for the Chair, a GNSO Council member is not expected to speak for more than three minutes at a time and the Chair should solicit the views of other GNSO members before returning to the same speaker on any one issue. Such discretion should not be exercised for a "point of information". A point of information is for GNSO Council members seeking information from the Chair or other GNSO Council members about meaning or procedure - it is specifically not intended to provide information.
2.5 Seating During in-person meetings, the GNSO Chair should be located so he/she can see all members.
3. GNSO committees and task forces
3.1 The GNSO may form task forces, which may comprise of non-Council members in accordance with Annex A, section 7 of the bylaws. In addition the GNSO Council may form committees from the membership of the GNSO Council. In general committees should be structured according to the principles of task forces (eg ensuring participation from each constituency), although variations are possible with the approval of the full Council.
4. Agendas for GNSO Council meetings
4.1 Objective The chair will aim to post a draft agenda at least 7 days prior to a Council meeting. The agenda will be developed in consultation with the ICANN Staff Manager, taking into account requests for agenda items submitted by Council members. The Agenda will be finalized at the beginning of each GNSO Council meeting.
4.2 Reports and declarations No later than 7 days before the GNSO Council meeting, all reports or proposed declarations relating to forthcoming agenda items should be distributed to the GNSO Council.
5. Apologies
5.1 Any GNSO Council member that cannot attend a GNSO Council meeting must advise the GNSO Secretariat in advance. This allows re-scheduling of a meeting if quorum cannot be achieved.
6. Minutes of GNSO Council meetings
6.1 Within 7 days of a GNSO Council meeting, the GNSO Secretariat will prepare an initial draft of the minutes for review by the GNSO Chair. Following this review, the draft minutes will be posted on the public GNSO Council list for review by the full Council, and also posted to the ICANN Secretary no later than 21 days following the GNSO Council meeting (in accordance with Article X, section 3, paragraph 8). The GNSO Council will approve the minutes at its subsequent meeting for posting on the GNSO Website.
7. Recording of GNSO Council meetings
7.1 GNSO Council meetings will be recorded where possible, and made available for public review.
7.2 Disputes If any GNSO Council member disputes what he or she has said in the resulting draft minutes, a transcript of the relevant portion of the audio recording shall be prepared and made available to the GNSO Council before its formal approval of the minutes.
8. Absences
When a GNSO council member fails to participate in two regular consecutive GNSO meetings without notification of absence to the GNSO secretariat or GNSO chair or Council list, the GNSO secretariat will notify the constituency and ask for a response.
9 Voting within task forces
9.1 From time to time progress will be advanced by holding straw polls to determine the majority view. A motion to approve a draft proposal or report (or any section thereof) may be made by any member of the Task Force. Once seconded and approved by the Task Force Chair, such motion shall be put to a vote of the Task Force members. In such an event, the Task Force Chair shall poll the Working Group members. Motions that receive a majority of votes cast shall be deemed approved. Each task force member shall be entitled to cast one vote, unless otherwise agreed by the GNSO Council.
9.2 Consensus. The results of any vote within a task force will be taken solely to assist with progress within the task force. A majority vote of a task force should be described as a majority vote of a task force. No claim to GNSO consensus should be attributed to such a vote.
9.3 Disputes and role of an interim report
Many conflicts can be resolved by simple votes. The majority view goes forward and is documented in an interim report. However, where in the opinion of the Task Force Chair, there is a significant minority proposal, this proposal should also be documented in the interim report of the Working Group. The interim report should contain:
an abstract of all proposals which achieved a meaningful level of support,
a clear statement of what is being proposed and its underlying rationale,
9.4 Termination
Task Forces will be disbanded automatically on completion of their task or disbanded by the GNSO Council earlier if deadlock is evident.
10. E-mail voting
10.1 The GNSO secretariat will typically act as returning officer for an e-mail vote. All votes using the GNSO secretariat voting software have resource implications. Any vote of the GNSO undertaken by the GNSO secretariat must be requested by the GNSO Council chair.
10.2 The voting period for any vote will ordinarily be 14 calendar days. In exceptional circumstances it may be shorter. A reminder will be sent out two or three days before the end of the vote reminding the registered voters to vote before the close of the vote. The returning officer should confirm receipt of vote back to all voters. If a voter does not receive a receipt within one working day then the onus is on the voter to contact the returning officer and if necessary vote by telephone. Once the vote is closed, the address to which the ballot is sent is no longer valid and an out-of-time vote will be returned to sender. The result of the e-mail vote will be declared as soon as practicable once known.
10.3 GNSO Council e-mail votes. ICANN by-laws X 3(8) requires that GNSO Council members "can speak to and hear one another" for an GNSO Council meeting to be valid. Votes taken by e-mail therefore have to be validated at a subsequent meeting.
10.4 Typically at the meeting of the GNSO Council following an e-mail vote, the Chair will ask for the e-mail vote to be validated by a simple vote of approval to show the will of the GNSO was fairly expressed by the e-mail vote. After such validation the result of the e-mail vote will be an act of the GNSO Council.
10.5 Should there be any technical failure or other anomaly in the e-mail vote, the Chair will ask GNSO Council members at the GNSO Council meeting following an e-mail vote, to reaffirm their original or intended e-mail vote. GNSO Council members cannot change their vote in a reaffirmation vote.
10.6 Under exceptional circumstances which must be described by the Chair and agreed to by the GNSO Council by a two-thirds vote, it may be decided to ignore the e-mail vote and hold a fresh vote at which GNSO Council members may chose to vote differently from their earlier e-mail vote.
11 Statements of Interest
11.1 Article VI, section 6 of the ICANN bylaws requires a Board director to not less frequently than once a year set forth all business and other affiliations which relate in any way to the business and other affiliations of ICANN. In keeping with this principle, GNSO Council members must not less frequently than once a year set forth all business and other affiliations which relate in any way to the business and other affiliations of ICANN.
11.2 Continuous Disclosure. It is recognised that many Council members are direct participants in the gTLD domain name industry, and thus the outcome of a particular policy may have a financial impact on the Council member or an organisation associated with the Council member. However to ensure that the community gains transparency in the factors affecting the decision making of the GNSO Council, each Council member should disclose any relationship or other factor that could reasonably be considered to cause the Council to be considered to be an "interested person" as defined in the ICANN bylaws for Directors with respect to any decision being taken by the GNSO Council. The interest need not exclude the Council member from voting, but the interest should be declared prior to voting.
11.3 Where a GNSO Council member becomes aware of a potential interest of another GNSO Council member that has not been declared, the GNSO Council member should undertake the following steps in order:
(a) Directly remind the relevant GNSO Council member in private of the rules of procedure with respect to statements of interest.
(b) If (a) is not successful, contact the GNSO Council chair in private, and ask the GNSO Council chair to contact the relevant GNSO Council member.
( c) If steps (a) and (b) have been undertaken, and the GNSO Council member is still concerned, then this concern should be reported at a meeting of the GNSO Council, and the relevant GNSO Council member will have the opportunity to respond.
;>BHILUV[B C F X Y ^ c ¢ ©
M
[
`
h
i
l
m
Ë
Ì
Ï
×
"#&-.IX[Ýà"'|Éâæçï%
)
*
3
ü
gt³À6:Þê+Ž¹ñôùüõîõêõêæêâêõêÞêâêâÚêâêõîõêõêâêõêâêõêâêâêÒõêâêÈêâêâêâêâêâêâêâêâêâêâêõêâêõÁõêõh}55\hø]OJQJ^Jho®B*phh3²hëe{ho®hÒ~hø]ho®5\hø]5\hsFL;IC M
i
Ì
#Ý|ŠÉñÅê5ý
Ãçîu~úúúúúúúúúëëëúúúúúúúúúúúúúúú
&F€d€d[$\$gdø]gdø]è1ý{ÄÅÈéêíø4578rÒÙïûý
ÂÃÆæçêëíîþ
tuwxFS~ÕÚ
#>C€pzüøôüíæüíüôüíßüÛüÛüÛüíÔüíüÐüíÉüíüÅüíŸíüíüºüíŸüºüºüíüºüºüºüºüºü³¬³üšhaAh?ý5\haA5\hsU°hsU°5\h%'h%'5\hsFhsF5\hIj»h[š5\h¹#Y5\hø]5\h¹#Yh}5hø]B î0 Ë !!'!°!±!Ã!Ð"%&Ì'ö(*0*ó+/Ü/^0ó0å1úúúúúúëëúúúúúúúúúúúúúúúúæægd€[
&F€d€d[$\$gdø]gdø]z©Úäíîñòý)ak¹ÃÑÕÌ× !!!!'!2!!!°!±!²!³!Â!Ã!Ä!Å!Ç!Í!-"2"z""""Œ"Á"Ð"Ñ"Ò"Ô"%%%% %€%¥%É%Ï%Þ%ë%&üøüøüøüøüðìüøüøèøüøüøüøüøüáÚüèüÐüáÚüèüèüìÉáÉüÉáÉÅüÁüÁüÁüÁüɺÉüɺÉüÁìüÁüÁühc1Ë5\hc1Ëh3²hø]5\hø]OJQJ^Jhëe{5\h?ý5\h?ýhëe{hëe{hëe{5haAhø]I&+&&&&&³&ž&F'K'Ÿ'Ã'Ì'Í'Î'Ð'/(<(K(W(®(Œ(ö(÷(ø(ú(U)a)Ã)Ð)*0*|*N+T+Z,s,~,//æ1ç1è1üøñêñøüøüøüøñêñøüøüøüøñêñøüøüøâüÚüÚÒÚÒÚÒÇÃh1'h€[h€[B*phh€[B*phhc1ËB*phh¬CZhc1Ë5hc1Ë5\hø]5\hø]hc1Ë*å1æ1ç1è1úúøgd€[,1h°. °ÆA!°"°# $ %°°Ä°ÄÄ@@ñÿ@NormalCJ_HaJmH sH tH DA@òÿ¡DDefault Paragraph FontRi@óÿ³RTable Normalö4Ö
l4Öaö(k@ôÿÁ(No List4U@¢ñ4ø] Hyperlink >*phÿR^@Rø]Normal (Web)€d€d[$\$OJQJ^JtH H@Ho®Balloon TextCJOJQJ^JaJè)Bÿÿÿÿ;ICMiÌ#Ý|ŠÉ ñ
Åê5
ý
Ãçîu~ î0Ëê)000000000 0 0 0000000000000000000000 0@ 0j00ì;ICMiÌ#Ý|ŠÉ ñ
Åê5
ý
Ãçîu~ î0Ë'°±ÃÐÌö "0"ó#'Ü'^(ó(å)æ)ç)ê)000000000 0 0 0000000000000000000000 0 0000000000000000000000;ICMiÌ#Ý|ŠÉ ñ
Åê5
ý
Ãçîu~ î0Ë'±ÃÐÌö "0"ó#'Ü'^(ó(å)æ)ç)ê)000000000 0 0 0000000000000000000000 0@ 0jË0jË0jË0jË0jË0ŒjË0jË0jË0@pjË0jË0jË0jË0jË0jË0jË0 jË0 jË0 jË0
0z&è1å1è1 è1ÿÿJ11.11.222.12.22.32.42.533.13.23.33.43.544.14.24.34.44.54.64.755.15.25.35.45.566.16.277.17.27.3891010.110.210.310.410.510.610.710.810.910.1010.1110.1210.1310.1410.1510.1610.1710.181111.111.211.311.411.511.611.711.8121313.113.213.313.413.513.6;ICMiÌ#Ý ñ
ÅÅÅÅÅê5
5
5
5
5
ý
ý
ÂÂÂÂÃçîîuu~€€€€€€€€€€€±±±±±±±±±±±±ÃÐÌö ê)
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHI;ICMiÌ#Ý ñ
ÅÅÅÅÅê5
5
5
5
5
ý
ý
ÂÂÂÂÃçîîuu~€€€€€€€€€€€±±±±±±±±±±±±ÃÐÌö ê)JLÌÐê)WZ€±¿Èöú%2²áùûY
d
þz³ Ã Ö$Ø$''ó(ö(ê)33333333333333333ÌÐê)µ!ZFûÀÿÿÿÿÿÿÿÿÿ€
°ãxoÿÿÿÿÿÿÿÿÿçn{ÿÿÿÿÿÿÿÿÿJí4ÿÿÿÿÿÿÿÿÿ r]*0F ÿÿÿÿÿÿÿÿÿc ü/Dàþ¶ÿÿÿÿÿÿÿÿÿù<%0:Ê\¡ÿÿÿÿÿÿÿÿÿ
H!=6|Ðÿÿÿÿÿÿÿÿÿ`>EAÑn<ÿÿÿÿÿÿÿÿÿP;¡CNãØMÿÿÿÿÿÿÿÿÿh*ÿKJ ÿÿÿÿÿÿÿÿÿ5gQìb©ÿÿÿÿÿÿÿÿÿ³T®pðÿÿÿÿÿÿÿÿÿÌ7TºFŒxÿÿÿÿÿÿÿÿÿ 8óTÐÅØÿÿÿÿÿÿÿÿÿÆWÈ)$ÚÿÿÿÿÿÿÿÿÿkMZê=ìÿÿÿÿÿÿÿÿÿ1GÈ_ŸŒròÿÿÿÿÿÿÿÿÿC&aXÄ6=ÿÿÿÿÿÿÿÿÿ :mÚåühÿÿÿÿÿÿÿÿÿO;zp¢³PÿÿÿÿÿÿÿÿÿÒówŽÛ&GÿÿÿÿÿÿÿÿÿQQznDRÿÿÿÿÿÿÿÿÿzÐìÚ{ÿÿÿÿÿÿÿÿÿÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þ. þÆ ^ `þ.pþÆp^p`þ.@þÆ@^@`þ.þÆ^`þ.àþÆà^à`þ.°þÆ°^°`þ.þÆ^`þ.PþÆP^P`þ.ÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðÐþÆÐ^Ð`þCJOJQJo(·ð þÆ ^ `þCJOJQJo(opþÆp^p`þCJOJQJo(§ð@þÆ@^@`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðàþÆà^à`þCJOJQJo(§ð°þÆ°^°`þCJOJQJo(§ðþÆ^`þCJOJQJo(§ðPþÆP^P`þCJOJQJo(§ðµ!Z :mh*ÿKçnkMZP;¡C5gQÒów€
c ü/Jíù<%0³TÌ7TÆW1GÈ_ r]*QQz
H!=O;zpz`>EA 8óTC&aÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Æ ŸXEzÆ ŸÐÐdd}Æ ŸÐÐddWk Æ ŸÐÐddm2Æ ŸÐÐdd06P3Æ ŸÐÐddEIØ9Æ ŸÐÐddŠ)^@Æ ŸÐÐddHnGÆ ŸÐÐddUxJÆ ŸÐÐdd[6Ò_Æ ŸÐÐdd!aÈqÆ ŸÐÐddgOzÆ ŸÐÐdd<å;sF^2
nÒ~0\ŠÈ®":%1'l3?R3À55}5ñ]:j3>]qE£EM°PUµ@V¹#Y¬CZ€[ø]ëv]6b±uxëe{Ò~aAivu%'£å'€0¥[ši©o®sU°3²Ô·DX·Ij»÷aÅOcÇc1Ë 9Ó4×/àÖ3è¢éé[CðÔ4ôìø?ýÿ@ÍÍ@.ÃÍÍè) @ÿÿUnknownÿÿÿÿÿÿÿÿÿÿÿÿGz ÿTimes New Roman5Symbol3&z ÿArial5&zaÿTahoma?5 z ÿCourier New;Wingdings"qðÐh^{£fj{£fA§#LA§#L!ð ŽŽ24dÓ)Ó)2ðHX)ðÿ?äÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿø]2ÿÿ%Amended (new item 8) 26 February 2001bruce tonkinbruce tonkinl
þÿà
òùOh«+'³Ù0ÈÔìø ,8
Xd
p|ä(Amended (new item 8) 26 February 2001bruce tonkinNormalbruce tonkin8Microsoft Office Word@H'@|[ØGÆ@L£ÚGÆA§#þÿÕÍÕ.+,ù®0hp š°žÀ
ÈúäMelbourne ITLÓ)š&Amended (new item 8) 26 February 2001Title
!þÿÿÿ#$%&'()þÿÿÿ+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZþÿÿÿ\]^_`abþÿÿÿdefghijþÿÿÿýÿÿÿmþÿÿÿþÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿRoot Entryÿÿÿÿÿÿÿÿ ÀF°ÆÆ#ÚGÆoData
ÿÿÿÿÿÿÿÿÿÿÿÿ"1Tableÿÿÿÿ*ÁaWordDocumentÿÿÿÿ.BSummaryInformation(ÿÿÿÿÿÿÿÿÿÿÿÿ[DocumentSummaryInformation8ÿÿÿÿÿÿÿÿcCompObjÿÿÿÿÿÿÿÿÿÿÿÿqÿÿÿÿÿÿÿÿÿÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿþÿ
ÿÿÿÿ ÀFMicrosoft Office Word Document
MSWordDocWord.Document.8ô9²qRoot Entryÿÿÿÿÿÿÿÿ ÀFpÝUÚGÆu@Data
ÿÿÿÿÿÿÿÿÿÿÿÿ"1Tableÿÿÿÿ*ÁaWordDocumentÿÿÿÿ.B
!þÿÿÿ#$%&'()þÿÿÿ+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZþÿÿÿ\]^_`abþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿtýÿÿÿþÿÿÿþÿÿÿþÿÿÿsÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿþÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ° SummaryInformation(ÿÿÿÿÿÿÿÿÿÿÿÿ[DocumentSummaryInformation8ÿÿÿÿÿÿÿÿCompObjÿÿÿÿÿÿÿÿÿÿÿÿqÿÿÿÿÿÿÿÿÿÿÿÿþÿ
ÿÿÿÿ ÀFMicrosoft Office Word Document
MSWordDocWord.Document.8ô9²qþÿÕÍÕ.+,ù®DÕÍÕ.+,ù®\hp š°žÀ
ÈúäMelbourne ITLÓ)š&Amended (new item 8) 26 February 2001Title4 $,
1
0
Hello All,
Below is a draft rules of procedure.
I edited the original Names Council rules of procedure. A red-line
version is attached. I have removed many of the sections that are now
covered in the bylaws to avoid repetition, and also avoid mistakes of
copying and pasting from the bylaws. I have also attempted to update
the procedures to reflect current practice.
I added a new section on Statements of Interest.
I also retained a section about voting in task forces with some minor
edits.
See below for plain text version.
Regards,
Bruce Tonkin
DRAFT v1.0 (15 March 2006) GNSO Council Rules of Procedure
1. GNSO Chair
1.1 Election. The GNSO Council chair will be elected in accordance with
the ICANN bylaws, Article X, Section 3, Paragraph 7. Where possible the
term of the GNSO Council chair will be aligned to end at the next Annual
General Meeting (AGM) of ICANN.
1.2 Meeting schedules. The GNSO Chair will finalise a schedule of
meetings on a quarterly basis. GNSO Council members may request changes
to the schedule which may be agreed upon by the Chair in consultation
with the Council, subject to the minimum period of notice below.
2. Conduct of GNSO meetings
2.1 Meetings will be conducted in accordance with ICANN bylaws, Article
X, Section 3, Paragraph 8.
2.2 Voting will be in accordance with ICANN bylaws, Article X, Section
5, Paragraph 2.
2.3 Quorum. In compliance with by-law Article X 3(8) ), members entitled
to cast a majority of the total number of votes of GNSO Council members
then in office shall constitute a quorum
2.4 Speaking at meetings Both at physical and telephone meetings the
GNSO Chair will recognise three types of intervention in the following
order of priority:
1. A point of order
2. A point of information
3. A normal substantive intervention
At a physical meeting, a GNSO Council member may raise a hand or during
a teleconference an GNSO Council member may speak over the dialogue and
say immediately "point of order". The Chair will suspend discussion and
hear the point. Points of information and normal interventions. At a
physical meeting, an GNSO Council member may raise a hand and wait to be
recognised by the Chair and during a teleconference an GNSO Council
member may speak in an appropriate gap and say immediately "their name
to speak". This will be noted by the Chair who will invite the
intervention in due course. To ensure balance, the Chair has the
discretion to delay an intervention by a frequent speaker to allow
others to speak. By way of guidance for the Chair, a GNSO Council member
is not expected to speak for more than three minutes at a time and the
Chair should solicit the views of other GNSO members before returning to
the same speaker on any one issue. Such discretion should not be
exercised for a "point of information". A point of information is for
GNSO Council members seeking information from the Chair or other GNSO
Council members about meaning or procedure - it is specifically not
intended to provide information.
2.5 Seating During in-person meetings, the GNSO Chair should be located
so he/she can see all members.
3. GNSO committees and task forces
3.1 The GNSO may form task forces, which may comprise of non-Council
members in accordance with Annex A, section 7 of the bylaws. In
addition the GNSO Council may form committees from the membership of the
GNSO Council. In general committees should be structured according to
the principles of task forces (eg ensuring participation from each
constituency), although variations are possible with the approval of the
full Council.
4. Agendas for GNSO Council meetings
4.1 Objective The chair will aim to post a draft agenda at least 7 days
prior to a Council meeting. The agenda will be developed in
consultation with the ICANN Staff Manager, taking into account requests
for agenda items submitted by Council members. The Agenda will be
finalized at the beginning of each GNSO Council meeting.
4.2 Reports and declarations No later than 7 days before the GNSO
Council meeting, all reports or proposed declarations relating to
forthcoming agenda items should be distributed to the GNSO Council.
5. Apologies
5.1 Any GNSO Council member that cannot attend a GNSO Council meeting
must advise the GNSO Secretariat in advance. This allows re-scheduling
of a meeting if quorum cannot be achieved.
6. Minutes of GNSO Council meetings
6.1 Within 7 days of a GNSO Council meeting, the GNSO Secretariat will
prepare an initial draft of the minutes for review by the GNSO Chair.
Following this review, the draft minutes will be posted on the public
GNSO Council list for review by the full Council, and also posted to the
ICANN Secretary no later than 21 days following the GNSO Council meeting
(in accordance with Article X, section 3, paragraph 8). The GNSO
Council will approve the minutes at its subsequent meeting for posting
on the GNSO Website.
7. Recording of GNSO Council meetings
7.1 GNSO Council meetings will be recorded where possible, and made
available for public review.
7.2 Disputes If any GNSO Council member disputes what he or she has said
in the resulting draft minutes, a transcript of the relevant portion of
the audio recording shall be prepared and made available to the GNSO
Council before its formal approval of the minutes.
8. Absences
When a GNSO council member fails to participate in two regular
consecutive GNSO meetings without notification of absence to the GNSO
secretariat or GNSO chair or Council list, the GNSO secretariat will
notify the constituency and ask for a response.
9 Voting within task forces
9.1 From time to time progress will be advanced by holding straw polls
to determine the majority view. A motion to approve a draft proposal or
report (or any section thereof) may be made by any member of the Task
Force. Once seconded and approved by the Task Force Chair, such motion
shall be put to a vote of the Task Force members. In such an event, the
Task Force Chair shall poll the Working Group members. Motions that
receive a majority of votes cast shall be deemed approved. Each task
force member shall be entitled to cast one vote, unless otherwise agreed
by the GNSO Council.
9.2 Consensus. The results of any vote within a task force will be taken
solely to assist with progress within the task force. A majority vote of
a task force should be described as a majority vote of a task force. No
claim to GNSO consensus should be attributed to such a vote.
9.3 Disputes and role of an interim report
Many conflicts can be resolved by simple votes. The majority view goes
forward and is documented in an interim report. However, where in the
opinion of the Task Force Chair, there is a significant minority
proposal, this proposal should also be documented in the interim report
of the Working Group. The interim report should contain:
1. an abstract of all proposals which achieved a meaningful level
of support,
2. a clear statement of what is being proposed and its underlying
rationale,
9.4 Termination
Task Forces will be disbanded automatically on completion of their task
or disbanded by the GNSO Council earlier if deadlock is evident.
10. E-mail voting
10.1 The GNSO secretariat will typically act as returning officer for an
e-mail vote. All votes using the GNSO secretariat voting software have
resource implications. Any vote of the GNSO undertaken by the GNSO
secretariat must be requested by the GNSO Council chair.
10.2 The voting period for any vote will ordinarily be 14 calendar days.
In exceptional circumstances it may be shorter. A reminder will be sent
out two or three days before the end of the vote reminding the
registered voters to vote before the close of the vote. The returning
officer should confirm receipt of vote back to all voters. If a voter
does not receive a receipt within one working day then the onus is on
the voter to contact the returning officer and if necessary vote by
telephone. Once the vote is closed, the address to which the ballot is
sent is no longer valid and an out-of-time vote will be returned to
sender. The result of the e-mail vote will be declared as soon as
practicable once known.
10.3 GNSO Council e-mail votes. ICANN by-laws X 3(8) requires that GNSO
Council members "can speak to and hear one another" for an GNSO Council
meeting to be valid. Votes taken by e-mail therefore have to be
validated at a subsequent meeting.
10.4 Typically at the meeting of the GNSO Council following an e-mail
vote, the Chair will ask for the e-mail vote to be validated by a simple
vote of approval to show the will of the GNSO was fairly expressed by
the e-mail vote. After such validation the result of the e-mail vote
will be an act of the GNSO Council.
10.5 Should there be any technical failure or other anomaly in the
e-mail vote, the Chair will ask GNSO Council members at the GNSO Council
meeting following an e-mail vote, to reaffirm their original or intended
e-mail vote. GNSO Council members cannot change their vote in a
reaffirmation vote.
10.6 Under exceptional circumstances which must be described by the
Chair and agreed to by the GNSO Council by a two-thirds vote, it may be
decided to ignore the e-mail vote and hold a fresh vote at which GNSO
Council members may chose to vote differently from their earlier e-mail
vote.
11 Statements of Interest
11.1 Article VI, section 6 of the ICANN bylaws requires a Board director
to not less frequently than once a year set forth all business and other
affiliations which relate in any way to the business and other
affiliations of ICANN. In keeping with this principle, GNSO Council
members must not less frequently than once a year set forth all business
and other affiliations which relate in any way to the business and other
affiliations of ICANN.
11.2 Continuous Disclosure. It is recognised that many Council members
are direct participants in the gTLD domain name industry, and thus the
outcome of a particular policy may have a financial impact on the
Council member or an organisation associated with the Council member.
However to ensure that the community gains transparency in the factors
affecting the decision making of the GNSO Council, each Council member
should disclose any relationship or other factor that could reasonably
be considered to cause the Council to be considered to be an "interested
person" as defined in the ICANN bylaws for Directors with respect to any
decision being taken by the GNSO Council. The interest need not
exclude the Council member from voting, but the interest should be
declared prior to voting.
11.3 Where a GNSO Council member becomes aware of a potential interest
of another GNSO Council member that has not been declared, the GNSO
Council member should undertake the following steps in order:
(a) Directly remind the relevant GNSO Council member in private of the
rules of procedure with respect to statements of interest.
(b) If (a) is not successful, contact the GNSO Council chair in private,
and ask the GNSO Council chair to contact the relevant GNSO Council
member.
(c) If steps (a) and (b) have been undertaken, and the GNSO Council
member is still concerned, then this concern should be reported at a
meeting of the GNSO Council, and the relevant GNSO Council member will
have the opportunity to respond.
1
0
[To council[at]gnso.icann.org]
Dear All,
Ahead of complete minutes of the GNSO Council teleconference held on 14
March 2006, Council passed the following procedural motion:
The GNSO Council proposed that both the public comment period and the
deadline for the submission of constituency statements for the policy
development process on policies for contractual conditions for
existing gTLDs - PDP-Feb06 - be extended to 30 April 2006.
The motion carried unanimously by voice vote
Absent: Kiyoshi Tsuru, absent and excused: Norbert Klein, June Seo
There were 18 Council members on the call.
--
Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org
1
0