ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] Progress on new gTLDs


Hi,

Thanks for the overview and proposed plan.

I have some embedded questions and initial comments.

On 15 aug 2005, at 06.15, Bruce Tonkin wrote:


There seem to be two main threads in the decisions.

The first thread is as follows:
- the Names Council/GNSO support introducing new TLDs, but requests that
the ICANN community first start with a proof of concept, and evaluate
the outcome of that proof of concept, before moving ahead with the
introduction of more TLDs
- The ICANN Board authorises a proof-of-concept round, and then a
further extension of that proof-of-concept for additional sponsored TLDs
- the evaluation of the first phase of the proof-of-concept was
completed in July 2004


Was the pointer to this evaluation included in Olof's report. I don't remember seeing it? Who did the evaluation? And who approved it?




The second thread starts around Dec 2002, and assumes that new TLDS will
be created:
- The GNSO Council is asked by the Board whether to structure the
evolution of the generic top-level namespace
- the GNSO responds that interested parties should be free to propose
names and the process should be market driven (ie the market decides
what new names to add).
- the GNSO recommends that a Policy Development Process be used to
establish a set of objective criteria for new TLDs
- in October 2003, the Board asks the ICANN staff to come up with the
process for addiing new TLDs
- subsequently the staff have produced a report detailing the input
necessary to develop the process, and also created a set of questions
that need to be addressed

The Council has not been actively involved since 2003.



Other then the recommendation that is should be bottom up and user driven, a good idea, has the council made done any work on the structure of evolving namespace?

Also, while defining a structured namespace and allowing bottom up user driven process may seem to be contradiction, it does seem reasonable that the bottom up process be constrained to some minimal structure.



I believe that we first need to complete the first thread:
- ie should we continue to introduce new TLDs based on the outcomes of
the proof-of-concpet round?
(to answer this question we should review the original reasons
for/against introducing new TLDs, allow a short comment period for other
(or new) reasons for/against to be supplied, review the output of the
evaluation)

With respect to the second thread, it is clear that the GNSO intended
that interested parties be able to submit proposed names.   I think we
should focus first on developing an objective criteria for new
applications.



This seems like a good approach.


In parallel we could look at the question of how many
new TLDs (and whether to introduce them in phases).


I understand there are operational constraints on how many could be introduced at a time. But I don't have this information. Is this info avaialble, or does someone need to research that operational constraint.


If the outcome is
that only a limited number of new TLDs can be introduced at a time -



Seems almost certain that it would be. No matter how big the limit, there are organizational scalability issues that would prevent too many from happening, in a controlled and stable manner, in any given unit of time.


then we need to consider how they will be allocated (e.g ballot,
auction, first-come first served).


If we define criteria for a successful application, then it seems reasonable to take them on a first come, first served as long as it meets criteria. Using a ballot, leaves the selection open to subjective and interest driven decisions.

As for an auction, this might be a good idea if the proceeds were to be used for appropriate charitable purposes, such as capacity building and education. But it might prevent the less well heeled from obtaining TLDs. I am personally uncomfortable with only granting new TLDs to the richest applicants.


a.




<<< Chronological Index >>>    <<< Thread Index >>>