I
concur with Jordyn's analysis below of the question from the ICANN
Board.
I
think the question was quite narrowly framed.
Either
let the market choose names, or use a structure:
e.g 7
deadly sins (sloth, greed etc), 7 dwarfs, 26 (one for each letter in the
alphabet etc), some sort of ISO table (in addition to the country code table),
olympic sports as chosen by the IOC
We of
course can initiate our own separate policy development process on any element
of new TLD policy. This should be done via generating an issues report and
following the GNSO policy development process described in:
Regards,
Bruce
Philip:
You
are confusing two questions. The underlying question that must be
answered is "what did the board mean by their use of the word
'structure'"? Having determined that, I agree wholeheartedly that the
Names Council has full authority to
As I
indicated on the last call, I believe that the Board has asked quite a narrow
question of us. I think there was some agreement on the call that the
board meant "structure" in the context of Stuart's paper on gTLD
expansion. Here, then, is the relevant excerpt:
---------------------------------------
Since well before ICANN's new TLD process in 2000, there has been
discussion about the best way to address the semantic element of new TLD
creation.
Some have argued that the best approach is to allow each would-be TLD
registry operator to select which new TLD string(s) it wishes to operate (on
the basis of its own analysis, market research and/or reference to the
intended community to be served), with little or no editorial role for ICANN
in selecting new TLD proposals. This is the approach ICANN took in 2000: each
proposer was asked to specify the TLD string(s) it wanted, including an
explanation of its rationale and, for sponsored TLD proposals, the
relationship of the string to the intended community to be served and to any
restrictions or limitations on registration.
Others have argued that the ICANN community should undertake to
"rationalize" the new TLD space according to a defined taxonomy of names. This
is the approach that was taken when the Domain Name System was first designed
and deployed in the mid-1980s. [See RFC 1034, RFC 1035, RFC 1591]. RFC 1591
documented post-hoc the initial taxonomy decisions, which established seven
three-letter "generic" top-level domains (EDU, COM, NET, ORG, GOV, MIL, and
INT) and an expandable number of "country-code" top-level domains, drawn from
the ISO 3166-1 table. In other words, the initial architects of the DNS made a
collective judgment about the best taxonomic structure for the DNS, which the
IANA then implemented by identifying registry operators for each generic and
country-code TLD and delegating registry authority, according to the policies
documented in RFC 1591.
There are any number of pros and cons to each of these approaches:
- The laissez-faire approach puts responsibility for TLD string selection
in the hands of those who are arguably in the best position to make
market-driven or community-driven judgments – the potential registry
operators. For example, the proposer of .museum was arguably in the best
position to determine which particular string of letters would be most
acceptable to the global community of museums, which spans a vast range of
cultures and languages.
- On the other hand, the laissez-faire approach may result in a DNS that
is confused and confusing, undermining the basic objective that domain
names should be easy-to-remember pointers to the IP addresses that
identify nodes, services, and links on the Internet.
- The taxonomic approach would allow the broad community of ICANN
stakeholders the ability to participate in designing a rational and
comprehensive set of available TLD strings, with the objective of
articulating a system with the greatest utility for all Internet users. This
approach would be arguably most likely to result in a coherent system of
easy-to-remember TLD strings that make sense to users.
- On the other hand, the taxonomic approach would require ICANN to
undertake the doubtless difficult, contentious, and time-consuming process
of creating a global consensus around a particular list of TLD strings. It
could interpose that process between now and the start of ICANN's next
round of new TLDs selection.
Paragraph
II.C 8 of the Amendment to the Memorandum of Understanding between ICANN
and the United States Department of Commerce signed in September, 2002 states
that ICANN should "Continue the process of implementing new top level domains
(TLDs), which process shall include consideration and evaluation
of . . . (b) The creation and implementation of selection
criteria for new and existing TLD registries, including public explanation of
the process, selection criteria, and the rationale for selection decisions."
The need to understand how the top level TLD namespace should be expanded is
indeed a prerequisite to defining such "selection criteria".
Recommendation: As ICANN proceeds with its new TLD evaluation
process – and, if the Board concurs, with an additional round of new
sponsored TLDs – this basic question of taxonomic rationalization should
be addressed within the ICANN process. Accordingly, it is my recommendation to
the ICANN Board that the DNSO and its Names Council be requested to develop
and submit its advice and guidance on the issue.
-----------------
As
you can see, in this context, the question of structure is purely a taxonomic
one, essentially posing the question "should the list of available gTLD
strings be set in advance or established by new gTLD applicants" and is
explicitly distinct from selection criteria and process.
If
we are to diverge from this interpretation, I think the onus is to clearly
enunciate both the new definition of structure that we are using for the
purpose of our inquiry AND the reasons why we are diverging from the
interpretation laid out above.
Jordyn
-----Original
Message----- From: Philip Sheppard [mailto:philip.sheppard@xxxxxx]
Sent: Thursday, February 13, 2003 10:40 AM To: Council
(list); Denise Michel Subject: [council] Conclusions of gTLDs
committee 6 Feb 2003
Jordyn,
you correctly identify a key question facing the
committee. It is certainly our job to define and describe a structure that
we support. This is not a task for the staff. In essence it is the
question the Board has rightly deferred to the GNSO to answer.
Let the proposal flow!
Philip
|