Abstract

name="_Toc38689898">
name="_Toc34982486">This
is the Task Force Report for the Generic Names Supporting Organisation's policy
development process on Policies for Contractual Conditions: Existing Registries (PDPFeb06).

name="_Toc38689899">
name="_Toc34982487">Document
Status

name="_Toc37822844">10 April 2007: Task Force Report for GNSO Council. This report is the completed Task Force
Report which has been subjected to a public comment period and final review by
the Task Force and will now be forwarded to the GNSO Council for consideration
at its May 2007 meeting.

TABLE OF CONTENTS

Glossary.............................................................................................................................

Acknowledgments.......................................................................................................

1. Introduction.............................................................................................................

2. Recommendation
Summary...............................................................................

3. Term
of Reference 1A: Registry agreement
renewal...............

4. Term
of Reference 1B: Registry agreement
renewal standardization

5. Term
of Reference 2A: Relationship between
registry agreements and consensus policies...................................................................................................

6. Term
of Reference 2B: Relationship between
registry agreements and consensus policies and delegation of responsibility
style='mso-bidi-font-style:normal'>.....................

7. Term
of Reference 3: Policy for price controls for registry services

8.Term of Reference 4: ICANN fees..................................................................

9. Term of Reference 5: Uses of
Registry Data......................................

10. Term
of Reference 6: Investment in
development and infrastructure

11. Public
Comments...............................................................................................

Annex One - Recommendation Summary Chart........................................

Annex Two - Policy Development Process Background Information

Annex Three -- Participation Data....................................................................

Annex Four -- Constituency Statements and Rapporteur Group Input

References....................................................................................................................

clear=all style='page-break-before:always'>

name="_Toc38689901">Glossary

style='border-collapse:collapse;border:none;mso-border-alt:solid windowtext .75pt;
mso-yfti-tbllook:191;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;mso-border-insideh:
.75pt solid windowtext;mso-border-insidev:.75pt solid windowtext'>

Commercial
& Business Users Constituency

CBUC

Intellectual
Property Constituency

IPC

Internet
Service & Connection Providers Constituency

ISPCP

style='mso-yfti-irow:3 !msorm'>

Nominating
Committee

NomCom

Non-Commercial
Users Constituency

NCUC

style='mso-yfti-irow:5 !msorm'>

Policy
Development Process - see
href="http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA">http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA for full
explanation

PDP

style='mso-yfti-irow:6 !msorm'>

Rapporteur
Group

Registrar Constituency

Registry
Constituency

RyC

name="_Toc156718116">

name="_Toc36877690">Acknowledgments

name="_Toc37822847">This document was produced as a result of the
consultations of the PDP Feb 06 Task Force.
The full record of the group's work is found at
href="http://gnso.icann.org/issues/gtld-policies/">http://gnso.icann.org/issues/gtld-policies/ and the mailing list archives at
href="http://forum.icann.org/lists/pdp-pcceg-feb06/">http://forum.icann.org/lists/pdp-pcceg-feb06/.

name="_Toc37822848">Meetings have been open to observers and
remote participation in meetings has been made available. For full information on participation,
consult the charts found in Annex Three.
The full list of Rapporteur Group input is found, along with
Constituency Statements in Annex Four. A
full list of references used to inform the Report is found within the Reference
section at the end of the document.

style='page-break-before:always'>

name="_Toc156718010">
name="_Toc36877693">
name="_Toc157837021">1. Introduction

1.1 This
is the Task Force Report for the
Policies for Contractual Conditions for Existing Registries policy development
process (PDPFeb06). The final draft of
the Task Force Report was discussed at the March 2007 ICANN meeting in Portugal
whilst a twenty day public comment period was conducted
style='mso-footnote-id:ftn1' href="#_ftn1" name="_ftnref1" title="">[1]. The public comment period ended on 28 March
2007, during the ICANN meeting. A final
Task Force meeting was held on April 19 2007 to approve the Report. A one week email voting period began on April
20 2007 to confirm the Report's accuracy before sending the Report to the GNSO
Council for review.

1.2 The work of the Task Force was guided by
Section 7 of the ICANN GNSO policy development process
style='mso-footnote-id:ftn2' href="#_ftn2" name="_ftnref2" title="">[2]. This
Report reflects comprehensive information gathering, including the preparation
of Expert Materials
style='mso-footnote-id:ftn3' href="#_ftn3" name="_ftnref3" title="">[3] by ICANN Staff and the use of two Task
Force Rapporteur Groups
style='mso-footnote-id:ftn4' href="#_ftn4" name="_ftnref4" title="">[4] (RG) that examined separate streams of work
for presentation to the Task Force as a whole.

1.3 The following sections set out the proposed
policy recommendations and identify the level of support for each of the
recommendations. The Task Force, in the
course of its work, used measures of support rather than specific voting. Strong support for a recommendation was
measured by four out of six constituencies supporting a recommendation with
some NomCom support which equated to a supermajority position. Support from three constituencies with some
NomCom support was termed medium support.
Support from fewer than three constituencies is termed weak
support. In a Task Force a supermajority
vote has a specific meaning within the policy development process. A supermajority vote "means a vote of more
than sixty-six (66) percent of the members present at a meeting of the
applicable body."
style='mso-footnote-id:ftn5' href="#_ftn5" name="_ftnref5" title="">[5]

1.4 The RyC has, throughout the policy
development process, expressed its opposition to the Terms of Reference, to the
potential applicability of any of the proposed policy recommendations and to
the work of the Task Force as whole.
style='mso-comment-reference:LW_1;mso-comment-date:20070224T2007'>
class=msocomanchor id="_anchor_1"
onmouseover="msoCommentShow('_anchor_1','_com_1')"
onmouseout="msoCommentHide('_com_1')" href="#_msocom_1" language=JavaScript
name="_msoanchor_1">[LW1] The Registry Constituency (RyC), prior to the
commencement of the formal PDP proceedings, issued a statement and a preface to
that statement which set out its objections to the process
style='mso-footnote-id:ftn6' href="#_ftn6" name="_ftnref6" title="">[6]. The
RyC issued a further statement on 27 April 2006 setting out its ongoing
objection to the Task Force's work
style='mso-footnote-id:ftn7' href="#_ftn7" name="_ftnref7" title="">[7]. On
3 January 2007, the RyC sent in a formal response to the straw poll
recommendations that are listed below
style='mso-footnote-id:ftn8' href="#_ftn8" name="_ftnref8" title="">[8]. On
27 March 2007, the RyC sent final comments to the public comment archive and to
the Task Force mailing list
style='mso-footnote-id:ftn9' href="#_ftn9" name="_ftnref9" title="">[9].

1.5 GNSO Council Chair Bruce Tonkin, in a
message to the PDP Feb06 mailing list reaffirmed the sequence of events as
follows "…The
creation of the PDP was a decision taken by supermajority vote of the GNSO
Council, under Annex A, section 3(c) of the bylaws. The use of a task force and their terms of
reference of the task force is a decision of the
Council taken in accordance with Annex A, section 4 of the bylaws. The outcomes of the task force would need to
be considered by the Council, before voting to approve any recommendations for
the ICANN Board. The ICANN Board would
then need to vote to approve any recommendations as policy, taking into account
public comment, and any legal advice it may receive, along with advice from
GAC, ALAC, SSAC, etc. Then the terms of
existing contracts would affect whether any new ICANN policies were
implementable. The contracts have
various terms to resolve disputes, and ultimately a legal court could be used
to resolve any disputes."
style='mso-footnote-id:ftn10' href="#_ftn10" name="_ftnref10" title="">[10]

1.6 From a procedural perspective the Task
Force's work record is contained in Annex Two.
This includes the establishment of the Task Force and its work
plan. The work plan was modified at a
number of points throughout the process.
Chair (Maureen Cubberley) and the replacement Chair (Avri Doria)
notified the GNSO Council of the changes.
Section E of the GNSO Policy Development Guidelines
style='mso-footnote-id:ftn11' href="#_ftn11" name="_ftnref11" title="">[11] has some specific requirements for the Task
Force Report. In particular, the "e.
Task Force Report.
… Within five (5) calendar days after the final task force meeting, the chair
of the task force and the Staff Manager shall create the final task force
report (the "Task Force Report") and post it on the Comment Site.
Each Task Force Report must include:

1. A clear statement of any Supermajority
Vote position of the task force on the issue;

2. If a Supermajority Vote was not reached, a
clear statement of all positions espoused by task force members submitted
within the twenty-day timeline for submission of constituency reports. Each
statement should clearly indicate (i) the reasons underlying the position and
(ii) the constituency(ies) that held the position;

3. An analysis of how the issue would affect
each constituency of the task force, including any financial impact on the
constituency;

4. An analysis of the period of time that
would likely be necessary to implement the policy; and

5. The advice of any outside advisors
appointed to the task force by the Council, accompanied by a detailed statement
of the advisors' (i) qualifications and relevant experience; and (ii) potential
conflicts of interest.

1.7 The Report includes a clear statement of the
level of support that each recommendation received. Constituency Statements and
Rapporteur Group inputs are found in Annex Four. Constituencies did not provide any analysis
of how the issues contained here would affect each constituency nor did they
provide any financial impact statements.
With respect to Section 4, no analysis was made by the Task Force
members about the period of time necessary to implement policy. In effect, most of the policy recommendations
reflect the status quo or are requests for further work to be done, either by
the ICANN Board or the Stability and Security Advisory Committee (SSAC).

1.8 The following table sets the Constituency
representatives that voted on the recommendations. The Chair will send the Report to the Council
on completion of the voting.

style='margin-left:27.85pt;border-collapse:collapse;border:none;mso-border-alt:
solid windowtext .5pt;mso-yfti-tbllook:191;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;
mso-border-insideh:.5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>

Constituency

Task Force Members

Constituency

Task Force Members

CBUC

Marilyn Cade, Philip Sheppard & Alistair Dixon

NCUC

Mawaki Chango, Milton Mueller & Danny Younger

ISPCP

Greg Ruth, Tony Holmes & Tony Harris

Jon Nevett, Jeff Eckhaus & Ross Rader

IPC

Ute Decker, Kristina Rosette, Steve Metalitz

RyC

Ken Stubbs, David Maher & Cary Karp

NomCom

Avri Doria, Sophia Bekele

ALAC

Alan Greenberg

style='page-break-before:always'>

name="_Toc36877694">2. Recommendation
Summary

2.1 The
first table in this section sets out the recommendations which have majority
support. As set out above this is
measured as having the support of four or more Constituencies (with some NomCom
support) within each Term of Reference.
The recommendations and the variations that were discussed by the Task
Force are set out in full in the following sections. Support from non-voting NomCom and ALAC
members are not included here but are referenced in each of the sections
below. Note that there are two
references on the Recommendations. The
first relates to the Term of Reference; the second relates to a Recommendation
within the Term of Reference as there were multiple recommendations within each
Term of Reference. The votes are found
in full in Annex One with a legend which explains the table.

2.2 The
second table sets out the remainder of the proposed recommendations and
identifies those that supported that particular text. These recommendations did not reach majority
support.

style='margin-left:40.05pt;border-collapse:collapse;border:none;mso-border-alt:
solid windowtext 1.5pt;mso-yfti-tbllook:191;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;
mso-border-insideh:1.5pt solid windowtext;mso-border-insidev:1.5pt solid windowtext'>

name="_Toc37822851">Majority
Supported Recommendations

There should be a policy guiding registry agreement
renewal. (TOR 1: Rec 1A.1)

style='mso-bidi-font-style:normal'>

The initial term of Registry agreements should be
for a commercially reasonable length. (TOR1: Rec 1A.2)

There was majority support for the concept
of a re-bid of registry contracts but there are differing opinions as to the
conditions under which re-bids would occur. (TOR 1: Rec 1C)

name="_Toc37822852">The present limitations to Consensus Policies are
appropriate and should continue.
(TOR 2: Rec 2A)

name="_Toc37822853">Certain policy making responsibility should be delegated
to the sponsored gTLD operators.
(TOR2: Rec 2B)

name="_Toc37822854">In order to improve ICANN accountability and effective
business planning by registries, ICANN staff should immediately implement a
system that avoids individual negotiations of ICANN fees and provides
consistency unless there is an established justification for disparate
treatment.
(TOR 4: Rec 4A)

name="_Toc37822855">The ICANN Board should establish a Task Force or Advisory
Committee to examine budgeting issues, including the manner and allocation of
revenue collection, budget oversight and budget approval processes. This group should solicit and review public
comments on the issues.
(TOR 4: Rec 4B)

style='mso-yfti-irow:0 !msorm;mso-yfti-firstrow:yes !msorm'>

In
order to determine whether there is a need for a new consensus policy on the
collection and use of registry data, including traffic data, for purposes
other than which is was collected, there is first a need for a properly
targeted study by an independent third party on the data collected and the
uses to which it is put.

The
study should provide appropriate safeguards to protect any data provided for
the purposes of the study, and the confidentiality of which registry, or
other group, provides the data. The findings of the study should be published
and available for public review. A
Statement of Work should be developed by the GNSO Council, with appropriate
public review, to cover an analysis of the concerns for data collection and
use, the practice involved in collection and use of data - including traffic
data, and the availability, when appropriate, for non-discriminatory access
to that data.

It
is recommended that a current processes document be developed, describing the
current registry practices for the collection of data and the uses of that
data, for example, but not limited to, operating the registry; preparing
marketing materials to promote registration of domain names; gathering of
'null' returns, ensuring the integrity of the Registry, or the DNS. This
report should be available to the group doing the external study and should
be made available to the public for comment.

After examining the results of the
independent study and public discussions recommended above, the GNSO Council
should examine the findings and determine what, if any, further policy
process is required. (TOR 5: Rec 5)

style='mso-yfti-irow:0 !msorm;mso-yfti-firstrow:yes !msorm'>

name="_Toc37822856">There should not be a policy guiding
investments in development and infrastructure. (TOR 6: Rec 6A)

name="_Toc37822857">ICANN should establish baseline requirements for the
security and stability of registries and anything above that would be
negotiated on a case-by-case basis, if necessary. Baseline requirements should be recommended
to the Board by the Security and Stability Advisory Committee (SSAC) after
consultation with the gTLD registry operators. In determining those recommendations, the
SSAC should solicit and consider public comments.
(TOR6: Rec 6B)

The following table sets out the recommendations that received some support
from either constituencies or NomCom members.
Support from three constituencies with some NomCom support was termed
medium support. Support from fewer than
three constituencies was termed weak support.

style='margin-left:40.05pt;border-collapse:collapse;border:none;mso-border-top-alt:
solid black 1.5pt;mso-border-bottom-alt:solid black 1.5pt;mso-yfti-tbllook:
191;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;mso-border-insideh:cell-none;
mso-border-insidev:cell-none'>

name="_Toc37822858">Other Recommendations

Registry agreements should be a commercially
reasonable length but that "commercially reasonable length" was not
determined. (TOR1: Rec 1A.2)

When a registry contract is up for
renewal, there should be a determination whether that registry is market
dominant. That determination should be made by a panel of competition experts
including competition lawyers and economists. This panel would operate
similarly to the panel that reviews the security and stability implications
of new registry services. If the panel
determines that there is a situation of market power, then the registry
agreement must include a pricing provision for new registrations, as
currently is included in all of the largest gTLD registry agreements. If the
panel determines that there isn't market power, then there would be no need
for a pricing provision related to new registrations, as is the practice in
the recent round of sTLD registry agreements.

Regardless of whether there is market
dominance, consumers should be protected with regard to renewals due to the
high switching costs associated with domain names. Therefore, this policy
recommendation is to continue the system of pricing provisions in the current
unsponsored TLD agreements with regard to domain name renewals. The price for
new registrations and renewals for market dominant registries and for
renewals for non-market dominant registries should be set at the time of the
renewal of the registry agreement. Such a price should act as a ceiling and
should not prohibit or discourage registries from providing promotions or
market incentives to sell more names. In agreeing on such a price ceiling,
ICANN should consider the domain name market, the price of names in the prior
agreement, the market price in cases of competition through rebids, and the
specific business plans of the registry.
The pricing provision should include the ability for an increase if
there is cost justification for such an increase, as is required in the
current registry agreements with pricing provisions. Such increases should be
evaluated and approved by a third party entity, such as an accounting or
financial analyst firm. Differential
pricing between domain names should be prohibited whenever there is a set
price/price cap and should be permitted when there isn't such a price constraint.
In other words, non-dominant registries may differentially price for new
registrations, but not for renewals. Dominant registries may not
differentially price for new registrations or renewals. Finally, as is the current practice, all
registries should provide equitable pricing opportunities for all registrars
and at least six months notice before any price increase. (TOR3)

The NCUC argued that it is premature to
formulate policy in the area of pricing without having had the benefit of an
intensely focused study on this topic.
The NCUC suggested that a new PDP is required to address the specific
issue of price controls. (TOR3)

The right of renewal should be
standardized for all gTLD registry agreements. Two Constituencies supported this view and
two abstained. (TOR 4: Rec 4A1)

The right of renewal should be
standardized for all registry agreements except when there is an exceptional
situation. (TOR 4: Rec 4B1)

style='page-break-before:always'>

name="_Toc38689916">
name="_Toc34982511">2. Recommendations
Discussion

2.1 There
were six Terms of Reference with several suggestions for possible policy recommendations
relating to each Term of Reference. The
Table in Annex One sets out each of the full set of proposed choices and shows
where each Constituency has voted. An
email was sent to the PDPFeb06 email list on 25 January 2007
style='mso-footnote-id:ftn12' href="#_ftn12" name="_ftnref12" title="">[12] seeking confirmation that the table
accurately represented the views of each Constituency. A further note was sent on 31 January 2007
confirming that, if no responses were received by 2 February 2007, it would be
assumed that the chart was an accurate representation. Full discussion of each of the
recommendations took place at the 24 February Task Force meeting in Los Angeles
to confirm levels of support. Final
discussion took place at the 23 March 2007 Lisbon meetings.

2.2 The
recommendation text should be read in conjunction with the correspondence from
the General Counsel's office
style='mso-footnote-id:ftn13' href="#_ftn13" name="_ftnref13" title="">[13] in response to Task Force Chair Maureen
Cubberley's request for more information about the applicability of the Task
Force's recommendations to existing registry contracts. In addition, the participation data in Annex
Three provides a full set of data on which constituencies participated in each
of the Task Force's calls and Rapporteur Groups. On numerous occasions, several Constituencies
were not represented.

name="_Toc34982512">3. Term of Reference 1A: Registry agreement renewal

name="_Toc37822862">Examine
whether or not there should be a policy guiding renewal, and if so, what the
elements of that policy should be.

name="_Toc37822863">
style='mso-bidi-font-style:normal'>Recommendation 1A: There should be a policy guiding registry
agreement renewal.

name="_Toc37822864">
style='mso-bidi-font-style:normal'>Recommendation 1B: The initial term of Registry
agreements should be for a commercially reasonable length.

style='mso-bidi-font-style:normal'>Recommendation 1C: There was majority
support for the concept of a re-bid of registry contracts but there are
differing opinions as to the conditions under which re-bids would occur.

3.1 The
Task Force considered a number of variations on the draft policy recommendation
for all the Terms of Reference. Term of Reference One was considered by
Rapporteur Group A (RGA). The
transcripts for the weekly conference calls conducted through October 2006 can
be found at http://gnso.icann.org/drafts/.

3.2 Term
of Reference One discussion separated out whether there should be a policy
guiding renewal. All Constituencies
except the RyC agreed that there should be a policy guiding renewal.

3.3 The
discussion then turned to what elements that policy should include -- whether
there should be a standard term for all gTLD registries that the initial term
is a commercially reasonable length.

3.4 Four
Constituencies supported this recommendation but the RyC questioned what was a
"commercially reasonable length" and whether the GNSO were the appropriate body
to determine that. In parallel
discussions about the introduction of new top-level domains, a "commercially
reasonable term" was suggested to be ten years.
This is consistent with, for example, the current .jobs agreement
style='mso-footnote-id:ftn14' href="#_ftn14" name="_ftnref14" title="">[14] where the term of the agreement is discussed
in Article IV.

3.5 There
was detailed discussion about the "presumption of renewal" of registry
contracts and no agreement was reached.
Two Constituencies (CBUC & ISPCP along with Bekele and Doria)
supported the recommendation that there should be a reasonable expectation of
renewal with a mandatory re-bid (with an advantage to the incumbent
operator).

3.6 Two
Constituencies (IPC and RC along with Greenberg) supported a discretionary
re-bid based on ICANN's determination of poor performance (or other bad acts)
with an advantage to the incumbent.

3.7 The
remaining two Constituencies (NCUC and RyC) argued that there should be no
re-bid unless there was a history of repeated material breaches. This option reflects the current situation
for the existing registry contracts.

3.8 There
was detailed discussion about the nature and conditions of any re-bid
process.

3.9 There
was majority support for a policy guiding renewals.

3.10
There was majority support for the
recommendation that the initial term of registry agreements should be of a
reasonable length.

3.11
There was majority support for the concept of a
re-bid of registry contracts but there are differing opinions as to the conditions
under which re-bids would occur.

3.12
The remainder of the proposed recommendations do
not have majority support.

style='page-break-before:always'>

name="_Toc34982516">4. Term
of Reference 1B: Registry agreement
renewal standardization

name="_Toc37822866">Recognizing
that not all 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 registry agreements.

4.1 The
discussion about whether registry agreement terms should be standardized across
future registry agreements has been discussed both in the context of this
policy development process and within the policy development process on the
introduction of new top-level domains (see Term of Reference 4 - Policies for
Contractual Conditions in the updated draft Final
Report)
style='mso-footnote-id:ftn15' href="#_ftn15" name="_ftnref15" title="">
style='mso-bidi-font-style:normal'>[15].

4.2 Rapporteur
Group A (RGA) considered this question in its work (referenced in the footnote
above) and derived two possible recommendations. The first proposal was that
the right of renewal should be standardized for all gTLD registry agreements. Two Constituencies supported this view and
two abstained.

4.3 The
second part of the recommendation suggested that the right of renewal should be
standardized for all registry agreements except in an exceptional situation
such as in the footnote below. Two Constituencies supported this view and two
abstained.

4.4 In
summary, there is no majority support for either of the recommendations in this
context but, in the context of the PDP Dec 05 on new TLDs, the final policy
recommendation may differ.

name="_Toc33432057">
name="_Toc34982518">5.
Term of Reference 2A: Relationship between registry agreements and
consensus policies

Recommendation 2A: The present limitations to Consensus Policies
are appropriate and should continue.

5.1 "Consensus
Policies" is a clearly defined term in all of the existing registry agreements
style='mso-footnote-id:ftn16' href="#_ftn16" name="_ftnref16" title="">[16]. In
each of the agreements, the applicability of Consensus Policies is set out
clearly. The limitations on Consensus
Policy provisions also provide a guide to areas to which the GNSO policy
development process applies.

5.2 The
Section 3 of the 2006 .biz registry agreement sets out explicitly the
applicability of Consensus Policies and the way in which those policies are
formulated.

3.1
(b) Consensus Policies.

3.1
(b)(i) At all times during the term of this Agreement and subject to the
terms hereof, Registry Operator will fully comply with and implement all
Consensus Policies found at
http://www.icann.org/general/consensus-policies.htm, as of the Effective Date
and as may in the future be developed and adopted in accordance with ICANN's
Bylaws and as set forth below.

3.1
(b)(ii) "Consensus Policies" are those specifications or
policies established (1) pursuant to the procedure set forth in ICANN's Bylaws
and due process, and (2) covering those topics listed in Section 3.1(b)(iv)
below. The Consensus Policy development process and procedure set forth in
ICANN's Bylaws may be revised from time to time in accordance with ICANN's
Bylaws, and any Consensus Policy that is adopted through such a revised process
and covering those topics listed in Section 3.1(b)(iv) below shall be
considered a Consensus Policy for purposes of this Agreement.

3.1
(b)(iii) For all purposes under this Agreement, the policies identified
at
href="http://www.icann.org/general/consensus-policies.htm">http://www.icann.org/general/consensus-policies.htm shall be treated in the same manner and have the same
effect as "Consensus Policies."

3.1
(b)(iv) Consensus Policies and the procedures by which they are developed
shall be designed to produce, to the extent possible, a consensus of Internet
stakeholders, including the operators of gTLDs. Consensus Policies shall relate
to one or more of the following: (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).
Such categories of issues referred to in the preceding sentence shall include,
without limitation:

3.1
(b)(iv)(A) principles for allocation of registered names in the TLD
(e.g., first-come, first-served, timely renewal, holding period after
expiration);

3.1
(b)(iv)(B) prohibitions on warehousing of or speculation in domain names
by registries or registrars;

3.1
(b)(iv)(C) reservation of registered names in the TLD that may not be
registered initially or that may not be renewed due to reasons reasonably
related to (a) avoidance of confusion among or misleading of users, (b)
intellectual property, or (c) the technical management of the DNS or the
Internet (e.g., establishment of reservations of names from registration);

3.1
(b)(iv)(D) maintenance of and access to accurate and up-to-date information
concerning domain name registrations;

3.1
(b)(iv)(E) procedures to avoid disruptions of domain name registration
due to suspension or termination of operations by a registry operator or a
registrar, including procedures for allocation of responsibility for serving
registered domain names in a TLD affected by such a suspension or termination;
and

3.1
(b)(iv)(F) resolution of disputes regarding whether particular parties
may register or maintain registration of particular domain names.

3.1
(b)(v) In addition to the other limitations on Consensus Policies, they
shall not:

3.1
(b)(v)(A) prescribe or limit the price of Registry Services;

3.1
(b)(v)(B) modify the standards for the consideration of proposed Registry
Services, including the definitions of Security and Stability (set forth below)
and the standards applied by ICANN;

3.1
(b)(v)(C) for two years following the Effective Date, modify the
procedure for the consideration of proposed Registry Services;

3.1
(b)(v)(D) modify the terms or conditions for the renewal or termination
of this Agreement;

3.1
(b)(v)(E) modify ICANN's obligations to Registry Operator under Section
3.2 (a), (b), and (c);

3.1
(b)(v)(F) modify the limitations on Temporary Specifications or Consensus
Policies;

3.1
(b)(v)(G) modify the definition of Registry Services;

3.1
(b)(v)(H) modify the terms of Sections 7.2 below; or

3.1
(b)(v)(I) alter services that have been implemented pursuant to Section
3.1(d) of this Agreement (unless justified by compelling and just cause based
on Security and Stability.

3.1
(b)(vi) Registry Operator shall be afforded a reasonable period of time
following notice of the establishment of a Consensus Policy or Temporary
Specifications or Policies in which to comply with such policy or
specification, taking into account any urgency involved. In the event of a
conflict between Registry Services (as defined in Section 3.1(d)(iii) below),
on the one hand, and Consensus Policies developed in accordance with this
Section 3.1(b) or any Temporary Specifications or Policies established pursuant
to Section 3.1(a)(i) above, on the other hand, the Consensus Polices or
Temporary Specifications or Policies shall control, notwithstanding any other
provisions contained within this Agreement.

5.3 The
.aero sponsorship agreement
style='mso-footnote-id:ftn17' href="#_ftn17" name="_ftnref17" title="">[17] treats Consensus Policies slightly
differently but the major components remain the same.

5.4 The
Task Force discussed three possible recommendations. Option 2A.1 that Consensus Policies
limitations are inappropriate; Option 2A.2 that Consensus Policies should
always apply to all gTLD registries and 2A.3 that the present limitations to
Consensus Policies are appropriate and should continue

5.5
The IPC, CBUC and ISPCP Constituencies supported
2A.2.

5.6
The RC, RyC, NCUC and NomCom members Doria and
Bekele supported recommendation 2A.3 that the present limitations to Consensus
Policies are appropriate and should continue.

name="_Toc38689924">
name="_Toc33432058">6.
Term of Reference 2B: Relationship between registry agreements and
consensus policies and delegation of responsibility

style='mso-bidi-font-style:normal'>Recommendation
2B: Certain policy making responsibility
should be delegated to the sponsored gTLD operators.
style='mso-bidi-font-style:normal'>

6.1 The
Task Force recognised that "…certain policy making responsibility should be
delegated to the sponsored gTLD operators, but variations can be made, based on
the characteristics of the sponsoring community. Variations should be discussed/disclosed in
charter for public comment. Examples of
policy making responsibility to be delegated to the sponsored gTLD operators
include but are not limited to the "charter and scope of 'sponsored community;
eligibility to be in the 'sponsored category; eligibility for a particular name
and the concept of a conflicts/dispute process as a service to the sponsored
community.

6.2 The
nature of sponsorship in the ICANN context relates particularly to the subset
of sponsored TLDs including .aero, .museum, .coop and .travel. A full list of the sponsored TLDs and their
specific agreements can be found at
href="http://www.icann.org/registries/agreements.htm">http://www.icann.org/registries/agreements.htm and the sponsorship conditions can be found
within those agreements, for example in the case of the .mobi agreement at http://www.icann.org/tlds/agreements/mobi/mobi-appendixS-23nov05.htm.

6.3 All
Constituencies supported the recommendation that certain policy making
responsibility should be delegated to the sponsored gTLD operators.

name="_Toc38689925">
name="_Toc33432059">7.
Term of Reference 3: Policy for price controls
for registry services

7.1 This
Term of Reference was discussed in detail by Rapporteur Group B (RGB) which
took responsibility for TOR 3, 4 and 6
style='mso-footnote-id:ftn18' href="#_ftn18" name="_ftnref18" title="">[18].

7.2 The
RyC did not take part in any discussion with respect to price controls and
actively voiced its opposition both to the Term of Reference itself and any
discussion of it. The IPC abstained from voting on this recommendation. The NCUC did not vote on the proposed policy
recommendation but expressed its position in section 7.5. The remainder of the
Constituencies supported the recommendation and discussion as drafted below.

7.3 When
a registry contract is up for renewal, there should be a determination whether
that registry is market dominant. That determination should be made by a panel
of competition experts including competition lawyers and economists. This panel
would operate similarly to the panel that reviews the security and stability
implications of new registry services.
If the panel determines that there is a situation of market power, then
the registry agreement must include a pricing provision for new registrations,
as currently is included in all of the largest gTLD registry agreements. If the
panel determines that there isn't market power, then there would be no need for
a pricing provision related to new registrations, as is the practice in the
recent round of sTLD registry agreements.

7.4 Regardless
of whether there is market dominance, consumers should be protected with regard
to renewals due to the high switching costs associated with domain names.
Therefore, this policy recommendation is to continue the system of pricing
provisions in the current unsponsored TLD agreements with regard to domain name
renewals. The price for new registrations and renewals for market dominant
registries and for renewals for non-market dominant registries should be set at
the time of the renewal of the registry agreement. Such a price should act as a
ceiling and should not prohibit or discourage registries from providing
promotions or market incentives to sell more names. In agreeing on such a price
ceiling, ICANN should consider the domain name market, the price of names in
the prior agreement, the market price in cases of competition through rebids,
and the specific business plans of the registry. The pricing provision should include the
ability for an increase if there is cost justification for such an increase, as
is required in the current registry agreements with pricing provisions. Such
increases should be evaluated and approved by a third party entity, such as an
accounting or financial analyst firm.
Differential pricing between domain names should be prohibited whenever
there is a set price/price cap and should be permitted when there isn't such a
price constraint. In other words, non-dominant registries may differentially
price for new registrations, but not for renewals. Dominant registries may not
differentially price for new registrations or renewals. Finally, as is the current practice, all
registries should provide equitable pricing opportunities for all registrars
and at least six months notice before any price increase."

7.5 The
NCUC argued that it was premature to formulate policy in the area of pricing
without having had the benefit of an intense focused study on the topic. The NCUC suggested that a new PDP is required
to address the specific issue of price controls.

7.6 In
summary, the RyC did not participate in any of the discussions on price
controls. The NCUC did not support
either recommendation. The IPC abstained
from voting on either recommendation.
The Registrars, ISPCP and the CBUC supported Recommendation 3A.1.

style='mso-special-character:line-break'>

clear=all style='mso-special-character:line-break;page-break-before:always'>

name="_Toc34982521">8. Term of Reference 4: ICANN fees

name="_Toc37822871">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.

name="_Toc37822872">
style='mso-bidi-font-style:normal'>Recommendation 4A: That in order
style='mso-bidi-font-style:normal'>to
improve ICANN accountability and effective business planning by registries,
ICANN staff should immediately implement a system of ICANN fees from registries
that avoids individual negotiations of ICANN fees and provides consistency
unless there is established justification for disparate treatment.

Recommendation 4B:
style='mso-bidi-font-style:normal'>The ICANN Board should establish a Task
Force or Advisory Committee to examine budgeting issues, including the manner
and allocation of revenue collection, budget oversight, and budget approval
processes. This group should solicit and
review public comments on the issues.

8.1 This
Term of Reference was discussed by Rapporteur Group B (RGB ) which took
style='mso-comment-reference:LW_2;mso-comment-date:20070224T2007'>
class=msocomanchor id="_anchor_2"
onmouseover="msoCommentShow('_anchor_2','_com_2')"
onmouseout="msoCommentHide('_com_2')" href="#_msocom_2" language=JavaScript
name="_msoanchor_2">[LW2] responsibility
for TOR 3, 4 and 6
style='mso-footnote-id:ftn19' href="#_ftn19" name="_ftnref19" title="">[19]. The
results of its discussion via teleconferences can be found in the report in the footnote below
which was supplemented by discussion at the Task Force's meeting in Sao Paulo.

8.2 The
RG recommended that "…in order to
improve ICANN accountability and effective business planning by registries,
ICANN staff should immediately implement a system of ICANN fees from registries
that avoids individual negotiations of ICANN fees and provides consistency
unless there is established justification for disparate treatment."

8.3 Five constituencies supported the
recommendation with the RyC abstaining from the vote.
style='mso-comment-reference:LW_3;mso-comment-date:20070224T2007'>
class=msocomanchor id="_anchor_3"
onmouseover="msoCommentShow('_anchor_3','_com_3')"
onmouseout="msoCommentHide('_com_3')" href="#_msocom_3" language=JavaScript
name="_msoanchor_3">[LW3]

8.4 The
RG also recommended that "…the ICANN Board should establish a Task Force or
Advisory Committee to examine budgeting issues, including the manner and
allocation of revenue collection, budget oversight, and budget approval
processes. This group should solicit and
review public comments on the issues."

8.5 All
Constituencies, except the RyC supported this recommendation.

style='mso-special-character:line-break'>

name="_Toc36877717">9. Term of Reference 5: Uses of Registry Data

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.

style='mso-bidi-font-style:normal'>Recommendation 5:
style='mso-bidi-font-style:normal'>In
order to determine whether there is a need for a new consensus policy on the
collection and use of registry data, including traffic data, for purposes other
than which is was collected, there is first a need for a properly targeted
study by an independent third party on the data collected and the uses to which
it is put.

style='mso-bidi-font-style:normal'>The
study should provide appropriate safeguards to protect any data provided for
the purposes of the study, and the confidentiality of which registry, or other
group, provides the data. The findings of the study should be published and
available for public review. A Statement
of Work should be developed by the GNSO Council, with appropriate public
review, to cover an analysis of the concerns for data collection and use, the
practice involved in collection and use of data - including traffic data, and
the availability, when appropriate, for no- discriminatory access to that data.

style='mso-bidi-font-style:normal'>It
is recommended that a current processes document be developed, describing the
current registry practices for the collection of data and the uses of that
data, for example, but not limited to, operating the registry; preparing
marketing materials to promote registration of domain names; gathering of
'null' returns, ensuring the integrity of the Registry, or the DNS. This report
should be available to the group doing the external study and should be made
available to the public for comment.

style='mso-bidi-font-style:normal'>After
examining the results of the independent study and public discussions
recommended above, the GNSO Council should examine the findings and determine
what, if any, further policy process is required.

9.1
This Term of Reference was discussed by RG1 and
in subsequent teleconferences by the Task Force as a whole when it became clear
that little progress had been made on any proposed recommendations.

9.2
In a straw poll at the Sao Paulo meeting, four
Constituencies suggested that further work needed to be done which was followed
up by conference calls on 16 January, 23 January, 6 and 15 February 2007
style='mso-footnote-id:ftn20' href="#_ftn20" name="_ftnref20" title="">[20]. On
those calls there was disagreement about the nature of the problem to be solved
by considering the question of registry data; scant agreement on what the
problems actually were and what kind of information the RyC committed to
provide to the group to assist with the discussions.

9.3
Ms Doria provided a set of proposed
recommendations in her email
style='mso-footnote-id:ftn21' href="#_ftn21" name="_ftnref21" title="">[21] to the Task Force on 1 February 2007 which
said, in part, …"proposed recommendation a.
There is no clear need for a new policy on the use of registry data, including
traffic data, for purposes other then which is was collected [;] b. There is,
however, a need for exhaustive public study by an outside agency on the data
collected and the uses to which it is put [and] c. It is recommended that a
best practices document be published as a guideline for Registry data
collection and use". In
order to determine whether there is a need for a new consensus policy on the
collection and use of registry data, including traffic data, for purposes other
than which is was collected, there is first a need for a properly targeted
study by an independent third party on the data collected and the uses to which
it is put. The study should provide
appropriate safeguards to protect any data provided for the purposes of the
study, and the confidentiality of which registry, or other group, provides the
data. The findings of the study should be published and available for public
review. A Statement of Work should be
developed by the GNSO Council, with appropriate public review, to cover an analysis
of the concerns for data collection and use, the practice involved in
collection and use of data - including traffic data, and the availability, when
appropriate, for no- discriminatory access to that data. It is recommended that a current processes document
be developed, describing the current registry practices for the collection of
data and the uses of that data, for example, but not limited to, operating the
registry; preparing marketing materials to promote registration of domain
names; gathering of 'null' returns, ensuring the integrity of the Registry, or
the DNS. This report should be available to the group doing the external study
and should be made available to the public for comment. After examining the results of the
independent study and public discussions recommended above, the GNSO Council
should examine the findings and determine what, if any, further policy process
is required"

9.4
The TOR was discussed at the February 2007 Los
Angeles meetings to determine the level of support for Ms Doria's
recommendations. The CBUC, ISPCP, RC
supported the recommendation with additional individual support from Bekele.

9.5
In a 5
March 2007 email to the PDPFeb06 archive, the RyC re-iterated its opposition to
the proposal in the following text. "The
gTLD Registries Constituency ("RyC") votes NO
on the proposed resolution to conduct a "study by an independent third party on
the data [collected by registries] and the uses to which it is put" for the
reasons set forth below. The RyC believes that it is premature to conduct
a study on the collection and use of registry data, in particular because the
Task Force has never been able to (1) define exactly what it means by "registry
data"; (2) articulate a list of realistic concerns with respect to the
contractual provision governing registry data; nor (3) articulate either the
deficiencies in, or any potential harm flowing from, the existing contractual
conditions governing registry data. In
the absence of clarity with respect to these three critical components the proposed
study amounts to nothing more than an unjustified "fishing expedition" to
identify new ways to regulate registry practices. The policy development
process is intended to address real issues arising within ICANN's narrow
technical mission. Absent a reasonable articulation of the potential harm
to be studied, the terms of the existing .biz, .com, .info and .org agreements,
coupled with existing national law provide ample controls. Undertaking the
proposed study at this time would constitute an abuse of the policy development
process, to say nothing of the time, energy, and resources - both human and
financial - that it would consume.

9.6
The
Business Constituency, in clarification of the question about use of registry
data, would like to record that it has consistently raised concerns about the
use of registry data being used for commercial
purposes other than those for which the data is collected such as the
identification of commercially valuable sites from null returns that indicate
potential value as typosquatting sites.
This topic is one that the TF recommendation for a study should address.

name="_Toc36877718">10. Term
of Reference 6: Investment 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.

style='mso-bidi-font-style:normal'>Recommendation 6A: There should not be a policy guiding
investments in development and infrastructure.

style='mso-bidi-font-style:normal'>Recommendation 6B: ICANN should establish baseline requirements
for the security and stability and security of registries and
style='mso-bidi-font-style:normal'>anything
above that would be negotiated on a case-by-case basis, if necessary. Such a baseline requirements should be
recommended to the Board by the Security and Stability Advisory Committee
("SSAC") after consultation with the gTLD registry operators. In
determining these recommendations, the SSAC also should solicit and consider
public comments.
style='mso-bidi-font-style:normal'>

10.1
This Term of Reference was discussed and the
recommendation was agreed early in the Task Force's work. Two recommendations emerged from the discussion.

10.2
All Constituencies agreed that there
should not be a policy guiding investments in development and
infrastructure.

10.3
The
second recommendation which was supported by all constituencies was that ICANN
should establish baseline requirements for the security and stability of the
registries and anything above that would be negotiated on a case-by-case basis,
if necessary. Such baseline requirements
should be recommended to the Board by the Security and Stability Advisory
Committee (SSAC) after consultation with the gTLD registry operators. In
determining these recommendations, the SSAC also should solicit and consider
public comments.

style='page-break-before:always'>

name="_Toc38689931">11.
Public Comments

Public comment periods are an integral part
of ICANN's policy development process.
The public comment archives were opened on 8 March 2007 and closed on 28
March 2007[22].
Three comments were submitted, one of which the Registry Constituency is
set out above. The two additional
comments are set out in full below.

Danny Younger
style='mso-footnote-id:ftn23' href="#_ftn23" name="_ftnref23" title="">[23] submitted:

Out of Scope

To:
pdp-feb06-comments@xxxxxxxxx

Subject: Out of Scope

From: Danny
Younger <dannyyounger@xxxxxxxxx>

Date: Tue, 27 Mar
2007 18:18:04 -0700 (PDT)

A short note:

I was
extremely disconcerted by this particular PDP.

From the
outset the Registry Constituency relentlessly voiced their strenuous opposition
and I kept wondering throughout the entire process whether anyone other than
the Registry constituency still grasped the concept of "consensus".

I have come to
conclude that the ICANN non-registry GNSO community no longer understands the
fundamentals of governance by consensus, and instead now acts to pervert our
founding consensus process by seeking to unilaterally impose their will upon
the registries through the vehicle of recommendations that they hope the Board
will consider when acting to renegotiate registry contracts.

In this
context, the non-registry GNSO constituencies are acting collectively as an
advisor to one single party (ICANN) in a two-party contract over the opposition
of the second party, an action that in my view is fully outside the scope of
their chartered activities.

Frankly, the
ICANN General Counsel should have stepped in with a definitive ruling as to
whether the GNSO activities were in or out of scope. Instead, we wasted over a year in pursuit of
this folly.

We are looking
at a major problem here... if the bulk of the GNSO constituencies no longer
understand the fundamentals of the "consensus policy process" (a
governance principle that asks each supplier whether they will agree contractually
to implement and abide by a future rule, sight unseen, provided that most
people support it and that those parties substantially affected by the policy
do not vigorously or unreasonably oppose it), then ICANN's legitimacy as a
rule-maker is once more thrown into question.

Phil Corwin
style='mso-footnote-id:ftn24' href="#_ftn24" name="_ftnref24" title="">[24] submitted the following:

Internet Commerce Association
Comments on the Draft Final Task Force Report

To:
<pdp-feb06-comments@xxxxxxxxx>

Subject: Internet
Commerce Association Comments on the Draft Final Task Force Report

From: "Phil
Corwin" <pcorwin@xxxxxxxxxxxxxxxxxx>

Date: Thu, 29 Mar
2007 18:49:35 -0400

Note: This comment
letter was filed yesterday in advance of the comment deadline from Lisbon while
attending the ICANN meeting. However, for some reason no e-mail confirmation
was received nor has it been posted at the ICANN website. We are therefore
re-submitting it. Thank you.

BUTERA & ANDREWS

Attorneys at Law

1301 Pennsylvania
Avenue, N.W.

Washington, D.C.
20004-1701

202-347-6875

Philip S. Corwin,
Partner

pcorwin@xxxxxxxxxxxxxxxxxx
<
href="mailto:pcorwin@xxxxxxxxxxxxxxxxxx">mailto:pcorwin@xxxxxxxxxxxxxxxxxx> By E-Mail

March 28, 2007

Board of Directors

Internet Corporation
for Assigned Names and Numbers (ICANN)

4676 Admiralty Way,
Suite 330

Marina del Rey, CA
90292-6601

Re: ICANN Opens
Public Comment Period on Policy Development Process on Policies

for Contractual
Conditions: Existing Registries

<
href="http://gnso.icann.org/announcements/announcement-08mar07.htm">http://gnso.icann.org/announcements/announcement-08mar07.htm>

Dear Members of the
ICANN Board:

This comment letter
is submitted by the Internet Commerce Association (ICA) in regard to the March
8, 2007 ICANN Notice, "ICANN Opens Public Comment Period on Policy
Development Process on Policies for Contractual Conditions: Existing Registries
<
href="http://gnso.icann.org/announcements/announcement-08mar07.htm">http://gnso.icann.org/announcements/announcement-08mar07.htm> ".

ICA is a
not-for-profit trade association. Its membership is composed of individuals and
companies that invest in domain names and develop and monetize the associated
websites. ICA's mission is to promote the benefits of the activities of
professional domain name investors and developers to the press, advertisers,
and governmental authorities on a global basis. ICA stands for Internet
prosperity and entrepreneurship and for fairness among regulators and in the
dispute resolution process, taxation, and treatment under other relevant laws,
regulations, and agreements in the U.S. and other nations. ICA provides a
unified voice for a membership with common interests and a diverse collection
of experience in the professional domain name ownership community. This
community represented by ICA has risked large amounts of capital in order to
develop domain names as the first new form of property of the virtual age. Professional domain name registrants are a
major source of the fees that support registrars, registries, and ICANN itself.

The ICA commends
ICANN for soliciting public comment on this draft Final Task Force Report
("Report") prepared for the Generic Names Supporting Organization
(GNSO) in furtherance of its PDPFeb06 project. It is unfortunate that the ICANN
Board ignored the many requests from a broad range of community members that it
defer final action on the proposed new registry contracts for .Biz, .Org and
.Info until this Report could be completed and considered. The premature
approval of those contracts at the December 2006 Sao Paulo meeting, far in advance
of their renewal dates, was a grave disservice to the many registrants who had expressed outrage over
their presumptive renewal and pricing increase provisions. The Board's
explanation that it would be unfair to these registries to deny them the same
unjustifiable concessions that were made to VeriSign in the .Com settlement
displayed a great insensitivity to what constitutes fairness to millions of
domain name (DN) registrants. Nonetheless, we presume that your solicitation of
comments on the Report is an indication that it may have some beneficial impact
on all registry contracts in the future.

The general views of
the ICA as regards the key recommendations of the Report are as follows:

* Registry Agreement Renewal - We concur
that there should be a general policy guiding renewals and that registry
agreements should be a commercially reasonable length; we do however have
concerns hat the suggested standard term of ten years may be too long a term,
especially for dominant registries or newly introduced registries, and that a
shorter period would allow recouping of investment in combination with market
testing at intervals that prevent a drift into monopolistic conduct. While we
have no objections to a reasonable presumption of renewal where a registry
operator has not materially breached its existing agreement we cannot support
presumptive renewal as written into the current .Com and similar registry
agreements, as they permit the presumption to stand despite multiple material
breaches triggering corrective arbitration or litigation by ICANN. Such
presumptive renewal is an effective grant of perpetual renewal and is blatantly
anti-competitive. In any event, we support mandatory re-bid, with a modest but
not insurmountable advantage to the incumbent operator who has not been in
material breach, as the only practical means to provide periodic market testing
of service quality and pricing. Absent
such market testing the only viable alternative would be pervasive price and
service quality regulation, an approach that we do not favor.

* Relationship to Consensus Policies - We
support the view that Consensus

Policies should apply
to all generic top level domain (gTLD) registries. We also support the
recommendation that it is appropriate to delegate certain policy making
responsibilities to operators of sponsored top level domain (sTLD) registries.

* Pricing Policies - As an association of
free market entrepreneurs our general preference is for marketplace
determination of pricing. However, given that each registry operator is an
effective natural monopolist, that certain gTLD operators have substantial
market dominance (especially .Com), and that DN registrants face high switching
costs, some effective controls on registry pricing must be in place. Periodic
market testing can have a salutary effect in this regard, as was demonstrated
in the re-bid process for the .Net gTLD.

Registry agreements
should contain reasonable limits on annual price increases and in all cases
should require that any proposed increase be justified by verifiable cost data
accompanied by a demonstration that the registry operator would not reap an
excessive return on investment from the proposed increase.

Differential pricing
within any TLD should be prohibited, as the cost of providing registry services
to any particular DN is identical and differential pricing therefore
constitutes an unjustified tax on the value of a particular DN or on the
commerce taking place at the associated website. In determining the relative dominance
of particular TLDs we would suggest that ICANN utilize the auction and other
pricing data that is now readily available from the robust and highly
competitive marketplace for secondary DNs, as high valuations for particular
TLDs are indicative of such dominance.

* ICANN Fees - We support the view that
ICANN should implement a system of fees from registries that avoids individual
negotiation and provides consistency and predictability. Separate negotiations
may tend to prolong ICANN's reliance on particular TLDs for its own funding as
well as leverage the negotiation process to support new staff-driven projects.

* Use of Registry Data - We support the
development of a general policy on the permissible registry use of registry
data, including traffic data, for purposes other than that for which it was
collected, as well as the development of a policy to ensure non-discriminatory
access to registry data by third parties. Such basic statistical data on the
operation of the DNS should be available, subject to appropriate privacy
protections, to all parties seeking it. Further, the availability of such data
is the only way to ensure that competing bids submitted in a re-bid process are
based on sound and accurate TLD data. Finally, any policy addressing this area
should ensure that registries do not use such data to unfairly leverage their
monopoly operator position into one of competitive advantage for the offering
of services against registrants and registrars who must rely upon the TLD operators.

* Investment in Development and
Infrastructure - We support the development of baseline requirements for the
security and stability of registries by
ICANN in consultation with the Security and Stability Advisory Committee
(SSAC). In fact, we are quite surprised that such requirements have not yet
been established given the critical and ever expanding role of the Internet in
facilitating global commerce and communications.

In all of the above
areas, maximum utilization of open competition combined with greater process
transparency and ICANN accountability will yield results that best assure the
continued secure and stable operation of the DNS in a manner that is beneficial
and fair to all constituencies including registrants.

We appreciate the opportunity
to comment upon this matter and look forward to participating in ICANN's future
internal processes devoted to implementing this Report.

Sincerely,

Philip S. Corwin

Counsel, Internet
Commerce Association [address details removed]

style='page-break-before:always'>

name="_Toc38689932">Annex One - Recommendation Summary Chart

PDP FEB 06:
STRAW POLL INDICATORS CURRENT AT 28 MARCH 2007

TERMS OF REFERENCE ONE AND TWO

name="_Toc38689933">Note: The chart below shows the full range of
potential recommendations and the votes associated with them. Recommendation 1A.3, 1A.4 and 1A.5 required a
choice between alternatives.
Recommendation 1B.1 and 1B.2 required a choice between two
recommendations. Recommendation 2A.1,
2A.2 and 2A.3 required a choice between alternatives. Recommendation 3B.1 and 3B.2 required a
choice between alternatives.
Recommendation 5A.1 and 5A.2 required a choice between alternatives.

style='width:389.95pt;margin-left:5.4pt;border-collapse:collapse;mso-padding-alt:
0pt 5.4pt 0pt 5.4pt'>

POLICY RECOMMENDATION

1A.1

1A.2

1A.3

1A.4

1A.5

1B.1

1B.2

2A.1

2A.2

2A.3

2B.1

CONSTITUENCIES

CBUC

ISPCPC

IPC

Y**

NCUC

RyC

Doria

Cubberley

Bekele

Fausett

style='mso-yfti-irow:13 !msorm;height:12.3pt !msorm'>

Greenberg

TOTAL - CONSTITUENCIES

TOTAL - NV MEMBERS

PDP FEB 06:
STRAW POLL INDICATORS CURRENT AT 28 MARCH 2007

TERMS OF REFERENCE THREE, FOUR, FIVE AND SIX

style='width:390.7pt;margin-left:5.75pt;border-collapse:collapse;mso-padding-alt:
0pt 5.75pt 0pt 5.75pt'>

POLICY RECOMMENDATION

3A.1

3B.1

3B.2

4A.1

4B.1

5A.1

5A.2

5B.1

6A.1

CONSTITUENCIES

CBUC

ISPCPC

IPC

NCUC

RyC

DNV

Doria

Cubberley

Bekele

Fausett

Greenberg

TOTAL -- CONSTITUENCIES

TOTAL -- NV MEMBERS

name="_Toc38689934">
name="_Toc34982527">Legend:

name="_Toc38689935">
name="_Toc34982528">Y == support draft
recommendation; N == does not support draft recommendation; A == Abstain; P ==
Pending

name="_Toc38689936">DNV
== Did Not Vote

name="_Toc38689937">
name="_Toc34982529">NV: Non Voting Members which include the
Nominating Committee members and the ALAC representative.

name="_Toc38689938">
name="_Toc34982530">Note: The shaded recommendations indicate a choice
between policy recommendation options.

name="_Toc38689939">
name="_Toc34982531">Note: Maureen Cubberley's votes have been carried
forward from the 17 November 2006 conference call.

name="_Toc36877727">Note: Recommendations 5a.1 and 5a.2 have to be
confirmed.

name="_Toc37822884">Note**: Proposed modified text
needs consideration.

name="_Toc37822885">Note^^: Registry Constituency did
not vote on this issue.

style='page-break-before:always'>

name="_Toc36877730">Annex Two -
name="_Toc157837024">Policy
Development Process Background Information

1.1
The Task Force has held a series of meetings,
the minutes of which are available online
style='mso-footnote-id:ftn25' href="#_ftn25" name="_ftnref25" title="">[25]. The first meeting of the Task Force,
conducted during the ICANN Wellington meeting in March 2006, elected Nominating
Committee representative Maureen Cubberley as Task Force Chair and set out the
work of the group by agreeing a Task Force Charter and work timeline. During the course of the Task Force's work,
Avri Doria took over the chairing of the group.

1.2
At the 6 June 2006 meeting, the detailed work of
the Task Force began with discussion of the first draft of the Preliminary
Taskforce Report
style='mso-footnote-id:ftn26' href="#_ftn26" name="_ftnref26" title="">[26]. The Task Force agreed to conduct the third
Taskforce meeting on 24 June 2006 during the ICANN Marrakech meeting. This meeting was held, as planned, and it was
agreed to progress the work by taking any further input from Constituencies
prior to releasing an updated report after the Marrakech meeting. Since the Marrakech meeting, the Task Force
has divided into two Rapporteur Groups who have shared the detailed analysis
required for each of the Terms of Reference.

1.3
By way of more detailed background, in December
2005, the GNSO Council initiated a policy development process [PDP-Dec05] to
develop policy about whether to introduce new generic top level domains and,
subsequently, to determine the selection criteria, allocation methods and
policies for contractual conditions for any new top level domains.

1.4
During 2005, ICANN commenced a process of
revising the .net and .com agreements. There was discussion amongst members of
the GNSO community about the .net agreement (found at
http://www.icann.org/tlds/agreements/net/), and the proposed .com agreements
(found at
http://icann.org/topics/verisign-settlement.htm#amended_agreements). As a result, the GNSO Council recognized that
there may have been a broader set of policy issues around contractual
conditions for existing gTLDs. It was
thought 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.

1.5
On 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 can
be found at
href="http://gnso.icann.org/issues/gtld-policies/issues-report-02feb06.pdf">http://gnso.icann.org/issues/gtld-policies/issues-report-02feb06.pdf.

1.6
Section D of the Issues Report outlines a
discussion of many of the concerns that had been raised by the GNSO community
in response to the proposed revisions to the .com agreement. In the Issues Report, ICANN's General Counsel
advised that it would not be appropriate nor within the scope of the GNSO's
policy development remit to consider a policy development process that
specifically targeted the .com registry agreement alone.

1.7
At its meeting on 6 February 2006
style='mso-footnote-id:ftn27' href="#_ftn27" name="_ftnref27" title="">^{^[27]}, to
accommodate the concerns communicated by ICANN's General Counsel, the GNSO
Council members amended their request for an Issues Report to seek information
on the broader policy issues relating to the contractual conditions of gTLD
agreements, which had been expressed within constituency discussions.

1.8
The GNSO Council recognized 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.
As a consequence, the Council could not depend on PDP-Dec05 to address
the new issues raised by the GNSO.

1.9
At its 6 February 2006 meeting, the GNSO
Council, by a super-majority decision, decided to initiate a separate PDP
[called PDP-Feb06] to look at specific policy areas to guide the development of
contractual conditions of existing gTLDs.
The terms of reference can be found at
href="http://gnso.icann.org/issues/gtld-policies/tor-pdp-28feb06.html">http://gnso.icann.org/issues/gtld-policies/tor-pdp-28feb06.html.

1.10
The Task Force has continued its work for the
last twelve months with specific and often repeated opposition that the Task
Force was improperly formulated and incorrectly tasked. Leaving that opposition aside
class=msocomanchor id="_anchor_4"
onmouseover="msoCommentShow('_anchor_4','_com_4')"
onmouseout="msoCommentHide('_com_4')" href="#_msocom_4" language=JavaScript
name="_msoanchor_4">[LW4] , the
participation data below shows which individuals participated in the work of
the Task Force and which GNSO Constituencies were involved. It should be noted that, for many meetings,
sometimes up to three constituencies were missing from the discussions.

1.11
During the work of the Task Force, the ICANN
Board approved the signing of renewal agreements for the .biz, .info and .org
agreements
style='mso-footnote-id:ftn28' href="#_ftn28" name="_ftnref28" title="">[28].

style='page-break-before:always'>

name="_Toc36877731">Annex Three -- Participation Data

The data found here is designed to show the
nature and frequency of participation in the Task Force's work. A full and complete chart will be included in
the Board Report after the Task Force
has completed its deliberations.
style='mso-comment-reference:LW_5;mso-comment-date:20070224T2014'>
class=msocomanchor id="_anchor_5"
onmouseover="msoCommentShow('_anchor_5','_com_5')"
onmouseout="msoCommentHide('_com_5')" href="#_msocom_5" language=JavaScript
name="_msoanchor_5">[LW5] Maureen Cubberley was elected Task Force
Chair at the Wellington meeting. Avri Doria was appointed Interim Chair when Ms
Cubberley's Nominating Committee term expired.
Ms Doria then replaced Ms Cubberley as the Chair and completed the work
of the Task Force.

clear=all style='page-break-before:always;mso-break-type:section-break'>

style='width:435.6pt;margin-left:5.4pt;border-collapse:collapse;mso-padding-alt:
0pt 5.4pt 0pt 5.4pt'>

Task Force Members

Mar

June

July

Aug

Sept

Oct

Nov

Dec Jan Feb

Name & Constituency

M Cubberley Chair

CBUC

Marilyn Cade

Philip Sheppard

Grant Forsyth replaced

1 replaced by AD

Alistair Dixon

Mike Roberts

ISPCPC

Tony Holmes

1 (alt)

Tony Harris

Greg Ruth

Registrar C

Jon Nevett

Jeff Eckhaus

Ross Rader

2 (alt)

Registry C

Ken Stubbs

David Maher

Cary Karp

Jeff Neuman (alt)

added Nov 1

IPC

Ute Decker

Kiyoshi Tsuru

Lucy Nichols

NCUC

Milton Mueller

Mawaki Chango

Paula Bruening

Nom Com

Sophia Bekele

Avri Doria (replacement
Chair)

Bret Fausett ALAC

Alan Greenberg

Observers

Bruce Tonkin RR

Steve Metalitz IPC

Danny Younger NCUC

Staff

John Jeffrey

Dan Halloran

Denise Michel

Olof Nordling

Liz Williams

Maria Farrell

Kurt Pritz

Glen de St Gery

P = Present at mtg

A = Absent

RP = Remote participation

March 29,2006 Face to face
meeting in Wellington

June 24, 2006 Face to face
meeting in Marrakech

name="_Toc157837025">Rapporteur Group
A: Attendance List
style='mso-footnote-id:ftn29' href="#_ftn29" name="_ftnref29" title="">[29]

style='border-collapse:collapse;border:none;mso-border-alt:solid windowtext .5pt;
mso-yfti-tbllook:480;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;mso-border-insideh:
.5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>

Name

Constituency

11 Oct

13 Oct

17 Oct

24 Oct

Marilyn Cade - Rap.

CBUC

Present

Mike Roberts *

CBUC

Absent

Greg Ruth

ISPCPCP

Present

Absent

Tony Holmes *

ISPCPCP

Absent

David Maher

RegistryC

Absent

Present

Ute Decker

IPC

Present

Absent

Present

Danny Younger

NCUC

Present

Bret Fausett

ALAC

Absent

Jon Nevett - RGB

RegistrarC

Present

Absent

Jeff Eckhaus

RegistrarC

Did not participate

Avri Doria - Interim Chair

Nom Com

Absent

Present

Staff

Denise Michel

VP Policy

Present

Liz Williams

Senior Policy Counselor

Present

Glen de Saint Géry

Secretariat

Present

Rapporteur Group
B: Attendance List
style='mso-footnote-id:ftn30' href="#_ftn30" name="_ftnref30" title="">[30]

Name

Constituency

11 Oct

13 Oct

19 Oct

26 Oct

Jon Nevett - Rap B

Registrar C

Present

Alistair Dixon

CBUC

Present

Marilyn Cade - A

CBUC

Present

Danny Younger

NCUC

Present

Ken Stubbs

Registry C

Present

Sophia Bekele*

Nom Com

Present

Bret Fausett

ALAC

Absent

Present

Absent

Avri Doria

Interim Chair

Nom Com

Absent

Present

Staff

Denise Michel

Present

Liz Williams

Present

Glen de St. Géry

Present

style='page-break-before:always;mso-break-type:section-break'>

name="_Toc156718142">
name="_Toc36877732">Annex
Four -- Constituency Statements and Rapporteur Group Input

name="_Toc36877733">This
section includes the full set of Constituency Statements and Rapporteur Group
inputs for each Term of Reference.

1. Under the PDP
guidelines, each GNSO Constituency files a formal Constituency Statement. In addition to input from the Constituencies,
a Public Comment Period (found at
http://forum.icann.org/lists/gtld-policies-tor/) was announced and closed on 30
April 2006. No public comments were
received. The Taskforce made an
additional Call for Expert Papers. The
Call for Expert Papers closed on Friday 5 May 2006 with one response found at
href="http://www.icann.org/announcements/announcement-11apr06.htm">http://www.icann.org/announcements/announcement-11apr06.htm.

2. The Registries'
Constituency submitted its Statement in conformance with the PDP guidelines
style='mso-footnote-id:ftn31' href="#_ftn31" name="_ftnref31" title="">[31].

3. The Registrars'
Constituency submitted a draft position and then completed a formal vote on the
Statement after the deadline for submission of statements had passed.

4. The Intellectual
Property Constituency sought and received an extension for submission of their
Statement. The Constituency provided
some general introductory comments which included that "[The IPC] presents the
following position statement on elements of the Terms of Reference for this PDP
as our initial views. We look forward to
considering the views of other constituencies and working toward a mutually
acceptable recommendation. (2) IPC recognizes the value of consistency and
even uniformity among the agreements entered into by ICANN with the various
gTLD registries. However, it is a fact
that not all gTLD registries are comparably situated, with regard to size or
dominance, and it is not always appropriate to treat them as if they were. Consistency is only one of several factors
that should be taken into account in fashioning a policy regarding registry
agreements."

5. The Non
Commercial Users' Constituency in place of a formal Constituency Statement
submitted a set of preliminary positions.
The NCUC also submitted a very detailed additional set of comments
through the Rapporteur Group process.

6. The Business and
Commercial Users submitted a formal Statement on 31 May 2006.

7. The Internet
Service Providers' Constituency submitted a formal Statement on 6 June 2006.

clear=all style='page-break-before:always;mso-break-type:section-break'>

8.One response to the
Call for Papers was submitted from Mr Matt Hooker, President of
LowestPriceDomain, a domain name supplier found at
href="http://www.lowestpricedomain.com/">http://www.lowestpricedomain.com/. Lowestpricedomain.com is not listed as an
ICANN accredited Registrar or as a member of the Registrars' Constituency.

9. Under Section 7 d
1 of the Bylaws, "…the [Task Force] Representatives will each be responsible
for soliciting the position of their constituencies, at a minimum, and other
comments as each Representative deems appropriate, regarding the issue under
consideration."

10. The Sections below
set out the Constituency Statements in their entirety. In addition, work from each of the Rapporteur
Groups has been included in the analysis.

11. For clarity and to
understand the current situation with existing registry agreements in the
context of the Terms of Reference, Annex 3 prepared for the Issues Report has
been included as an easy reference. In
addition, the more comprehensive draft Comparison Table is also available
(found at
http://gnso.icann.org/drafts/draft-comparison-of-icann-registry-agreeme…). This document was produced in response to a request
from the GNSO Council through Task Force Chair Maureen Cubberley (found at
href="http://gnso.icann.org/correspondence/jeffrey-to-tonkin-27sep06.pdf">http://gnso.icann.org/correspondence/jeffrey-to-tonkin-27sep06.pdf).

12. A more detailed
table has been prepared and will be posted separately.

src="pdp-report-feb06-tfr-20Apr07_files/image002.jpg" v:shapes="_x0000_i1025">

name="_Toc37822890">CS:
name="_Toc24527796"> TOR 1a - 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.

RyC…
style='mso-bidi-font-style:normal'>"The Constituency believes that an attempt
to set a policy guiding renewal is not properly within the scope of a GNSO PDP.
style='mso-footnote-id:ftn32' href="#_ftn32" name="_ftnref32" title="">^{^[32]}

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>In general, the overall goal of this PDP
should be limited to a determination of what policies are (a) appropriate for
the long term future of gTLDs - specifically within the context of ICANN's mission
to preserve the stability and security of the DNS, and (b) relate to certain
specific issues identified below.

style='mso-bidi-font-style:normal'>In particular, the interests of the various constituencies that make up
the GNSO are diverse and may well, from time to time, be in conflict with the
goal of establishing a stable and effective contractual framework for
agreements between registries and ICANN. If a policy concerning renewals is
determined by the ICANN Board to be within the limitations specified above,
then such policy can, legitimately, only be set by the ICANN Board."

RC…
style='mso-bidi-font-style:normal'>"There should be a policy guiding renewals,
and we believe that the initial term of the registry agreement should be of
commercially reasonable length. We are
not opposed to renewing registry operator agreements, but oppose presumptive
renewals. The registry operator should justify its renewal and meet certain
qualifications and standards. Even if the registry operator meets these
standards, ICANN should still have the choice to seek out a bid at its discretion."

IPC…
"There should be a general presumption
that a registry operator that performed competently during the initial term of
the agreement should have a preferential status in any review that occurs prior
to renewal. This will promote continuity
and encourage long-term investment.
However, the presumption can be overcome if there have been significant
problems with the operator's performance (including non-compliance with terms
of the registry agreement) or if there have been significant intervening
changes in circumstance."

NCUC… "
style='mso-bidi-font-style:normal'>We believe that it is in the public interest
for there to be a renewal expectancy for parties who have been delegated generic top-level
domains. By "renewal expectancy" we mean that those who were originally assigned a top level domain should
retain the assignment unless there is a
significant problem, such as criminal activity, breach of contract, repeated
failure to meet service standards,
or serious noncompliance with applicable
ICANN rules and policies. In this view,
reassignment of the domain is punishment for malfeasance -- not an attempt to
run a periodic beauty contest to determine who is the "best"
operator.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>We believe that presumptive renewal as
described above is required for a long-term view of value-creation and
investment in a domain name and the associated infrastructure. Continuity and stable expectations about who
will be in control is required for the development of a community. This is
especially true for sponsored or nonprofit domains. Operators who succeed in creating value,
identity or a community around a domain should not have that taken out from
under them. They should be able to reap the benefits of their creation of
value, and be able to build on it into the future.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>We accept the importance of the principle of
competition. We do not, however, believe that it requires taking established
domains and throwing them up for grabs every five years or so when there
are no major problems with the operation of a domain. Registrar-level
competition helps to ensure that retail services associated with any gTLD
registry will be competitive, and cross-gTLD diversity will ensure users a
variety of naming alternatives (or
"intermodal" competition). Those are the most important forms
of competition. Reassigning a gTLD simply substitutes one operator with
exclusive control of the domain for another.
While this can put pressure on the incumbent to perform better in a
short-term time horizon, we believe that on the whole the amount of time and
resources spent on fighting over the control of the domain would outweigh the
prospective benefits. We also note that achieving improved performance from a
new operator can only be a promise, and that transfers of control inherently
involve costs and risks."

style='mso-bidi-font-style:normal'>

CBUC:…
style='mso-bidi-font-style:normal'>"It is the view of the CBUC that there
should be a set of policies that govern registry agreements, developed by the
GNSO, through a PDP process which provides for consultation with the community.
Included in those polices should be a policy that guides the decisions related
to renewal of registry agreements in the generic TLD space, whether these are
sponsored, open, restricted, or other categories. The elements of such a policy should include,
among other elements, establishing an environment which promotes competition
among registries and both competition and co-existence in the underlying
registry infrastructure. Policy
recommendations are the purview of the GNSO and will, once developed, be
subject to acceptance by the ICANN Board. To promote appropriate levels of
business certainty and investment, the registry agreement should be of a
reasonable length. It possible that an initial term might be between 7 and 10
years, with subsequent awarded terms of 5 years.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>In general, the CBUC members do not support
presumptive renewals for gTLDs; we find that presumptive renewal is
inconsistent with the objective of promoting competition. They do agree that there can be different
renewal standards, depending on characteristics of a registry. For instance, it
may be appropriate to have different renewal qualifications for sponsored TLDs
where there is a significant investment of a sponsoring organization in
policies for the TLD. Such a possibility
should be further examined during the PDP process.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>The policy should address the different
considerations of stability that are inherent in the role of a registry in
operating a TLD, and in providing underlying infrastructure for said
operation. Competition is important for
promoting the stability of the Internet through promoting diversity of
infrastructure. ICANN should therefore
take seriously the need for a considerable degree of "choice" in registry
infrastructure. In decisions on renewal
of contracts a key question should be how the renewal, or re-bid, contributes
to the investment in new registry infrastructures that can support further
competition at the registry infrastructure level.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>To restate, the CBUC does not support an
"automatic" or presumptive right of renewal. As the .net bid illustrated, there
are tangible benefits in having a competitive process, even if the TLD is
re-awarded to the incumbent, as happened with .net. In particular, significant improvements in
commitments and in pricing to registrars resulted from the competition process.
The CBUC again notes the appropriateness and the need for special consideration
of the circumstances of sponsored, due to their policy role as sponsoring
entities.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>Comparisons have been made with renewal
policies in other industries, especially telecommunications. While there are some common considerations
around renewal of contracts between these industries and registries, such as
recognition of the importance of business certainty, the presumption for
renewal in these industries arises because they involve capital-intensive
investments in very long-life assets and often include high licensing or
authorization fees of hundreds to millions of dollars, which is not the case
with gTLD registries. Many countries require additional provision of services
or investment, such as contributions to a universal service fund, or build out
in high cost areas, as a requirement to qualify for a license, and some
countries require a very strong failsafe provision before providing the
authorization or license. Similar
requirements are not imposed on gTLD registries.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>It should also be noted that a presumption
of renewal is not the norm for supply of services in most industries. If anything, there is a presumption of
competition for provision of services at the conclusion of a contractual term,
and provision of registry services to ICANN should be no different."

style='mso-bidi-font-style:normal'>

ISPCP: …"The ISPCPCP
Constituency opposes presumptive renewal of contracts as blatantly
anti-competitive. A registry should
provide so high a quality of service during the course of its contract that it
will be in a strong position to win an open competition for contract
renewal. Presumptive renewal provides a
disincentive to strive for excellence.
Furthermore, we consider the argument that without presumptive renewal
registries will not be motivated to make long term investments in
infrastructure development as utterly spurious.
They will in fact be highly motivated to make such an investment if they
wish to win renewal in open competition when their contracts expire. Sponsored TLDs may be an exception. In some cases registries with a limited
community have made a
substantial investment in policy development and implementation. It may be appropriate to hold these
registries to a different standard vis à vis renewal."

style='page-break-before:always'>

RGA^{^[33]}:
TOR 1a

1. Rapporteur Group
A (RGA) examined Terms of Reference 1, 2
and 5. This section sets out the initial
findings of the Group that met throughout the latter part of October and early
November 2006. At the full Task Force
meeting on 2 November 2006, this element of the RGA's report was discussed in
detail with limited agreement on the proposals made by the RGA.

2. The RGA report
said "the majority of those who participated [see the participation table
above] in the working effort agree that there should be a policy guiding
renewals and voted yes on the straw poll.
One participant [from the Registry Constituency] abstained from the
straw poll that there should be a policy guiding registry agreement renewal.

3. Under the current
conditions for existing registry agreements, there is presumption of renewal in
eleven of the sixteen registry agreements (for full details see the Annex 3
Issues Report table above).

4. Further work
needs to be done on establishing the status of support for a policy recommendation
about the presumption of renewal.

CS:
TOR
1b - Registry Agreement Renewal Conditions

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.

name="_Toc24533640">
name="_Toc12081042">
name="_Toc10607890">
name="_Toc8721475">RyC… "…
style='mso-bidi-font-style:normal'>for the reasons stated above, this is not a
proper question for this PDP.
style='mso-bidi-font-style:normal'>"

RC…
"…yes, the renewal terms
should be standard across all future registry agreements."

IPC…
style='mso-bidi-font-style:normal'>"…From comment (2) under "General Approach"
above regarding standardization. The IPC
recognizes the value of consistency and even uniformity among the agreements
entered into by ICANN with the various gTLD registries. However, it is a fact that not all gTLD registries
are comparably situated, with regard to size or dominance, and it is not always
appropriate to treat them as if they were.
Consistency is only one of several factors that should be taken into
account in fashioning a policy regarding registry agreements."

NCUC…
did not address this question
directly.

CBUC… "
style='mso-bidi-font-style:normal'>The CBUC is well aware that not all existing
registry agreements share the same rights of renewal, however, we do not
believe uniformity in this area is appropriate or necessary. We have noted that sponsored registries
require special consideration, due to their role as in developing a community
to support the launch of a TLD, the role in policy development and the delivery
of services to the "sponsoring community".
We do not support a "one size fits all" approach to this issue but would
suggest that renewal terms within the different categories of TLDs should be
consistent."

ISPCP… "
style='mso-bidi-font-style:normal'>The ISPCPCP Constituency holds that rights
of renewal should be standardized across all future agreements."

RGA:
TOR 1b

1. RGA considered
whether registry renewal provisions should be standardized across all registry
agreements. RGA examined the issues,
taking into account ICANN's Bylaw on discriminatory treatment that says, "ICANN
shall not apply its standards, policies, procedures, or practices inequitably
or single out any particular party for dISPCParate treatment unless justified
by substantial and reasonable cause, such as the promotion of effective
competition". (http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#II)

2. In addition, the
analysis provided by ICANN's Deputy General Counsel shows that there is no
single treatment of registry renewal across the existing agreements. For example, all seven of the sTLD (such as
.aero, .museum and .travel) have a presumption of renewal as do the latest
versions .com and .net. The remaining
.biz, .info and .org agreements, in their original form, have no presumption of
renewal. Those agreements have been
amended and the proposed new agreements can be found at
href="http://www.icann.org/announcements/announcement-24oct06.htm">http://www.icann.org/announcements/announcement-24oct06.htm. Those agreements contain provisions of
renewal expectancy.

3. Two possible
recommendations were considered by the group.
The first that renewal rights should be standardized for gTLD registry
agreements. The second that renewal
rights for registry agreements should be standardized, barring exceptional
circumstances such as where market dominance exists.

4. It is helpful to
consider the broader concept of licensing renewals found, for example, in the
World Bank's report on mobile license renewal
href="#_ftn34" name="_ftnref34" title="">^{^[34]} which says, in part, "…As technological
changes and convergence and technologically neutral approaches gain importance,
regulators and policy makers need to be ready to adapt and evolve licensing
procedures and practices to the new environment. […To] ensure regulatory certainty and ease
investors' concerns, [it is necessary to] codify a clear regime of license
renewal…, including renewal procedures, reasons for refusal to renew and
appeals to regulatory decisions, …adopt some varying degree of the principle of
renewal expectancy; strike the right balance between certainty in the renewal
process and regulatory flexibility, and engage in forward thinking and
planning".

5. In addition, the
Expert Materials
title="">^{^[35]}
prepared for the Task Force contain comprehensive information about licensing
renewal and discussion about commercially reasonable term lengths in a variety
of jurisdictions and across various industry sectors.

6. Further
discussion about the level of support for the proposed policy recommendation is
required to reconcile, for example, the Registry Constituency's position that
this area is outside the scope of the GNSO's policy development remit with that
of, for example, the Alistair Dixon Business Constituency, which argued that
style='mso-bidi-font-style:normal'>"…There have been suggestions in PDP05 and
PDP06 that there might be a need for different policies for renewal for new and
existing TLDs, especially over the question of whether there should be a rebid
at the end of a contract. My view is
that the competition questions are the same for both and that there should
either be a rebid at the end of the contract period or at least a review
style='mso-bidi-font-style:normal'>that considers whether there are competition
issues that would require a rebid. I
explain why below.

As
with most policy questions in area, there is not really a black and white
answer as to whether there should be a rebid for new or existing TLDs. In general, neither a small existing registry
nor a new entrant is likely to cause a competition concern in the short term.
However, that may not be the case in the medium to long term. The key questions
are (as for existing):

- what share of the total market does the registry account for?

- are there any substitutes that exist for users of that registry that they
could switch to?

- are the switching costs significant?

- Does the registry have the ability to unilaterally increase prices or degrade
service without losing customers?

- Do users of the registry have countervailing market power?

What
these questions highlight is that even if there are no competition concerns in
the short term, there might be in the longer term. Consider for example a TLD that is specific
to a particular industry. Initially,
when the TLD is first offered to users the TLD will have of course have limited
users. However, over time it may prove to be the case that a credible operator
in that industry must use that TLD. In
that case, conferring a perpetual monopoly might cause a competition
concern. That is why the rule rather
than the exception in service markets (eg government and corporate contracts)
is periodic rebids.

One
of the concerns in the Council about a policy of rebids seems to be about
whether this provides sufficient incentives for bidding in the first place and
investment in the long term. The way to
manage such concerns is making sure that the length of the contract is
sufficient for the provider to cover costs and make a profit. For a service like a registry, which I don't
think is particularly capital intensive (as compared to say a
telecommunications or electricity network) - though I might be wrong - 10 years
should be plenty of time to recover costs.

A second concern seems to be about whether it is worth the bother to have a
rebid, based on an argument that, despite what I have said about competition
risks, any such risks are minimal. The
problem is that there is no guarantee.
The solution might be to have a review of the contract prior to a
decision to renew that includes specific consideration of whether there are any
competition concerns. This is precisely
what is being done in NZ in relation to cellular spectrum: there is a policy of
renewal but this is subject to a "case-by-case review", ie if it's
found that there is a competition problem renewal is off and the spectrum
rights will be put up for auction"
href="#_ftn36" name="_ftnref36" title="">^{^[36]}.

7. One further
element of the discussion is "commercial reasonable term lengths". A variety of different arguments were made
for various term lengths. This is a
question that needs to be tested through, for example, the upcoming public
comment period for the Task Force Report and through reference to other
industries.

CS: TOR 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.

RyC…
"…consensus policy limitations are appropriate only to the extent that
they may undermine the interoperability, security, and stability of the
Internet and DNS. Any determination of the appropriateness of particular
limitations should be limited to review of their impact on these three
subjects."

RC… "…
style='mso-bidi-font-style:normal'>there are some limitations in registry
agreements that may be appropriate, such as the price of registry services and
fees that the registry must pay to ICANN.
Beyond these, there should not be contractual limitations on consensus policies
in registry agreements."

IPC… "
style='mso-bidi-font-style:normal'>to the extent feasible, the terms of
registry agreements should be aligned with policies adopted by the GNSO Council
and approved by the Board for gTLD registries generally. The necessity for any deviations should be
explicitly stated and justified in the agreement."

NCUC…
style='mso-bidi-font-style:normal'> "This is an issue that NCUC feels has not
been discussed or debated adequately. One point is that we must distinguish
carefully between the problems raised by one dominant operator's registry
agreement (.com) and policies that are appropriate as a general rule for
all registries. We look forward to
listening to the views of other constituencies and the public on this
question. We believe that existing
sponsored domains should retain the policy-making authority. We say this not
because we support the concept of sponsored domains per se, but because we
support greater diversity and decentralization of policy making authority."

style='mso-bidi-font-style:normal'>

CBUC… "
style='mso-bidi-font-style:normal'>Consensus policies are recommendations that
are built on the hard work of the community to reach agreement. It is not
simple to reach consensus, and when such policies are developed, it is in the
context of the participation of all parties, including the active and full
engagement of the registries themselves, as well as other constituencies. The
CBUC believes that consensus policies are appropriate. Consensus policies should be applicable from
the time of renewal of the contract.
This would ensure that they were not applied retrospectively and would
give the registry considering whether to seek renewal the option of not doing
so if it had major concerns in relation to consensus policies.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>Overall, the CBUC does not see a rationale
for using contractual terms to limit consensus policy in registry
agreements. The CBUC would like to hear
what justifications exist for creating exceptions to consensus policy. The CBUC
is very concerned that to date, ICANN staff have sometimes chosen to create
contractual terms, rather than taking the responsibility of raising an issue to
the GNSO and seeking guiding policy."

style='mso-bidi-font-style:normal'>

ISPCP… "The ISPCPCP Constituency maintains that every registry contract should
in all cases require that registry to conform to consensus policies developed
by ICANN. These policies are developed
by the community of all stakeholders, of which the registries are full members;
indeed, in the policy development process of the GNSO, the registry
constituency has been given a double vote."

RGA:
TOR 2a

1. RGA considered
the relationship between registry agreements and the applicability of consensus
policies.

2. The Registry
Constituency [David Maher] reiterated its concern that this discussion is not
within the scope of the GNSO. Referring
to the Annex 3 table from the Issues Report found above it is clear that the
application of consensus policies is limited in each and every existing
registry agreement.

3. The General
Counsel's office, in its 28 September 2006 correspondence to the GNSO Chair,
set out a full explanation about the nature of consensus policies.

'Since there has
been no uniform language on consensus polices included in each ICANN registry
agreement, this has been the subject of bilateral negotiations between ICANN
and each registry operator and sponsor.
ICANN's GTLD registry and registrar agreements provide that under
certain circumstances policies that are recommended by the GNSO and adopted by
the Board can create new binding obligations on registries and registrars. All of ICANN's current GTLD agreements
include limitations on the topics that may be the subject of such binding new
obligations, and the procedures that must be followed in order to create
them. For example, Section 3.1(b)
of the .JOBS Registry Agreement (as an
example of the framework for ICANN's recent registry agreements)
<http://www.icann.org/tlds/agreements/jobs/jobs-agreement.htm#3.1>provid…
as follows:

[3.1](b) Consensus Policies.

(i) At all times during the term of this
Agreement and subject to the terms hereof, Registry Operator will fully comply
with and implement all Consensus Policies found at http://www.icann.org/general/consensus-policies.htm,
as of the Effective Date and as may in the future be developed and adopted in
accordance with ICANN's Bylaws and as set forth below.

(ii) "Consensus Policies" are those
specifications or policies established (1) pursuant to the procedure set forth
in ICANN's Bylaws and due process, and (2) covering those topics listed in
Section 3.1(b)(iv) below. The Consensus Policy development process and
procedure set forth in ICANN's Bylaws may be revised from time to time in
accordance with ICANN's Bylaws, and any Consensus Policy that is adopted
through such a revised process and covering those topics listed in Section
3.1(b)(iv) below shall be considered a Consensus Policy for purposes of this
Agreement.

(iii) For all purposes under this Agreement, the
policies identified at http://www.icann.org/general/consensus-policies.htm
shall be treated in the same manner and have the same effect as "Consensus
Policies."

(iv) Consensus Policies and the procedures by
which they are developed shall be designed to produce, to the extent possible,
a consensus of Internet stakeholders. Consensus Policies shall relate to one or
more of the following: (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 dISPCPutes regarding
the registration of domain names (as opposed to the use of such domain names).
Such categories of issues referred to in the preceding sentence shall include,
without limitation:

(A) principles for allocation of registered names
in the TLD (e.g., first-come, first-served, timely renewal, holding period
after expiration);

(B) prohibitions on warehousing of or speculation
in domain names by registries or registrars;

(C) reservation of registered names in the TLD that
may not be registered initially or that may not be renewed due to reasons
reasonably related to (a) avoidance of confusion among or misleading of users,
(b) intellectual property, or (c) the technical management of the DNS or the
Internet (e.g., establishment of reservations of names from registration);

(D) maintenance of and access to accurate and
up-to-date information concerning domain name registrations;

(E) procedures to avoid disruptions of domain name
registration due to suspension or termination of operations by a registry
operator or a registrar, including procedures for allocation of responsibility
for serving registered domain names in a TLD affected by such a suspension or
termination; and

(F) resolution of dISPCPutes regarding whether
particular parties may register or maintain registration of particular domain
names.

(v) Registry Operator shall be afforded a reasonable period of time
following notice of the establishment of a Consensus Policy or Temporary
Specifications or Policies in which to comply with such policy or
specification, taking into account any urgency involved.

name="_Toc36877735">The
.JOBS registry operator (Employ Media) therefore has agreed in advance to
follow any ICANN "Consensus Polices", which are defined as polices
that are developed pursuant to the procedure set forth in the ICANN Bylaws and
which relate to the categories of issues specified in the agreement, e.g. prohibitions
on speculation in domain names by registries, maintenance of and access to
"WHOIS" data, resolution of dISPCPutes regarding registrations,
etc. The .JOBS registry operator
accordingly would not be obligated to comply with any ICANN policy that is not
developed according to the policy-development procedure specified in the Bylaws
or that does not relate to one of the limited topics (the so-called
"picket fence") for Consensus Policies.

name="_Toc36877736">Other
ICANN registry agreements and the Registrar Accreditation Agreements contain
similar language on the applicability of Consensus Policies. For example, the Registrar Accreditation
Agreement and the current .BIZ (2001), .COM (2001), .INFO (2001), .NAME (2001),
.ORG (2002), and .PRO (2002) registry agreements <http://www.icann.org/registries/agreements.htm>
all specify that any Consensus Policy must be supported by a written report
with certain minimum required elements and must be recommended by at least a
two-thirds vote of the supporting organization's Council (see, e.g. .BIZ
section 4.3.1
<http://www.icann.org/tlds/agreements/unsponsored/registry-agmt-11may01.htm#4.3.1>)."

1. The RGA
considered three separate options: that
consensus policy limitations are inappropriate; that consensus policies should
always be applied to gTLD registries and that the present limitations to
consensus policies are appropriate and should continue.

2. There was divided
support for the options and there was insufficient participation to indicate a
fuller view from the RG.

CS:
TOR 2b:
Delegation of policy making

RyC…
"…it would be legitimate to examine
whether the diversity of sponsored TLD policy making poses a threat to the
interoperability, security, and stability of the Internet and DNS and if so,
under what circumstances should changes be applied."

style='mso-bidi-font-style:normal'>

RC… "…
style='mso-bidi-font-style:normal'>delegation of the GNSO's policy development
responsibilities to outside parties such as a registry operator is
inappropriate. The Registry Operator should have the authority to modify its
charter, in accordance with the terms of change in its agreement with ICANN,
but should have no specific policy making responsibility outside of this area."

IPC…
style='mso-bidi-font-style:normal'>"…such delegation is appropriate only to the
extent it does not conflict with ICANN policies (or is specifically justified,
see preceding answer). The
gatekeeping/charter enforcement role of sponsored TLD operators should be given
paramount importance".

NCUC… made
no further direct comment on this section.

CBUC…
style='mso-bidi-font-style:normal'>"The CBUC is a strong supporter of the
function of sponsored TLDs, and has seen the evolution of this concept as a
very positive step for the introduction of new TLDS in a way that we believe
can contribute to limiting the need for duplicate and non productive protective
registrations. We support the role of the sponsoring entity in the development
and implementation of certain policies and the continued need to publish these
proposed policies at the time of the registry application for consideration by
the broad community.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>It is possible that there needs to be more
clarity in what limitations on policy making exist for sponsored TLDs, but in
general, we support the delegation of certain limited policy making
responsibilities, keeping in mind the need to maintain end to end
interoperability, and the security and stability of the Internet, and the need
to have full transparency on what the policy scope is, and what limitations
exist, and what remediation mechanisms ICANN has. Sponsored gTLDS should not be
exempt from consensus policy, for instance.
And of course, policies need to be consistent with ICANN bylaws."

ISPCP…
style='mso-bidi-font-style:normal'>"The ISPCPCP recognizes that sponsored TLDs
may need to establish policies regarding membership in their respective
communities. These policies should be
developed according to a well-defined, transparent process in cooperation with
the GNSO."

RGA:
TOR 2b

1. RGA considered
whether the delegation of certain policy-making responsibility to sponsored TLD
operators is appropriate, and if so, what if any changes are needed.

2. The Registry
Constituency representative [David Maher] expressed a reservation that any
discussion of this area of the Terms of Reference was not within the scope of
existing sponsored TLD agreements.

3. A draft
recommendation was made but needs further discussion with the full Task Force
on "the charter and scope of a sponsored community; the eligibility to be in
the 'sponsored' category; eligibility for a particular name and the concept of
conflicts and a dISPCPute process as a service to the sponsored community."

3. The following
references set out each Sponsored TLD agreement and specify the existing
conditions for delegated policy making
authority.

.5. aero sponsorship
agreement at Annex 2 of .aero registry agreement
href="http://www.icann.org/tlds/agreements/aero/sponsorship-agmt-att2-20nov01…">(http://www.icann.org/tlds/agreements/aero/sponsorship-agmt-att2-20nov01…)

6. .cat charter
agreement at Appendix S of the .cat registry agreement
href="http://www.icann.org/tlds/agreements/cat/cat-appendixS-22mar06.htm">(http://www.icann.org/tlds/agreements/cat/cat-appendixS-22mar06.htm)

7. .coop sponsorship
agreement at Attachment 2 of the .coop registry agreement
href="http://www.icann.org/tlds/agreements/coop/sponsorship-agmt-att2-06nov01…">(http://www.icann.org/tlds/agreements/coop/sponsorship-agmt-att2-06nov01…)

8. .mobi charter
agreement at Appendix S of the .mobi registry agreement (
href="http://www.icann.org/tlds/agreements/mobi/mobi-appendixS-23nov05.htm">http://www.icann.org/tlds/agreements/mobi/mobi-appendixS-23nov05.htm)

9. .museum
sponsorship agreement at Attachment 2 of the .museum registry agreement
href="http://www.icann.org/tlds/agreements/museum/sponsorship-agmt-att2-20aug…">(http://www.icann.org/tlds/agreements/museum/sponsorship-agmt-att2-20aug…)

C S:
TOR 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)

RyC… "…Price controls are another example of a subject that is not properly
within the scope of GNSO proceedings and this PDP. It is clearly improper for
the various constituencies comprising the GNSO to be in the position of
resolving their conflicting interests by setting price policies for another
constituency"
name="_ftnref37" title="">^{^[37]}
style='mso-bidi-font-style:normal'>.

RC… "…if
a TLD has Market Power or Pricing Power, then there should be price controls
and cost justification requirements for any price increases. All registries should provide equitable
pricing opportunities for all registrars and at least six months notice before
any price increase."

IPC… "…there should be a general
presumption against price caps in registry agreements. Exceptions to this presumption should be
explicitly justified. There should be a
general presumption in favour of "price controls" aimed at preventing
discrimination among registrars; exceptions should be explicitly
justified. Also favored should be "price
controls" aimed at provided transparency and equal access to information about
pricing policies."

NCUC… "…
style='mso-bidi-font-style:normal'>we recognize that price caps can be
justified as a way of protecting consumers in markets with high switching
costs. Domain name registrations do have high switching costs. Rather than making specific policy
recommendations, however we make these starting observations:

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>a) We must not assume that ICANN contracts
are the proper mechanism

style='mso-bidi-font-style:normal'>for price controls. Regulatory authorities in national
governments have some ability to respond to this problem, either through
antitrust laws or through sector-specific regulations. We believe that the pros
and cons of a global vs. national approach should be debated and discussed in
this PDP.

style='mso-bidi-font-style:normal'>b) The case for or against price controls
must recognize the difference between the interests of end users/registrants
and the interests of intermediaries in the domain name supply chain, and not
let the latter speak for the former.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>c) Permitting increases in the price of .com
registrations may have the salutary effect of encouraging users to migrate to
new gTLDs and discouraging the concentration of users in .com.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>d) Permitting registries to sell
registrations for much longer terms, or registrations that do not expire, is
another way to handle the lock-in problem in a way that helps consumers."

style='mso-bidi-font-style:normal'>

CBUC… "
style='mso-bidi-font-style:normal'>The CBUC supports the concept of having
pricing guidelines, and in particular, a ceiling above which prices cannot be
raised, without public notice and the presentation, to the board, of
justification for such increases. This
is particularly the case for TLD operators that are able to price substantially
above cost, i.e. that are in a dominant market position, or that are able to
use the dominant market position in other ways that may create other barriers
to market success by competitors. This
is not an undue burden upon a registry. It may be appropriate to have certain
restrictions that apply to registries of certain size or certain
characteristics - such as being a sponsored gtld, or being a very small TLD, or
being a very large TLD with dominance or market power. Fairness in competition does not always
equate to "equal" treatment. When
prices are raised, there should be sufficient notice to the community in a
public process."

ISPCP… "
style='mso-bidi-font-style:normal'>The ISPCPCP Constituency advocates price
controls, narrow contractual limits beyond which a registry cannot raise its
prices without appeal to and review by the ICANN board. The consideration process for price rises should
be open and transparent. The entire
ICANN community should be notified and detailed economic justifications should
be well documented and open to public examination. A registry holds a public trust and is thus
liable to public scrutiny, especially in the matter of a change of contractual
terms."

style='page-break-before:always'>

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.

RyC… "…If there are objective measures, the GNSO is not the appropriate body
to determine them."

RC… "
style='mso-bidi-font-style:normal'>...a registry must justify any price
increases if there are price caps in the registry agreement. Such justification should be objectively
evaluated by an independent 3^rd party".

IPC… "…this should be handled on case by case basis in situations in which
the presumption against price caps is overcome."

NCUC did
not provide any further specific comments relating to this section.

CBUC…
style='mso-bidi-font-style:normal'>"The CBUC believes that it is possible for
such objective measures to be developed and taken into account in approving an
application for a price increase when a price cap exists. In general, to date,
the responsibility for developing a rationale, and supporting argumentation has
rested with the registry, and some limited openness has been given to accepting
comments from others on the rationale.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>In broad terms, the onus should be on the
registry to demonstrate that the price cap results in the registry being forced
to price below cost. The definition of
cost should include an allowance for a reasonable rate of return, taking into
account the degree of risk inherent in the registry business.

style='mso-bidi-font-style:normal'>Establishing a framework upon which to base
such decisions would be helpful. To support that framework development by the
GNSO, it would be helpful for ICANN to provide financial support to the GNSO to
consult external independent experts to advise the GNSO in its consideration of
these issues. The CBUC has provided a
suggestion for such an approach in its introductory statement to this comment."

style='mso-bidi-font-style:normal'>

ISPCP…
style='mso-bidi-font-style:normal'>" The ISPCPCP Constituency believes
that it is possible to develop objective measures for the justification of
raising registry fees. However, given
that there is a wide diversity of registries' situations, these should not be
too rigid. The operative principle here
is that the burden of the proof is on the registry and the Board, in
representing the best interests of the Internet community, are the final
arbiters."

style='mso-bidi-font-style:normal'>

RGB:
TOR 3a & 3b

1. RGB considered Term of Reference 3, 4 and
6. The following section sets out the
discussion on TOR 3a & 3b.

2. There appears to
be interest in achieving a policy related to pricing for registry
services. The intent of such a policy
would be to provide more certainty for users, protect them against the high
switching costs of domain names, and protect them against potential
monopolistic pricing by dominant actors.
This interest in protection is even greater in the face of a
predominance of renewal expectancy contracts in that, in such cases, the market
is not constrained through competitive bid processes. Another theme of any policy would be to
continue the system of equitable pricing for registrars.

3. Unlike a
telephone number in the United States and many other countries, there is no
portability of domain names from one registry to another. The registrant of rapporteur.biz for example,
must remain with NeuStar and may not port that name to another registry. Due to the competitive registrar market,
there is an opportunity to transfer the name from one registrar to another, but
not from one registry to another.
Registrants make substantial investments in their domain names and would
need to make similar investments if they were forced to transfer to a new
domain name. Therefore, many registrants
are "locked-in" to a specific name with a specific registry, as the costs of
switching to a different name (even the same second level name with a different
TLD) would be cost prohibitive.

4. Protections for
new registrants also are important when a registry is dominant - enjoys a
position of market power (i.e. the registry occupies a market position such
that it is able to set prices in excess of cost and sustain this without loss
of market share). Due to the lack of
market constraints on such dominant actors, set contractual pricing provisions
may be warranted. Similarly, when a
registry is not dominant, many posit that there should not be pricing
provisions with regard to new registrations because the market itself will
constrain non-dominant registries and protect the end users, but that there
should be pricing constraints on domain name renewals.

5. If there are
pricing provisions, the issue arises as to how such prices are changed if
necessary. While at least one
constituency believes that a governmental competition authority might be
involved in the setting or increasing of contractual pricing provisions with
registries, others believe that the global nature of gTLD registration means
that the jurisdictional and timeliness issues associated with such reviews
would make it unworkable.

6. Some
constituencies argue that prices may be increased if there is cost
justification, which should be determined by ICANN or a third party contractor
(e.g. accounting firm). The registries
argue that they need to be able to respond quickly to the changes in the
market. They and the NCUC do not
recommend a long and expensive cost justification process.

7. There also has
been much discussion related to "differential pricing" of domain names at the
time of initial registrations and renewal.
There is strong support that any policy should address such issues for
the protection of registrants. The
general principle should be that there is no differential pricing. The proposed concerns raised in the public
comment period related to differential pricing in the draft .biz, .info, and
.org registry agreements may be addressed if there were set pricing provisions
in the contracts.

8. During the
discussion of the Rapporteur Group, two potential policy options surfaced as
potential consensus policies.

9. Option 1: When a registry contract is up for renewal,
there should be a determination whether that registry is market dominant. That determination should be made by a panel
of competition experts including competition lawyers and economists. This panel would operate similarly to the
panel that reviews the security and stability implications of new registry
services.

10. If the panel
determines that there is a situation of market power, then the registry agreement
must include a pricing provision for new registrations, as currently is
included in all of the largest gTLD registry agreements. If the panel determines that there isn't
market power, then there would be no need for a pricing provision related to new
registrations, as is the practice in the recent round of sTLD registry
agreements.

11. Regardless of
whether there is market dominance, consumers should be protected with regard to
renewals due to the high switching costs associated with domain names. Therefore, this policy recommendation is to
continue the system of pricing provisions in the current unsponsored TLD
agreements with regard to domain name renewals.

12. The price for new
registrations and renewals for market dominant registries and for renewals for
non-market dominant registries should be set at the time of the renewal of the
registry agreement. Such a price should
act as a ceiling and should not prohibit or discourage registries from
providing promotions or market incentives to sell more names. In agreeing on such a price ceiling, ICANN
should consider the domain name market, the price of names in the prior
agreement, the market price in cases of competition through rebids, and the
specific business plans of the registry.

13. The pricing
provision should include the ability for an increase if there is cost
justification for such an increase, as is required in the current registry
agreements with pricing provisions. Such
increases should be evaluated and approved by a third party entity, such as an
accounting or financial analyst firm.

14. Differential
pricing between domain names should be prohibited whenever there is a set
price/price cap and should be permitted when there isn't such a price
constraint. In other words,
non-dominant registries may differentially price for new registrations, but not
for renewals. Dominant registries may
not differentially price for new registrations or renewals.

15. Finally, as is the
current practice, all registries should provide equitable pricing opportunities
for all registrars and at least six months notice before any price increase.

16. Option 2: The NCUC has argued that it is premature to
formulate policy in the area of pricing without having had the benefit of an
intensely focused study on this topic.
They believe that a new PDP is required to address the specific issue of
price controls. ("We believe that
existing price caps should be left in place for the short term, and another,
separate PDP inaugurated on methods and criteria for changing, raising or
eliminating price caps in the future.")

17. Thus, another
option is to keep the status quo by encouraging ICANN to continue with existing
pricing provisions and initiating a targeted PDP on this issue alone taking
into account the upcoming economist's report

(http://www.icann.org/minutes/resolutions-18oct06.htm).

name="_Toc34982542">CS: TOR
name="_Toc24527807"> 4a & 4b - ICANN fees & budgeting
process

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.

RyC… "…The
inappropriateness of this question can best be demonstrated by rephrasing it:
"Should there be a policy guiding [registrar] [ISPCP] [any other constituency]
fees to ICANN?"

RC… "…
style='mso-bidi-font-style:normal'>yes, there should be a policy guiding
registry fees to ICANN. The policy
should include a requirement that all ICANN fees charged to the Registries be
borne by the Registries themselves and not passed on to third parties."

IPC… "…the presumption should be that registry fees paid to ICANN (above a
modest base amount related to ICANN's costs) should be proportional to the size
of the registry; deviations from this presumption should be explicitly
justified."

style='mso-bidi-font-style:normal'>

NCUC… "…the
fees and budget of ICANN are policy issues in and of themselves. Control of the
purse strings is one of the most important forms of leverage over policy. NCUC believes that ICANN fees should be
applied to registries on a uniform basis
and not individually negotiated. This is important for the accountability of
ICANN as well as for fairness and the independence of registries."

style='mso-bidi-font-style:normal'>

CBUC…
style='mso-bidi-font-style:normal'> "There should be a policy guiding registry
fees to ICANN. Among those elements should be that staff does not add in
additional fees for services or programs that are not already an approved part
of the ICANN Operational Plan and Strategic Plan. Neither Registries nor ICANN
should use the registry negotiation process to establish new charges to support
non registry services.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>Registry fee negotiations should also not be
used to create undue financial dependence upon a single registry, at the
expense of destabilizing ICANN's budget when payment is delayed, or
withheld. Fees - in structure, in
purpose, and in amount -- should be published for public comment as part of the
registry award process. When the
Operational Plan and Strategic Plan process creates a form of fee that is
deemed by the community, based on public comment process and support from the
stakeholders to be part of ICANN's budget, such fees may include elements that
are then made part of the registry fee.
The rationale that has been practiced in the past of allocating
different amounts of "special fees" to different registries has not been transparent,
and should be made so by ICANN."

style='mso-bidi-font-style:normal'>

ISPCP… "
style='mso-bidi-font-style:normal'>The ISPCPCP Constituency favors the development of policy regarding
registry fees paid to ICANN. Fees must
be uniform across registry contracts.
ICANN must make a convincing case for any change to fees, based on its
operating and strategic plans. The
process of raising fees must be open and transparent."

style='page-break-before:always'>

4b. Determine how ICANN's public budgeting
process should relate to the negotiation of ICANN fees.

RyC… "…only
the ICANN Board can determine how its budgeting process should relate to the
negotiation of any fees charged to any constituency."

RC… "…all
ICANN fees charged to the Registries should be borne by the Registries
themselves and not passed on to third parties.
Any registrar obligation to ICANN should be approved by registrars during
the public budgeting process pursuant to the terms of the Registrar
Accreditation Agreement and should not be assessed by ICANN indirectly through
the registries."

IPC… "…
style='mso-bidi-font-style:normal'>safeguards should be introduced to minimize
the risk that registries contributing dISPCProportionately large fees to
ICANN's budget will be able to exercise dISPCProportionate control over
budgeting decisions. ICANN's budgeting
process should give priority to input from GNSO and its constituencies (at
least so long as fees derived from gTLD registrations provide the bulk of
ICANN's funding), and particularly to user constituencies as the ultimate
source of ICANN's funds (i.e., gTLD registrants)."

NCUC… offered no further comments on this
Term of Reference.

CBUC… "The
public budgeting process must be transparent, and provide sufficient detail
that the community understands the expenses that ICANN is proposing, and the
various forms of revenue/income that can meet that budget."

ISPCP…
style='mso-bidi-font-style:normal'>"
style='mso-bidi-font-style:normal'>See 4a."

RGB:
TOR 4a & 4b

1. RGB examined TOR
4a and 4b on whether there should be a policy guiding registry fees to
ICANN. The group decided that there
should be a policy or guidelines regarding registry fees to ICANN.
Individual negotiations of such fees create a problematic negotiating position
between ICANN and the registries and hampers ICANN's accountability. Achieving certainty in the process would
enable more effective business planning for both registries and ICANN.

2. Furthermore, such
a policy or guidelines should ensure equitable treatment of the
registries. Understanding that equitable treatment is not the same as
equivalent treatment, similarly situated registries should not be treated
differently. Any deviation from true consistency needs to be justified in
the interest of fairness to the registries and accountability of ICANN.
This is necessary to avoid arguments that ICANN has exerted undue influence
over an individual registry or has given a registry preferential treatment in
other terms of the agreement in exchange for generous payments to ICANN.

3. Policy Recommendation - In order to
improve ICANN accountability and effective business planning by registries,
ICANN staff should immediately implement a system of ICANN fees from registries
that avoids individual negotiations of ICANN fees and provides consistency
unless there is established justification for dISPCParate treatment.

clear=all style='mso-special-character:line-break;page-break-before:always'>

4b. Determine how ICANN's public budgeting
process should relate to the negotiation of ICANN fees.

1. The use of
individually negotiated registry contracts to collect fees from registrars
without input from registrars is problematic from at least a registrar and an
ICANN accountability perspective. Increasing budgetary transparency and
accountability are laudable goals of any policy, especially considering the
newly approved Joint Project Agreement between ICANN and the U.S. Department of
Commerce.

2. ICANN fees should
be determined by ICANN's budgeted costs and approved operational and strategic
plans. This will assist in promoting
transparency and accountability in the setting of budgets and help ensure that
ICANN fees relate to ICANN's actual costs.
This requires that ICANN's operational and strategic plans and budget
are approved prior to fees being set.
ICANN fees would then be based on the approved budget.

3. With that said,
it is clear that ICANN's budgeting process is extremely large and complex and
is worthy of detailed analysis and review in a separate multi-stakeholder
process.

4. Option - The ICANN Board should
establish a Task Force or Advisory Committee to examine budgeting issues,
including the manner and allocation of revenue collection, budget oversight,
and budget approval processes. This
group should solicit and review public comments on the issues.

CS: TOR 5
-- Uses of registry data

name="_Toc36877738">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.

RyC…
style='mso-bidi-font-style:normal'>"…The answer to this question requires
recognition that laws governing the capture and use of data vary around the
world. Any policy on this subject should be sensitive to the need for a
registry to conform to the laws of the jurisdiction where it is located".
style='mso-footnote-id:ftn38' href="#_ftn38" name="_ftnref38" title="">^{^[38]}

RC… "...there should be a policy limited the use of Registry data to just
the purpose for which it was collected".

IPC…
style='mso-bidi-font-style:normal'>"…the general rule should be that gTLD registry data may be used
for any lawful purpose. For registry
data that consists of personally identifiable information, a modified rule may
be required, which permits its use for purposes not incompatible with the
purpose for which it was collected, and which takes into account other public
policy interests in use of the data. Use
of gTLD registry data by the registry itself for the development or support of
new registry services should generally be subject as well to the procedures for
new registry services adopted by the GNSO Council and approved by the Board for
gTLD registries. Deviations from the above general principles should be
explicitly justified."
style='mso-bidi-font-style:normal'>

NCUC… "…the
privacy aspects of this issue need to be raised and discussed. As a starting point, we oppose
non-discriminatory access to registry traffic data. It would make Internet users' activities an
unending target of data mining".

CBUC… "There
should be policies regarding the use of registry data for purposes other than
that for which it was collected. Thus, if data about end users is collected
during a registrar/registry interaction in order to complete a transfer, or
some other process involving end users, there are very limited situations where
there would be any collection of data by a registry, given the "arms length"
relationship between registrants and registries, e.g. the intermediary role of
the registrar in these interactions.

style='mso-bidi-font-style:normal'>All registries should be subject to the
process for approval of new registry services, without exception. The CBUC was
involved, as were all constituencies in the development of a balanced set of
procedures to deal with the approval of new registry services. If further refinements are needed in this
policy or indeed any other consensus policy, or where there is a lack of policy
in a critical area, as has been suggested by the ICANN staff from time to time,
then it is the responsibility of the ICANN staff to present a recommendation to
the GNSO, noting the areas of clarification needed. And the GNSO should be
asked for expedited response in such circumstances,

style='mso-bidi-font-style:normal'>Overall, the purpose of collecting such data
should be limited to the fulfillment of the business functions within the
delivery of registry services-e.g. the purpose for which the data is gathered."

ISPCP… "
style='mso-bidi-font-style:normal'>The ISPCPCP Constituency strongly recommends the establishment of policy
regarding the use of registry data for purposes other than the execution of
registry operations as required by contract.
This includes account information and usage data (e.g. the frequency
with which a name is looked up in the DNS).
All proposed use of registry data for extra-operational purposes must be
subject to ICANN approval according to a process similar to that for approval
of new registry services."

style='page-break-before:always'>

5b Determine whether any policy is necessary to
ensure non-discriminatory access to registry data that is made available to
third parties.

RyC…
style='mso-bidi-font-style:normal'>"…this is also an area where local law must
be considered".

style='mso-bidi-font-style:normal'>

RC… "
style='mso-bidi-font-style:normal'>…there should be a policy limiting the use
of Registry data to just the purpose for which it was collected. To the extent that this purpose includes
sharing the data with third parties, it should be made available on a
non-discriminatory basis".

style='mso-bidi-font-style:normal'>

IPC… "…
style='mso-bidi-font-style:normal'> There should be a mechanism for
distinguishing between proprietary and non-proprietary registry data, and
non-discriminatory access should be guaranteed to the latter but not the
former. This mechanism could take the
form of a policy spelled out in the agreement; a procedural step in the
consideration of proposed new registry services pursuant to ICANN polices; or
both. Deviations from this general rule should be explicitly justified."

style='mso-bidi-font-style:normal'>

NCUC had
no further comments to add on this part.

CBUC…
style='mso-bidi-font-style:normal'>"In general, the CBUC supports the need for
non-discriminatory access to registry ata that is made available to third
parties, or that is used by the registry for any purpose other than that for
which the data is collected. In this
question, there is no definition of "registry data", and we would note that is
a term that is broader than "traffic data".
If there is a rationale not to make such data available, it should be
the responsibility of the registry to make the case as to why restrictions are
necessary.

style='mso-bidi-font-style:normal'>

style='mso-bidi-font-style:normal'>Traffic data itself, depending on what it
entails or is used, is a sensitive area. The CBUC is concerned that a registry
may have a unique and unfair ability to exploit traffic data in ways that may
limit the development of other services or byproducts by other third parties.
Since the traffic data is available to the registry by virtue of their sole
source contract with ICANN, the CBUC believes that there should be appropriate
access to traffic data, when such traffic data is aggregated, and gathered by
the registry. In the well-known telephone world, users are used to being able
to get "white pages" from different sources, not just the "phone company". This
happens because the "data" is required to be made available at
non-discriminatory terms and conditions and for only a cost recovery fee in
order to promote competitive outcomes."

style='mso-bidi-font-style:normal'>

ISPCP… "
style='mso-bidi-font-style:normal'>The ISPCPCP Constituency believes non-discriminatory access to registry
data that is made available to third parties is essential."

RGA:
TOR 5a & 5b

1. RGA examined TOR
5a and 5b and used, as a starting point, the 25 May 2001 .com Registry
Agreement definition of registry which says: "…Registry Data" means all
registry Database data maintained in electronic form in the Registry Database
and shall include Zone File Data, all data used to provide Registry Services
submitted to registrars in elections form and all other data used to provide
Registry Services concerning particular domain name registration or name
servers maintained in electronic form in the Registry Database." All ICANN registry agreements can be found
at http://www.icann.org/registries/agreements.htm.

2. During the
Rapporteur Group's work, this definition was used and included consideration of
traffic data. Traffic data is referenced
in the new .info, .org and .biz registry agreements and allows the Registry
operator commercial use of and collection of traffic data regarding names and
non-existent names for a variety of purposes, including the sale of
domain name, but also for various identification of concerns about
security. Registry's collect and use traffic data as a part of their
normal commercial operations to manage their customer database and to develop
new services for their customers. The
only data that ICANN is concerned with is that which relates to the stable
management of the domain name system and that which relates to the provision of
the WHOIS service.

3. ICANN is,
furthermore, only concerned about the management of the data that is the
subject of ICANN contractual requirements.

4. The obligation to
deposit all registry data into escrow is assumed to continue and applies to all
registries. Data escrow is not part of these Terms of Reference.

5. RGA discussion
included what safeguards exists when data is provided to third parties by the
registries under 'non discriminatory conditions' and allowing the registry to
gather and use data about non registered domain names to assign a per name
value on non registered names. The RG
suggested that this area deserves further thought and examination. However, there was support [from whom] for a
policy regarding the use of registry data, which includes traffic data, for
purposes other than that for which it is collected. The group supports
further discussion and work on this topic to determine what the elements of
such a policy would entail. [Refer in
detail to the WHOIS Task Force to ensure consistency]

6. For both 5a and
5b, in general, there is support for the need for policy, but acknowledgement
that there is not yet enough detail discussion on these two questions to
present a more detailed recommendation. The NCUC has proposed a separate Task
Force to target this topic but reference to the work of the existing WHOIS Task
Force needs to be taken into account in the first instance.

CS:
TOR 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.

RyC…
style='mso-bidi-font-style:normal'>"…the question of a policy guiding such
investments is closely related to the question of price controls and the
setting of ICANN fees. It is equally
inappropriate for the various constituencies comprising the GNSO to be in the
position of resolving their conflicting interests by setting investment
policies for another constituency".

RC…
style='mso-bidi-font-style:normal'>"…there should not be a policy guiding
investments in development and infrastructure.
It should be determined as a matter of contract and/or commercial
discretion. However, it is appropriate
for ICANN to consider such investments
when determining if the registry operator qualifies for renewal of its
agreement."

style='mso-bidi-font-style:normal'>

IPC… "…
style='mso-bidi-font-style:normal'>A general policy on this topic may not be
needed. Commitments regarding such
investment will generally be an appropriate factor in the selection of registry
operators. Contractual commitments to
such investment should be considered on a case-by-case basis. Any commitment entered into should be
transparently disclosed, and effectively enforced."

NCUC…
style='mso-bidi-font-style:normal'>"…it is completely inappropriate for ICANN
to dictate specific investment levels in infrastructure. Investment levels themselves are an
inappropriate metric of quality, what matters is performance. Clever applications of technology could
provide better performance with less investment. ICANN contracts should not attempt to
micromanage registry infrastructure development. If ICANN dictates infrastructure levels it
could thwart competition and innovation by imposing a dull uniformity on the
industry."

style='mso-bidi-font-style:normal'>

CBUC…
style='mso-bidi-font-style:normal'>" Competitive bids in .org and .net have led
to commitments and delivery on these commitments in investment in development
and infrastructure. If there is a truly competitive environment where
registries are always re-bid without presumption of renewal, then the pressure
of a competitive bid will support investments in development and
infrastructure.

style='mso-bidi-font-style:normal'>In the absence of a competitive bid process,
then there will need to be guidelines for policy for investment. Guidelines would need to ensure that
investment is sufficient to maintain the stability of infrastructure and ensure
quality levels are maintained. The CBUC
is considering further what the elements of such policy might be. In the end,
though, our strong preference is for a mandatory re-bid process, with the
awareness that there can be special characteristics for sponsored gTLDs."

style='mso-bidi-font-style:normal'>

ISPCP… "
style='mso-bidi-font-style:normal'>The ISPCPCP Constituency encourages registry investments in capability
development and infrastructure. We
propose that such investments be made a criterion in the evaluation of registry
bids. If registry awards are based on
free and open competition, with no presumptive right of renewal, then this will
motivate bidders to include provisions for the development of capabilities and
infrastructure in their proposals."

RGB:
TOR 6

1. There are
currently no requirements in the existing registry agreements which require
investments in infrastructure or development (see, for example, the Annex 3
table above).

2. In the discussion
of RGA, there appeared to be a split of the constituencies of whether there
should be mandated investment requirements at all. Some constituencies
are in favor of investment requirements, especially if there are presumptive
renewals of registry agreements. Others oppose mandatory investment
requirements regardless of whether there is competition inserted through a bid
process. It is also clear that there are insufficient security and
stability safeguards in the current registry agreements.

3. A middle-ground
policy recommendation emerged in which ICANN may set baseline requirements for
the security and stability of the registries and anything above that would be
negotiated on a case-by-case basis, if necessary. For example, baseline
guidelines could include requirements for: (1) specific security reporting to
ICANN; (2) detailed security plans and regular testing of DNS defenses; (3)
auditing provisions permitting ICANN to assess capabilities regarding potential
and ongoing DNS security breaches; (4) ICANN to be able to conduct risk
analysis of the operations and regular security reviews. Further
reference should be made to the work of the GNSO Committee on the introduction
of new TLDs (PDP Dec 05) to ensure policy consistency.

4. While this would
be important in registry renewals, these types of guidelines could be important
for new registries without a performance track record. Such baseline requirements could be
recommended to the Board by the Security and Stability Advisory Committee
("SSAC").

5. Option - The Board should seek
recommendations from the SSAC to provide baseline security and stability
requirements in registry agreements. In
determining these requirements, the SSAC should solicit and review public
comments.

style='page-break-before:always'>

name="_Toc34982544">
name="_Toc156718144">References

name="_Toc36877740">1. This
section sets out the key documents that have been produced during the course of
the policy development process.

name="_Toc36877741">2. The
Issues Report (found at
href="http://gnso.icann.org/issues/gtld-policies/issues-report-02feb06.pdf">http://gnso.icann.org/issues/gtld-policies/issues-report-02feb06.pdf)
sets out the key elements of the discussion and the recommendation from the
General Counsel's office to not proceed with the PDP as it was originally
formulated.

name="_Toc36877742">3. The
Terms of Reference (found at
href="http://gnso.icann.org/issues/gtld-policies/tor-pdp-28feb06.html">http://gnso.icann.org/issues/gtld-policies/tor-pdp-28feb06.html).

name="_Toc36877743">4. GNSO
Chair Bruce Tonkin made a brief report to the Wellington GNSO Public Forum
meeting on the progress of the Task Force (
href="http://www.icann.org/presentations/tonkin-gnso-wellington-28mar06.pdf">http://www.icann.org/presentations/tonkin-gnso-wellington-28mar06.pdf)

name="_Toc36877744">5. The
Call for Papers yielded only one response from Mr Matt Hooker that was taken
into account in the production of the Preliminary
Task Force Report. (
href="http://www.icann.org/announcements/announcement-11apr06.htm">http://www.icann.org/announcements/announcement-11apr06.htm)

name="_Toc36877745">6. The
first draft of the Preliminary Task Force
Report was prepared to facilitate the Task Force's face-to-face meeting in
Marrakech. (
href="http://gnso.icann.org/issues/gtld-policies/tld-contract-policies-16jun0…">http://gnso.icann.org/issues/gtld-policies/tld-contract-policies-16jun0…)

name="_Toc36877746">7. An
updated Preliminary Task Force Report was
released on 3 August 2006 and took into account inputs received at the
Marrakech meeting (
href="http://gnso.icann.org/issues/gtld-policies/pcc-pdp-03aug06.pdf">http://gnso.icann.org/issues/gtld-policies/pcc-pdp-03aug06.pdf)

name="_Toc36877747">8. The
first draft of the Task Force's Expert
Materials can be found at (
href="http://gnso.icann.org/drafts/pdp-feb-06-expert-materials.pdf">http://gnso.icann.org/drafts/pdp-feb-06-expert-materials.pdf)

name="_Toc36877748">9. After
feedback from the Task Force, the updated Expert
Materials were released in September 2006 (
href="http://gnso.icann.org/drafts/PDPFeb06ExpertMaterials_draft2.pdf">http://gnso.icann.org/drafts/PDPFeb06ExpertMaterials_draft2.pdf)

name="_Toc36877749">10. In
response to correspondence from the Task Force Chair about the status of the
work of the group, ICANN's General Counsel's office prepared a
style='mso-bidi-font-style:normal'>Comparison Table which can be used to
compare and contrast existing registry agreements and the PDP Feb 06 Terms of
Reference
(http://gnso.icann.org/drafts/draft-comparison-of-icann-registry-agreements-20061009.htm)

name="_Toc36877750">The
full Taskforce membership is listed below at Annex Two along with the
attendance at each of the meetings. The
attendance lists for the Rapporteur Groups are also included to show
representation and participation in the work of the Task Force.

name="_Toc36877751">Guermazi,
Boutheina and Isabel Neto, Mobile License
Renewal: What are the issues? What is at stake?, available at
href="http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/2…">http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/23

name="_Toc36877752">
href="http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/2…">/000016406_20050923113019/Rendered/PDF/wps3729.pdf

name="_Toc36877753">Matsui,
Masayuki, Comparing Domain Name
Administration in OECD Countries, available at
href="http://www.oecd.org/dataoecd/46/38/2505946.pdf">http://www.oecd.org/dataoecd/46/38/2505946.pdf

name="_Toc36877754">Paltridge,
Sam and Masayuki Matsui, Generic Top
Level Domain Names: Market Development
and Allocation Issues, available at

http://www.oecd.org/dataoecd/56/34/32996948.pdf
name="_Toc34982560">
name="_Toc38689968">

name="_Toc36877756">Perset,
Karin and Dimitri Ypsilanti, The
Secondary Market for Domain Names, available at
href="http://www.oecd.org/dataoecd/14/45/36471569.pdf">http://www.oecd.org/dataoecd/14/45/36471569.pdf

name="_Toc36877757">Further
detailed materials are contained with the Expert
Materials documentation reference above.

href="#_ftnref1" name="_ftn1" title="">[1]
href="http://gnso.icann.org/announcements/announcement-08mar07.htm">http://gnso.icann.org/announcements/announcement-08mar07.htm. The two public comments that were received,
from Danny Younger and Phil Corwin. The
comments are reproduced in full in the public comment section below.

href="#_ftnref2" name="_ftn2" title="">[2]
href="http://www.icann.org/general/archive-bylaws/bylaws-28Feb06.htm#AnnexA">http://www.icann.org/general/archive-bylaws/bylaws-28Feb06.htm#AnnexA

href="#_ftnref3" name="_ftn3" title="">[3] Found at
http://gnso.icann.org/drafts/PDPFeb06ExpertMaterials_draft2.pdf.

href="#_ftnref4" name="_ftn4" title="">[4]
Rapporteur Group 1 was chaired by Marilyn Cade.
Rapporteur Group 2 was chaired by Jon Nevett.

href="#_ftnref5" name="_ftn5" title="">[5] Refer to
the http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA

href="#_ftnref6" name="_ftn6" title="">[6] Found at
http://www.gtldregistries.org/news/2006/2006-03-02-01
and http://www.gtldregistries.org/news/2006/2006-03-02-02.pdf.

href="#_ftnref7" name="_ftn7" title="">[7]
href="http://www.gtldregistries.org/news/2006/2006-04-27-01">http://www.gtldregistries.org/news/2006/2006-04-27-01

href="#_ftnref8" name="_ftn8" title="">[8]
href="http://www.gtldregistries.org/news/2007/2007-01-03-01.pdf">http://www.gtldregistries.org/news/2007/2007-01-03-01.pdf

href="#_ftnref9" name="_ftn9" title="">[9]
http://forum.icann.org/lists/pdp-feb06-comments/msg00001.html.

href="#_ftnref10" name="_ftn10" title="">[10]
http://forum.icann.org/lists/pdp-pcceg-feb06/msg00589.html

href="#_ftnref11" name="_ftn11" title="">[11]
http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA

href="#_ftnref12" name="_ftn12" title="">[12]
http://forum.icann.org/lists/pdp-pcceg-feb06/msg00518.html

href="#_ftnref13" name="_ftn13" title="">[13]
Correspondence from General Counsel John Jeffrey to GNSO Council Chair Bruce
Tonkin answering Maureen Cubberley's request for information about the
applicability of the PDP Feb 06 possible recommendations.
href="http://gnso.icann.org/correspondence/jeffrey-to-tonkin-27sep06.pdf">http://gnso.icann.org/correspondence/jeffrey-to-tonkin-27sep06.pdf. Ms Cubberley's original correspondence is at
http://gnso.icann.org/correspondence/cubberley-to-tonkin-25aug06.pdf.

href="#_ftnref14" name="_ftn14" title="">[14]
http://www.icann.org/tlds/agreements/jobs/jobs-agreement.htm

href="#_ftnref15" name="_ftn15" title="">[15]
http://gnso.icann.org/drafts/GNSO-PDP-Dec05-FR13-FEB07.htm

href="#_ftnref16" name="_ftn16" title="">[16] A full
list of all existing registry agreements is found at
http://www.icann.org/registries/agreements.htm

href="#_ftnref17" name="_ftn17" title="">[17]
http://www.icann.org/tlds/agreements/sponsored/sponsorship-agmt-05nov04…

href="#_ftnref18" name="_ftn18" title="">[18]
http://gnso.icann.org/drafts/pdp06-groupB-workdoc-27oct06.pdf

href="#_ftnref19" name="_ftn19" title="">[19]
http://gnso.icann.org/drafts/pdp06-groupB-workdoc-27oct06.pdf

href="#_ftnref20" name="_ftn20" title="">[20] The
transcripts and MP3 recordings of all the meetings can be found on the GNSO's
master calendar. http://gnso.icann.org/calendar/

href="#_ftnref21" name="_ftn21" title="">[21] The
email and subsequent responses to it can be found at
http://forum.icann.org/lists/pdp-pcceg-feb06/msg00521.html.

href="#_ftnref22" name="_ftn22" title="">[22]
http://forum.icann.org/lists/pdp-feb06-comments/

href="#_ftnref23" name="_ftn23" title="">[23]
http://forum.icann.org/lists/pdp-feb06-comments/msg00002.html

href="#_ftnref24" name="_ftn24" title="">[24]
http://forum.icann.org/lists/pdp-feb06-comments/msg00003.html

href="#_ftnref25" name="_ftn25" title="">[25]
href="http://gnso.icann.org/meetings/minutes-pdp06-06jun06.htm">http://gnso.icann.org/meetings/minutes-pdp06-06jun06.htm

http://gnso.icann.org/meetings/minutes-PDP06-24jun06.shtml

http://gnso.icann.org/meetings/minutes-PDP06-10aug06.shtml

http://gnso.icann.org/meetings/minutes-PDP06-13sep06.shtml

href="#_ftnref26" name="_ftn26" title="">[26] The MP3
recordings of the meetings can be found at on the Calendar section of the GNSO
website at http://gnso.icann.org/calendar
and transcripts of both the Task Force meetings. The Rapporteur Group A
transcripts, MP3 recordings and final report can be found at
href="http://gnso.icann.org/drafts/">http://gnso.icann.org/drafts/. Rapporteur Group B only produced a final
report.

href="#_ftnref27" name="_ftn27" title="">[27] The
minutes are found at
href="http://gnso.icann.org/meetings/minutes-gnso-06feb06.shtml">http://gnso.icann.org/meetings/minutes-gnso-06feb06.shtml
and MP3 recording of the meeting found at http://gnso-audio.icann.org/GNSO-Council-20060206.mp3.

href="#_ftnref28" name="_ftn28" title="">[28]
http://www.icann.org/minutes/resolutions-08dec06.htm

href="#_ftnref29" name="_ftn29" title="">[29] 29
November 2006 call: Scott Hemphill,
Afilias and Steve Metalitz, IPC joined the call.

href="#_ftnref30" name="_ftn30" title="">[30] Note no
representation from ISPCP or IP constituencies.

href="#_ftnref31" name="_ftn31" title="">[31] The
Registry Constituency submitted a statement prior to the vote by the GNSO
Council on the Terms of Reference stating that the draft Terms of Reference
"reflects a serious misperception about the extent to which the ICANN community
as a whole can and should have authority to impose obligations on registries
and registrars and/or dictate the terms and conditions contained in ICANN's
commercial agreements with DNS service providers. In the view of the Registry Constituency, the
misperception threatens fundamental checks and balances built into the ICANN
process that are an important source of ICANN's legitimacy and must,
accordingly, be preserved". The Registry
Constituency also stated "any further proceedings on this PDP are outside the
legal powers of the GNSO, and can have no effect on the subject matter of
contractual conditions for existing generic top level domains." In submission of the constituency statement
re-iterated that "the participation of the RyC in commenting on the proposed
text of the ToR should be viewed in the context of this preface. Any comments are without prejudice to the
position of RyC that the proceedings are out of scope and without legal
foundation…" (For further background, see
href="http://www.gtldregistries.org/news/2006/2006-03-02-01">http://www.gtldregistries.org/news/2006/2006-03-02-01
and http://www.gtldregistries.org/news/2006/2006-03-02-02.pdf
and http://www.gtldregistries.org/news/2006/2006-04-27-01).

href="#_ftnref32" name="_ftn32" title="">[32] The
Registry Constituency, in their 11 June 2006 supplementary comments, said that
"As already noted…, this topic is not a possible topic for consensus policies
that registries/sponsors would be contractually required to follow. The last sentence of the 'commentary'
paragraph of Section 1a says, "Further analysis is required about the nature of
competition in the market for registry services." As with renewal provisions, it should be
noted that the topic of competition is not a possible topic for consensus
policies that registries/sponsors would be contractually required to
follow. With regard to Section 1b
[determine whether or not these conditions should be standardized across all
future agreements], the RyC agrees with the well articulated comments submitted
by the IPC in this regard: "…it is a
fact that not all gTLD registries are comparably situated, with regard to size
or dominance, and it is not always appropriate to treat them as if they
were. Consistency is only one of several
factors that should be taken into account in fashioning a policy regarding
registry agreements."

href="#_ftnref33" name="_ftn33" title="">[33] The
full membership of each of the Rapporteur Groups is set out in the Rapporteur
Group attendance tables found above.

href="#_ftnref34" name="_ftn34" title="">[34] Found
at
href="http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/2…">http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/23

href="http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/2…">/000016406_20050923113019/Rendered/PDF/wps3729.pdf

href="#_ftnref35" name="_ftn35" title="">[35] Both
drafts of the Expert Materials are found on the GNSO website at
http://gnso.icann.org/drafts/

href="#_ftnref36" name="_ftn36" title="">[36] Email
posting from Alistair Dixon
http://forum.icann.org/lists/pdp-pcceg-feb06/msg00335.html

href="#_ftnref37" name="_ftn37" title="">[37] The RyC
submitted additional comments on 11 June 2006 that included the following. "As already noted in the comments to Section
D above, this topic is not a possible topic for consensus policies that
registries/sponsors would be contractually required to follow. The 'Commentary' paragraph at the end of
Section 3a says, "…It would be helpful to retain expert economic advice to
provide a report on the impact of price controls in industries such as registry
services. It would helpful if the
Taskforce considered registry services agreements in the context of other
regulated industries such as the telecommunications or electricity
sectors". Considering the topic is out
of scope for consensus policies as defined in registry agreements, it does not
appear to be a wise use of resources to hire outside expertise in this
regard. Moreover, considering the
uniqueness of the Internet especially with regard to how it has flourished with
minimal regulation, comparing registry agreements to agreements in other
economic sectors such as telecommunications or public utilities seems like a
questionable tactic".

href="#_ftnref38" name="_ftn38" title="">[38] The RyC
submitted further comments on this area.
"As already noted in the comments to Section D above, this topic is not
a possible topic for consensus policies that registries/sponsors would be
contractually required to follow".

onmouseover="msoCommentShow('_anchor_1','_com_1')"
onmouseout="msoCommentHide('_com_1')">

href="#_msoanchor_1" class=msocomoff>[LW1]Include
commentary from the NCUC and other constituencies

onmouseover="msoCommentShow('_anchor_2','_com_2')"
onmouseout="msoCommentHide('_com_2')">

href="#_msoanchor_2" class=msocomoff>[LW2]Insert
a glossary of terms

onmouseover="msoCommentShow('_anchor_3','_com_3')"
onmouseout="msoCommentHide('_com_3')">

href="#_msoanchor_3" class=msocomoff>[LW3]Insert
expressions of support from Nom Com and ALAC

onmouseover="msoCommentShow('_anchor_4','_com_4')"
onmouseout="msoCommentHide('_com_4')">

href="#_msoanchor_4" class=msocomoff>[LW4]Clarify
why this is here?

onmouseover="msoCommentShow('_anchor_5','_com_5')"
onmouseout="msoCommentHide('_com_5')">

href="#_msoanchor_5" class=msocomoff>[LW5]Include
here when Avri was appointed.

Task Force Report - Policies for Contractual Conditions - Existing Registries - PDP Feb 06

name="_Toc38689897">name="_Toc156718109">Abstract

name="_Toc38689899">name="_Toc34982487">DocumentStatus

name="_Toc38689901">Glossary

name="_Toc156718116">

name="_Toc36877690">Acknowledgments

name="_Toc38689897">
name="_Toc156718109">Abstract

name="_Toc38689899">
name="_Toc34982487">Document
Status