[council] FW: Letter from the GNSO requesting GAC advice on Draft Recommendations for the Introduction of new gTLDs

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

For information - below is a copy of the note that I have sent to the
chair of the GAC with regard to seeking advice on new gTLD policy.

Regards,
Bruce Tonkin 



11 October 2006

Mr Mohamed Sharil Tarmizi
Chair - ICANN Governmental Advisory Committee

Ms Suzanne Sene
Chair - GAC GNSO Working Group One


Dear Mr Tarmizi and Ms Sene,

INTRODUCTION OF NEW TOP LEVEL DOMAINS

I am writing to you to seek your further assistance with the Generic Names 
Supporting Organisation's Policy Development Process on the Introduction of New 
Top Level Domains.   

The GNSO new TLDs Committee would be grateful for a formal response from the 
Governmental Advisory Committee on both the Initial Report 
(http://gnso.icann.org/issues/new-gtlds/issues-report-15jun06.pdf) and the 
Draft Recommendations which resulted from the Committee's consideration of the 
Public Comments received on the recommendations in the Initial Report at the 
Committee's recent Amsterdam meeting.  

I have appended the Draft Recommendations to the end of this letter.  These 
Draft Recommendations only have the status of a Working Document and do not yet 
reflect a formal vote by the GNSO Council.

The GNSO Committee on new TLDs has made significant progress through the policy 
development process.  We expect to produce a Final Report by mid November 2006 
which will formalize the draft Recommendations on each of the Terms of 
Reference, the key areas of which are as follows:

§       whether to continue to introduce new gTLDs;

§       the selection criteria for approving applications for new gTLDs;

§       the allocation methods for choosing new gTLDs; and 

§       the policies for contractual conditions for new gTLDs.

Additionally, Internationalised Domain Names are foreseen as an integral part 
of the introduction of new top level domains, and the GNSO is continuing to 
discuss this issue. 

The GAC will be pleased to note that the Draft Recommendations have been 
derived from a comprehensive series of face-to-face consultations with 
representatives from all the GNSO's Constituencies, input from many individual 
stakeholders and, of course, from our series of discussions with the GAC and 
other groups during ICANN's regular meetings.

The GNSO Committee has focused, in the preparation of its Draft 
Recommendations, very closely on ICANN's Mission and Core Values, particularly 
with respect to cultivating an environment in which competition can flourish, 
ensuring the stability and security of the Internet, and facilitating bottom-up 
policy development processes.

We understand that the GAC GNSO Working Group I is discussing public policy 
principles around the introduction of new top level domains and work is 
ongoing.  

We are keen to maximise opportunities for timely and constructive input into 
the GNSO's policy development process and propose that the following ideas may 
be a constructive way of ensuring effective GAC input:

§       A formal presentation of the draft set of GAC public policy principles 
on the introduction of new top level domains;

§       An invitation for individual governments to submit their comments on 
each area; and

§       An invitation for the GAC to submit a position on the introduction of 
new TLDS using the Final Report as the starting point for those discussions.

The GNSO is particularly interested in receiving advice from the GAC on various 
laws and international agreements or public policy that may impose restrictions 
in the strings (including possible IDN strings) which may be registered at the 
top level.

We welcome additional suggestions to ensure GAC input and are eager to finalize 
these arrangements as soon as possible.  Time is very much of the essence in 
our consultations.  We look forward to discussing this with you in more detail 
and concluding our consultation plans. 

We would greatly appreciate substantive input from the GAC for discussion at 
the ICANN meeting in Sao Paulo to enable further consideration of the GAC's 
advice as the GNSO concludes this Policy Development Process, and produces a 
Board Report for the ICANN Board to consider.

Yours sincerely,



BRUCE TONKIN
Chair of the GNSO Council 

From: http://gnso.icann.org/issues/new-gtlds/recom-summary-14sep06.htm 


WORKING DOCUMENT 14 September 2006

DRAFT GNSO Recommendation Summary

Introduction of New Generic Top-Level Domains

Table of Contents

PRINCIPLES      

RECOMMENDATIONS 

1       WHETHER TO INTRODUCE NEW TOP LEVEL DOMAINS

2       SELECTION CRITERIA

3       ALLOCATION METHODS

4       CONTRACTUAL CONDITIONS

 
Principles
==========

The following Recommendations have been derived from the work of the GNSO 
Committee on the introduction of new top level domains in accordance with the 
Terms of Reference set by the GNSO, with reference to ICANN's Mission and Core 
Values.
 
a) That new generic top level domains (gTLDs) will be introduced in an orderly 
and predictable way.

b) That some new generic top level domains will be internationalised
domain names (IDNs).     IDNs use characters drawn from a large
repertoire (Unicode).   There is a mechanism called Internationalizing
Domain Names in Applications (IDNA) that allows the non-ASCII characters to be 
representing using only the ASCII characters already allowed in so-called host 
names today (see RFC3490).

c) That the principal objective of the introduction of new top level domains is 
to permit market mechanisms to support competition and
consumer choice in the technical management of the DNS.    This
competition will lower costs, promote innovation, and enhance user choice and 
satisfaction.

d) That a set of "technical criteria" for a new gTLD registry applicant 
minimises the risk of harming the operational stability, reliability, security, 
and global interoperability of the Internet.

f) That a set of "business capability criteria" for a new gTLD registry 
applicant provides an assurance that an applicant has the capability to meet 
its business ambitions.


Recommendations
===============

1       Whether to introduce new top level domains
================================================

1.1     Additional new generic top-level domains should be introduced
and work should proceed to enable the introduction of new generic top level 
domains, taking into account the recommendations found in the following 
sections.


2       Selection Criteria
========================

2.1     The process for introducing new top level domains will follow a
pre-published application system including the levying of an application fee to 
recover the costs of the application process.  The application process will 
also include probity rules and clear timelines.

2.2     Application fees will be set at the start of the process and
application materials will be available prior to any application round.
Some applications may cost different amounts to evaluate.  Therefore, different 
fees may be levied depending on what stage in the process the
application reaches.   If applicants find the application fee a barrier
to entry, ICANN could have a system of grants to assist applicants.
This grant would only allow the applicant to apply, without any presumption 
that the application would be successful.  Grant
applications would go through an evaluation process.    ICANN should
evaluate options for funding the grants.

2.3     Technical criteria will include compliance with a minimum set of
technical standards that would include IETF Requests for Comment related
to the operation of the DNS and other technical standards.    Standards
may include RFC3730-3735, RFC2246, RFC1035, RFC2181, RFC2182, and the ICANN 
Guidelines for the Implementation of Internationalized Domain Names.

2.4     Applicants must comply with all ICANN consensus policies as and
when they are developed.

2.5     Applicants must choose a string of characters for the new
generic top level domain name that complies with the process for string
checks below.    


2.5.1   ICANN will use the following process for TLD string checks.
----------------------------------------------------------------

2.5.1.1 ICANN will make a preliminary determination on whether the application 
complies with the string requirements and may seek expert advice in order to 
make its preliminary determination.

2.5.1.2 ICANN will establish public comment processes (which may include input 
from governments or the Governmental Advisory Committee) that are specific to 
the criteria for the new string.

2.5.1.3 In the event that ICANN reasonably believes that the application for a 
particular string may not be compliant with the string requirements, ICANN will 
refer the issue to a panel of experts with appropriate backgrounds.


2.5.2   String Criteria
---------------------

2.5.2.1 The gTLD string should not be confusingly similar to an existing TLD 
string.  Confusingly similar means there is a likelihood of confusion on the 
part of the relevant public.  

2.5.2.2 The string must not infringe the legal rights of any third party 
(consistent with the current requirements of Registered Name Holders - see 
Clause 3.7.7.9 of the gTLD Registrar Accreditation Agreement).

2.5.2.3 The string should not cause any technical issues, for example, 
.localhost and .exe would be unacceptable name strings.

2.5.2.4 The string should not be in conflict with national or international 
laws or cause conflicts with public policy [for example, controversial, 
political, cultural religious terms].  (Develop text related to public policy 
issues with GAC assistance).

2.5.2.5 The string should not be a reserved word  (for example, RFC2606).


2.5.3   Dispute resolution with respect to ICANN accepting a new string.
----------------------------------------------------------------------

2.5.3.1 ICANN must establish a dispute resolution process, using independent 
arbitrators, where existing registry operators could challenge a decision made 
by ICANN regarding whether a new gTLD string is confusingly similar to an 
existing gTLD string.  If a string application is successfully challenged as 
being confusingly similar, then no other operator may subsequently apply for it.

2.5.3.2 ICANN may establish a new dispute resolution process, using independent 
arbitrators, where existing trademark holders could challenge an ICANN decision 
regarding a string.  This new dispute resolution process would be modeled on 
use existing Uniform Domain-Name Dispute Resolution Processes (UDRP).


2.6     An applicant for a new gTLD must use ICANN accredited registrars
to provide registration services to Registered Name Holders (registrants).  The 
registry shall not act as a registrar with respect to the TLD (consistent with 
the current registry-registrar structural separation requirements, for example, 
see clause 7.1 (b) and (c) of the
.jobs registry agreement).    An organization wishing to become a
registrar for a new gTLD would need to become accredited using ICANN's existing 
accreditation process. 
 
2.7     An applicant must demonstrate that they have the capability to
operate a new gTLD that meets the minimum technical criteria to preserve the 
operational stability, reliability, security, and global
interoperability of the Internet.   

2.8     The applicant must provide a financial and business plan that
provides an assurance that the applicant has the capability to meets its 
business ambitions. 


3       Allocation Methods
========================

3.1     To ensure an orderly introduction of new TLDs, the applications
should be accessed in rounds to allow issues of contention between applicants 
for the same string to be resolved.  First come first served
(FCFS) is the preferred method of assessing applications within an initial 
round.  Subsequently, processes may be developed that would enable an "apply as 
you go" system.

3.1.1   The start date for the round should be at least four months
after the ICANN Board has issued the Request for Applications.  ICANN must 
promote the opening time and details of the new round of applications to the 
broader worldwide Internet community.

3.1.2   Applications will be date stamped as they are received and will
form a queue with the ability to work on multiple applications in parallel.

3.1.3   The closing date for the first round of new applications should
be at least thirty days after the start date.  

3.1.4   Applications for strings are not published until after the
closing date.


3.2     The following process should be used to resolve contention
between multiple applicants for the same new gTLD.

3.2.1   Ensure each application for the same gTLD (or a set of gTLDs
that may be considered to be confusingly similar) is compliant with the 
selection criteria (with some flexibility to correct minor application form 
errors).

3.2.2   Establish a timeframe for a mediation process amongst the
applicants to identify a solution amongst competing applications.   A
possible solution is for the applicants to choose different TLD strings to 
avoid the conflict, or for the applicants to combine their resources.


3.2.3   If there is no agreement between the applicants, ICANN will
evaluate the additional criteria of the level of support of the community of 
potential registrants within that TLD to resolve
contention.   Both applicants would have a timeframe (e.g 90 days) to
supply this additional material for evaluation.   ICANN will determine
what evidence is acceptable, and the evidence must be measurable and
verifiable.     An applicant that is not successful will need to wait
until the next application round to submit a new application.

3.2.4   If ICANN staff are unable to distinguish between the level of
support for each applicant for the gTLD, then the Board will make a choice 
based on the ICANN Mission and Core Values which include introducing and 
promoting competition in the registration of domain names where practicable and 
beneficial in the public interest; and supporting the functional, geographic 
and cultural diversity of the
Internet.    An applicant that is not successful will need to wait until
the next application round to submit a new application.

3.3     An applicant who is granted a gTLD string has an obligation to
begin using it within an appropriate time-frame.


4       Contractual Conditions
=============================

4.1     There should be a frame agreement to provide some level of
consistency (for example, as for the registrars accreditation agreement) 
amongst gTLD agreements, with the ability for staff to have delegated
authority to approve.   Any material alterations to the frame agreement,
will be subject to public comments before approval by the ICANN Board.

4.2     The contract should strike the right balance between ensuring
certainty for market players and preserving flexibility of ICANN to accommodate 
the rapidly changing market, technological and policy conditions.

4.3     The initial term of the new gTLD agreement should be of
commercially reasonable length (for example, default 10 years, although may be 
changed on a case-by-case basis).

4.4     There should be renewal expectancy.  A contract would be renewed
provided that the license holder is not in material breach of the contract, or 
has not been found in repeated non-performance of the contract, and provided 
the license holder agrees to the any new
framework contract conditions that are reasonably acceptable.    Any new
framework contract would take into account the consensus policies in place at 
that time.

4.5     There should be a clear sanctions process outlined within the
frame agreement to terminate a contract if the new gTLD operator has been found 
in repeated non-performance of the contract.

4.6     During the term of the agreement, the registry must comply with
new or changed consensus policies to one or more of the following areas:

-       (1) issues for which uniform or coordinated resolution is
reasonably necessary to facilitate interoperability, security and/or stability 
of the Internet or DNS; 

-       (2) functional and performance specifications for the provision
of Registry Services (as defined in Section 3.1(d)(iii) below); 

-       (3) security and stability of the registry database for the TLD;


-       (4) registry policies reasonably necessary to implement
Consensus Policies relating to registry operations or registrars; 

-       or (5) resolution of disputes regarding the registration of
domain names (as opposed to the use of such domain names). 

4.7     Any deviation from consensus policies should be explicitly
stated and justified in the agreement.

4.8     Where a registry provides IDNs, the contract should require that
the registry adhere to IDN standards, and ICANN guidelines for IDNs.

4.9     Initially rely on the appropriate external
competition/anti-trust Government authorities to ensure compliance with
laws relating to market power or pricing power.   This can be reviewed
after an initial term.

4.10    ICANN should take a consistent approach with respect to registry
fees - taking into account differences in regional, economic and business models

4.11    Use of Personal Data: limit it to the purpose for which it is
collected, and the registry operator must define the extent to which it is made 
available to third parties.