Date

18 February 2007

name="_Toc43201948">name="_Toc35414180">

Task Force Report

DRAFT

PDPFeb06

18 February 2007

name="_Toc156717998">Author: Dr
Liz Williams

name="_Toc156718109">Abstract

This
is a DRAFT Task Force Report for the Generic Names Supporting Organisation's
policy development process on Policies for Contractual Conditions: Existing Registries (PDPFeb06).

name="_Toc156718111">Document Status

18 February 2007: draft
Task Force Report.

name="_Toc156718003">Contentsname="_Toc156718004">

1. Introduction

2. Recommendations

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

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

Annex One - Policy Development Process Background Information

Annex Two -- Participation Data

Annex Three -- Constituency Statements and Rapporteur Group Input

References

name="_Toc156718115">Definitions

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

PDP: 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.

name="_Toc156718116">

Acknowledgments

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/.

Meetings have been open
to observers and remote participation in meetings has been made available. For full information on participation,
consult the charts found below.

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

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

1.1 This
is the draft Task Force Report for the Policies for Contractual Conditions for
Existing Registries policy development process (PDPFeb06). The final draft of the Task Force Report is
due to be submitted to the GNSO Council prior to the March 2007 ICANN meeting
in Portugal. It is expected that the final drafting of the
Report will take place at the Task
Force's face-to-face meeting in Los
Angeles on 24 & 25 February 2007.

1.2 The work of the Task Force was guided by
Section 7 of the ICANN GNSO policy development process (href="http://www.icann.org/general/archive-bylaws/bylaws-28Feb06.htm#AnnexA">http://www.icann.org/general/archive-bylaws/bylaws-28Feb06.htm#AnnexA).
This Report reflects comprehensive
information gathering from a wide range of sources, including the preparation
of Expert Materialsstyle='mso-footnote-id:ftn1' href="#_ftn1" name="_ftnref1" title="">[1] by ICANN Staff and the use of two Task
Force Rapporteur Groups who did separate streams of work for presentation to
the Task Force as a whole.

1.3 According to the PDP guidelines, the Task
Force Report must include:

style='mso-bidi-font-style:normal'>. "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.4 The following sections set out the proposed
policy recommendations and identify the level of Constituency support for each
of the recommendations.

1.5 The Registry Constituency, 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. Those two statements can be found at href="http://www.gtldregistries.org/news/2006/2006-03-02-01">http://www.gtldregistries.org/news/2006/2006-03-02-01 and href="http://www.gtldregistries.org/news/2006/2006-03-02-02.pdf">http://www.gtldregistries.org/news/2006/2006-03-02-02.pdf.

1.6 The Registry Constituency issued a further
statement on 27 April 2006 setting out the Constituency's ongoing objection to
the Task Force's work (href="http://www.gtldregistries.org/news/2006/2006-04-27-01">http://www.gtldregistries.org/news/2006/2006-04-27-01).

1.7. On 3 January 2007, the Registry Constituency
sent in a formal response to the straw poll recommendations which are listed
below (href="http://www.gtldregistries.org/news/2007/2007-01-03-01.pdf">http://www.gtldregistries.org/news/2007/2007-01-03-01.pdf).

1.8 The Registry Constituency 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='page-break-before:always'>

name="_Toc33432054">2. Recommendations

2.1 There
were six Terms of Reference with several suggestions for possible policy
recommendations relating to each Term of Reference. The following table sets out each of the
proposed policy recommendations and shows where each Constituency has
voted. A confirmation email was sent to
the PDPFeb06 email list on 25 January 2007style='mso-footnote-id:ftn2' href="#_ftn2" name="_ftnref2" title="">[2] 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, the chart
would stand. No responses to that email
were received and the chart is reproduced belowstyle='mso-footnote-id:ftn3' href="#_ftn3" name="_ftnref3" title="">[3]. In
the discussion paragraphs below, a fuller description is provided for each of
the proposed recommendations.

2.2 The
Registry Constituency has voiced its opposition to the majority of the
recommendations, arguing that the proposals are out of scope and, even if the
recommendations were agreed upon, they would not be retroactively applied to
existing registry contracts.

2.3 Leaving
those views aside, and referring to the advice of the General Counsel's officestyle='mso-footnote-id:ftn4' href="#_ftn4" name="_ftnref4" title="">[4] in response to correspondence from Task
Force Chair Maureen Cubberley, the table below shows which Constituency
supported what draft recommendations.
The Nominating Committee members (Doria, Cubberley and Bekele) and the
ALAC Liaison do not have formal votes but their opinions are also expressed in
the chart. This chart needs to be read
in conjunction with the participation table at Annex A which sets out which
constituencies participated in each of the Task Force's calls and Rapporteur
Groups as, on numerous occasions, several Constituencies were not represented.

PDP FEB
06: STRAW POLL INDICATORS CURRENT AT 15
FEBRUARY 2007

TERMS OF
REFERENCE ONE AND TWO

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

ISPC

IPC

Y**

NCUC

RyC

Doria

Cubberley

Bekele

Fausett

TOTAL - CONSTITUENCIES

TOTAL - NV MEMBERS

PDP FEB
06: STRAW POLL INDICATORS CURRENT AT 15
FEBRUARY 2007

TERMS OF
REFERENCE THREE, FOUR, FIVE AND SIX

style='width:369.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

ISPC

IPC

NCUC

RyC

Doria

Cubberley

Bekele

Fausett

TOTAL -- CONSTITUENCIES

TOTAL -- NV MEMBERS

Legend:

Y == support draft recommendation; N == does not support draft
recommendation; A == Abstain; P == Pending

NV Members which include the Nominating Committee members and
the ALAC representative.

Note: The shaded
recommendations indicate a choice between policy recommendation options.

Note: Maureen
Cubberley's votes have been carried forward from the 17 November 2006
conference call.

Note:
Recommendations 5a.1 and 5a.2 have to be confirmed.

Note**:
Proposed modified text needs consideration.

Note^^:
Registry Constituency did not vote on this issue.

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

3. Term
of Reference 1A: Registry agreement
renewal

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

3.1 The
Task Force considered a number of variations on the draft policy recommendation
for all the Terms of Reference.
"Support" for a recommendation was agreed to be four or more
Constituencies agreeing recommendation text.
Term of Reference One was considered by Marilyn Cade's Rapporteur Group
One (RG1). 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. As is evident in the
chart above, all the 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 be including whether
there should be a standard term for all gTLD registries that 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 agreementstyle='mso-footnote-id:ftn5' href="#_ftn5" name="_ftnref5" title="">[5] where the term of the agreement is discussed
in Article IV.

3.5 Three
Constituencies supported the recommendation that there should be a reasonable
expectation of renewal.

3.6 Two
Constituencies (IPC and RC) supported the proposed recommendation that there
should be a reasonable expectation of renewal for all registry agreements.

3.7 Two
Constituencies supported the proposal that there should be renewal expectancy
for all registry agreements.

3.8 Finally,
two Constituencies (NCUC and RyC) agreed that there should be a presumption of
renewal for all registry agreements.

3.9 In
summary, there is majority support for a policy guiding renewals and that
registry agreements should be a reasonable length. The remainder of the proposed recommendations
do not have majority support.

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

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
two proposed recommendations in this section do not relate to policies for
contractual conditions for existing registries which is the focus of this
PDP. The discussion about whether
registry agreement terms should be standardized across future registry
agreements has been discussed 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:ftn6' href="#_ftn6" name="_ftnref6" title="">style='mso-bidi-font-style:normal'>[6].

4.2 However,
Rapporteur Group A considered this question in its work (referenced in the
footnote above) and derived two possible recommendations. The first
recommendation (1B.1 in the chart above) 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 (1B.2 in the chart) suggested that the right
of renewal should be standardized for all registry agreements except when there
is an exceptional situation. 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.

4.5 The
next sections highlight discussion about the relationship between registry
agreements and consensus policies.

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

5.1 In
the ICANN context, Consensus Policies are a clearly defined term in all of the
existing registry agreementsstyle='mso-footnote-id:ftn7' href="#_ftn7" name="_ftnref7" title="">[7]. In
each of the agreements, the applicability of Consensus Policies is set out
clearly. In the case of the .info
agreement, the Consensus Policy provisions are in the Article III Covenants sectionstyle='mso-footnote-id:ftn8' href="#_ftn8" name="_ftnref8" title="">[8] which can be used for ease of
reference. The limitations on consensus
policy provisions also provide a guide to the areas which the GNSO policy
development process applies.

5.2 The
Task Force discussed three possible recommendations in this section. In the chart above 2A.1 - that Consensus
Policies limitations are inappropriate; 2A.2. - that Consensus Policies should
always apply to all gTLD registries and 2A.3
-- that the present limitations to Consensus Policies are approved and
should continue)

5.3 As
is evident in the chart, the strongest support was for recommendation 2A.3 that
the present limitations to Consensus Policies are approved and should continue.

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

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 may not be 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 gTLD operators.

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 which took
responsibility for TOR 3, 4 and 6style='mso-footnote-id:ftn9' href="#_ftn9" name="_ftnref9" title="">[9]. The
results of its discussion is found in the report in the footnote below.

7.2 The
Registry Constituency 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
NCUC did not vote on the proposed policy recommendation. 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 With
respect to proposed recommendation 3A.2, 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.

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, ISPC and the BC supported Recommendation 3A.1.

8. Term of Reference 4: ICANN fees

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.
style='mso-special-character:line-break'>

8.1 This
Term of Reference was discussed in detail by Rapporteur Group B which took
responsibility for TOR 3, 4 and 6style='mso-footnote-id:ftn10' href="#_ftn10" name="_ftnref10" title="">[10]. 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 Four constituencies supported the
recommendation with the RyC abstaining from the vote and the BC's position
needing clarification.

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.

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.

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 2007style='mso-footnote-id:ftn11' href="#_ftn11" name="_ftnref11" title="">[11]. 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
Interim Chair Avri Doria provided a set of
proposed recommendations in her emailstyle='mso-footnote-id:ftn12' href="#_ftn12" name="_ftnref12" title="">[12] 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.

9.4
In
discussions during the conference calls and on the PDP Feb 06 email lists, the
RyC committed to providing some detailed information about the kinds of
registry data they collected and the purposes for which it was used. That data was due to be provided to the Task
Force on 15 February 2007. The RyC then
advised that the document would be provided in the week leading up to the Los
Angeles meetings on 24 and 25 February.

9.5
With
respect to draft recommendation 5b, Ms Doria suggested a proposed
recommendation choice which said "…there is currently no clear need for a new
policy on the use of registry data, including traffic data, for purposes other
then which is was collected. Based on the results of the exhaustive external
study and public discussions recommended in 5a (b), the GNSO council should
consider the creation of a PDP that would include policy recommendations for
new, as well as for existing Registry agreements.

9.6
This
element of the work needs to be completed with a definitive indication of
support for the proposed recommendation being agreed either with the provision
of the RyC data or, in the absence of that data, on the basis of the positions
that the group have already devised.

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.

10.1
This Term of Reference was discussed and agreed
early in the Task Force's work.

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

10.3
ICANN
should, however, 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 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='page-break-before:always'>

Annex One - Policy Development Process Background
Information

1.1
The Task Force has held a series of meetings,
the minutes of which are available onlinestyle='mso-footnote-id:ftn13' href="#_ftn13" name="_ftnref13" title="">[13]. 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.

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 Reportstyle='mso-footnote-id:ftn14' href="#_ftn14" name="_ftnref14" title="">[14]. 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 2006style='mso-footnote-id:ftn15' href="#_ftn15" name="_ftnref15" title="">^{^[15]}, 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, 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
agreementsstyle='mso-footnote-id:ftn16' href="#_ftn16" name="_ftnref16" title="">[16].

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

Annex
Two -- 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

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

ISPC

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 Interim Chair

Bret Fausett ALAC

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

Rapporteur Group A:
Attendance Liststyle='mso-footnote-id:ftn17' href="#_ftn17" name="_ftnref17" title="">[17]

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

ISPCP

Present

Absent

Tony Holmes *

ISPCP

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

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

Rapporteur Group B:
Attendance Liststyle='mso-footnote-id:ftn18' href="#_ftn18" name="_ftnref18" title="">[18]

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="_Toc156718032">Annex
Three -- Constituency Statements and Rapporteur Group Input

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 guidelinesstyle='mso-footnote-id:ftn19' href="#_ftn19" name="_ftnref19" title="">[19].

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 http://gnso.icann.org/correspondence/jeffrey-to-tonkin-27sep06.pdf).

src="/drafts/GNSO-PDP-Feb06-TFR-18Feb07_files/image002.jpg" v:shapes="_x0000_i1025">

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:ftn20' href="#_ftn20" name="_ftnref20" title="">^{^[20]}

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'>

BC:… style='mso-bidi-font-style:normal'>"It is the view of the BC 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 BC 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 BC 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 BC 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'>

ISP: …"The ISPCP 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^{^[21]}:
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.

BC… "style='mso-bidi-font-style:normal'>The BC 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."

ISP… "style='mso-bidi-font-style:normal'>The ISPCP 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 disparate 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 renewalhref="#_ftn22" name="_ftnref22" title="">^{^[22]} 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 Materialstitle="">^{^[23]}
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 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="#_ftn24" name="_ftnref24" title="">^{^[24]}.

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'>

BC… "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
BC 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 BC does not see a rationale for
using contractual terms to limit consensus policy in registry agreements. The BC would like to hear what justifications
exist for creating exceptions to consensus policy. The BC 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'>

ISP… "The ISPCP 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 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:

(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 disputes 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.

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 disputes 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.

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…;)."

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.

BC… style='mso-bidi-font-style:normal'>"The BC 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."

ISP… style='mso-bidi-font-style:normal'>"The ISPCP 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
dispute 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="_ftnref25" title="">^{^[25]}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'>

BC… "style='mso-bidi-font-style:normal'>The BC 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."

ISP… "style='mso-bidi-font-style:normal'>The ISPCP 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.

BC… style='mso-bidi-font-style:normal'>"The BC 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 BC has provided a suggestion
for such an approach in its introductory statement to this comment."

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

ISP… style='mso-bidi-font-style:normal'>" The ISPCP 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).

CS: TOR 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] [ISP] [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'>

BC… 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'>

ISP… "style='mso-bidi-font-style:normal'>The ISPCP 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 disproportionately large fees to ICANN's
budget will be able to exercise disproportionate 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.

BC… "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."

ISP… 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 disparate 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

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:ftn26' href="#_ftn26" name="_ftnref26" title="">^{^[26]}

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".

BC… "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 BC 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."

ISP… "style='mso-bidi-font-style:normal'>The ISPCP 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.

BC… style='mso-bidi-font-style:normal'>"In general, the BC 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 BC 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 BC 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'>

ISP… "style='mso-bidi-font-style:normal'>The ISPCP 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'>

BC… 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 BC 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'>

ISP… "style='mso-bidi-font-style:normal'>The ISPCP 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="_Toc156718144">References

1.
This section sets out the key documents that
have been produced during the course of the policy development process.

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.

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).

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)

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

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…)

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)

8.
The first draft of the Task Force's style='mso-bidi-font-style:normal'>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)

9.
After feedback from the Task Force, the updated style='mso-bidi-font-style:normal'>Expert Materials were released in
September 2006 (href="http://gnso.icann.org/drafts/PDPFeb06ExpertMaterials_draft2.pdf">http://gnso.icann.org/drafts/PDPFeb06ExpertMaterials_draft2.pdf)

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 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-agreeme…)

The full Taskforce membership is listed below at Annex One 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.

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

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

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

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

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

Further detailed materials are contained with the style='mso-bidi-font-style:normal'>Expert Materials documentation reference
above.

title="">[1]
Found at href="http://gnso.icann.org/drafts/PDPFeb06ExpertMaterials_draft2.pdf">http://gnso.icann.org/drafts/PDPFeb06ExpertMaterials_draft2.pdf.

name="_ftn2" title="">[2] http://forum.icann.org/lists/pdp-pcceg-feb06/msg00518.html

title="">[3]
http://forum.icann.org/lists/pdp-pcceg-feb06/msg00519.html

title="">[4]
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.

title="">[5]
http://www.icann.org/tlds/agreements/jobs/jobs-agreement.htm

title="">[6]
http://gnso.icann.org/drafts/GNSO-PDP-Dec05-FR13-FEB07.htm

title="">[7]
A full list of all existing registry agreements is found at http://www.icann.org/registries/agreements.htm

title="">[8]
http://www.icann.org/tlds/agreements/info/registry-agmt-08dec06.htm

title="">[9]
http://gnso.icann.org/drafts/pdp06-groupB-workdoc-27oct06.pdf

name="_ftn10" title="">[10]
http://gnso.icann.org/drafts/pdp06-groupB-workdoc-27oct06.pdf

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

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

href="#_ftnref13" name="_ftn13" title="">[13] 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="#_ftnref14" name="_ftn14" title="">[14] 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="#_ftnref15" name="_ftn15" title="">[15] The minutes
are found at 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.

name="_ftn16" title="">[16]
http://www.icann.org/minutes/resolutions-08dec06.htm

name="_ftn17" title="">[17]
29 November 2006 call: Scott Hemphill,
Afilias and Steve Metalitz, IPC joined the call.

name="_ftn18" title="">[18]
Note no representation from ISP or IP constituencies.

href="#_ftnref19" name="_ftn19" title="">[19] 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="#_ftnref20" name="_ftn20" title="">[20] 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="#_ftnref21" name="_ftn21" title="">[21] The
full membership of each of the Rapporteur Groups is set out in the Rapporteur
Group attendance tables found above.

href="#_ftnref22" name="_ftn22" title="">[22] 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="#_ftnref23" name="_ftn23" title="">[23] Both
drafts of the Expert Materials are found on the GNSO website at http://gnso.icann.org/drafts/

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

href="#_ftnref25" name="_ftn25" title="">[25] 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="#_ftnref26" name="_ftn26" title="">[26] 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".

Task Force Report - DRAFT - PDPFeb06

name="_Toc43201948">name="_Toc35414180">

name="_Toc156718109">Abstract

name="_Toc156718111">Document Status

name="_Toc156718115">Definitions

name="_Toc156718116">

Acknowledgments