ICANN/GNSO GNSO Email List Archives

[ga]


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

[ga] GNSO Council gTLDS committee report

  • To: ga@xxxxxxxxxxxxxx
  • Subject: [ga] GNSO Council gTLDS committee report
  • From: Danny Younger <dannyyounger@xxxxxxxxx>
  • Date: Wed, 21 Dec 2005 07:30:42 -0800 (PST)
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pwjGgqHikY6+ltFXHahObJn2FTTI8ULrLU/uUR0F1MbpfFoPf2RrKpVOp95A2uimS+HDxFhKIGIJCtfrCvKn0DFwTAjTlMlwT9uUoBe9SiXlmrU+LF67FK48QpbNW6th/FyGb6oeSNGhMhziMR0Vl3ACNzJUhElR2VXjcRA/r/c= ;
  • Sender: owner-ga@xxxxxxxxxxxxxx

In early 2003, the GNSO Council offered some guidance
to the Board on the topic of namespace expansion --
basically a response to the Board's request to examine
the issue of a taxonomic approach.  Their final report
is here:  
http://www.dnso.org/dnso/notes/20030410.gTLD.committee.conclusions-v3.html

I am listing their recommendations below for
reference:

1. Future expansion should increase the level of
competition.  

2. Future expansion should avoid names that are
confusingly similar so as to avoid confusing net
users.  

3. Future names could be in any language, subject to
the technical recommendations coming out of the
existing work on internationalized domain names (IDN).
A significant limiting factor is the stability of the
namespace. In respect to IDN gTLDs (ie IDN.IDN) ICANN
should ensure that the ASCII translation or
transliteration of any new IDN gTLD should not be
confusingly similar to an existing generic ASCII gTLD
or vice-versa, so as to avoid confusing net users.  

4. New names that were IDN translations or
transliterations of an existing gTLD or vice-versa,
should be obliged to follow the same policies and
practices of the original gTLD. In particular, where
the sponsoring organization for a sponsored TLD feels
that its target community would be well served by new
names that are IDN translations or transliterations of
the existing sponsored gTLD, these may be permitted
with the explicit consent of that sponsoring
organization. Any such new domains must, at the least,
be obliged to follow the policies of the original
sponsored gTLD. (It may be noted that these policies
will likely require modification to accommodate their
implementation in multiple languages).  

5. Future expansion should avoid names that might
deceive or defraud net users.  

6. Future names should be both for commercial and
non-commercial purposes.
 
7. Expansion of the gTLD namespace should be a
bottom-up approach with names proposed by the
interested parties to ICANN. There is no support for a
pre-determined list of new names that putative
registries would bid for. Expansion should be
demand-driven. It should be sufficient that a viable
demand is perceived by the name applicant and no
objective test should be required.   

8. Registries could operate multiple gTLDs.  A single
registry need not be linked uniquely with one name.
However, in order to meet the goal on competition,
this flexibility will need to be limited to the extent
that it might lead to market dominance in the supply
of registry services. A judgement on dominance needs
to be well balanced: ICANN should not needlessly set
barriers to entry for new applicants by restricting
their choice of business partners, nor needlessly
prevent new applicants benefiting from any economies
of scale resulting from multiple TLD registries.   

9. To the extent that a TLD is sponsored, sponsors
would typically sponsor a single gTLD, though it
should be possible for a sponsor to sponsor additional
names where the nature of the sponsored space is
complimentary. 

10. Registries should be required as at present to
demonstrate technical and financial competence during
the contract-negotiation stage with ICANN. This
demonstration should not be a significant barrier to
entry. Financial competence will need to be
demonstrated in context relevant to the specific
business model and proposed size of the gTLD.  A
performance bond may be an elegant solution for ICANN:
it in effect devolves the judgement on financial
competence to a third party while providing the
required reassurance. 

11. The application fee for future applications for
names should discourage spurious applicants, but
should also not penalize losers beyond the actual
administrative costs borne by the ICANN secretariat.

12. The investment made by registrants in their name
should be protected from the consequences of registry
failure. It may be sufficient that ICANN maintains the
ability to itself swiftly transfer the relevant TLD
zone file from the failed registry to another
registry.

13. There need to be rules to determine the conditions
under which such a transfer would take place.

14. There is wide but not universal support for what
was termed variously segmentation, differentiation,
and value added. It was generally agreed that given
the objective of a demand-driven bottom-up space,
ICANN need not be in a position to have to judge
differentiation beyond the obvious. If a new
registry/sponsor proposed a name and promised
differentiation, that should be sufficient to award
the name. Whether the applicant subsequently succeeded
in achieving true differentiation would be a function
of the success of its business model.

15. To some extent the concept of segmentation and
differentiation logically lead to support for
sponsored names ? a process which self-determines a
segment or differentiated space where the sponsor
wishes to be.  Expansion of the name space of only
sponsored gTLDs was supported by the Business
Constituency and the Intellectual Property
Constituency.  The non-commercial constituency
supports a model with both sponsored and unsponsored
names possible: conflicts over names would be
determined by price in an auction process. (There was
no support from other constituencies to the auction
model.)


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



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