ICANN/GNSO GNSO Email List Archives

[registrars]


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

[registrars] Terms of reference for PDP-Feb06

  • To: <registrars@xxxxxxxxxxxxxx>
  • Subject: [registrars] Terms of reference for PDP-Feb06
  • From: "Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
  • Date: Fri, 3 Mar 2006 13:32:27 +1100
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • Thread-index: AcY+ara5h0vtqd0OTa65GkWx4UmfhQ==
  • Thread-topic: Terms of reference for PDP-Feb06

Hello All,

The following terms of reference was approved by the GNSO Council today.

Regards,
Bruce Tonkin


Terms of Reference for PDP-Feb06

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.





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