Commercial & Business Users Constituency	CBUC
Intellectual Property Constituency	IPC
Internet Service & Connection Providers Constituency	ISPCP
Nominating Committee	NomCom
Non-Commercial Users Constituency	NCUC
Policy Development Process - see http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA for full explanation	PDP
Rapporteur Group	RG
Registrar Constituency	RC
Registry Constituency	RyC

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 http://gnso.icann.org/issues/gtld-policies/ and the mailing list archives at 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 in Annex Three. The full list of Rapporteur Group input is found, along with Constituency Statements in Annex Four. A full list of references used to inform the Report is found within the Reference section at the end of the document.

1. Introduction

1.1 This is the draft Final 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 after a twenty day public comment period.

1.2 The work of the Task Force was guided by Section 7 of the ICANN GNSO policy development process (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 Materials[1] by ICANN Staff and the use of two Task Force Rapporteur Groups[2] (RG) that examined separate streams of work for presentation to the Task Force as a whole.

1.3 The following sections set out the proposed policy recommendations and identify the level of support for each of the recommendations. Although the Nominating Committee (NomCom) appointees (Doria, Bekele, Cubberley and Bing) do not have formal voting rights at the Council level, each member made their views known at the time of the straw poll discussions. This is also the case for the At Large Advisory (ALAC) representatives (Fausett and Greenberg).

1.4 Strong support for a recommendation was measured by four out of six constituencies supporting a recommendation with some NomCom support. Support from three constituencies with some NomCom support was termed medium support. Support from fewer than three constituencies is termed weak support.

1.5 The RyC has, throughout the policy development process, expressed its opposition to the Terms of Reference, to the potential applicability of any of the proposed policy recommendations and to the work of the Task Force as whole. The Registry Constituency (RyC), prior to the commencement of the formal PDP proceedings, issued a statement and a preface to that statement which set out its objections to the process. Those two statements can be found at http://www.gtldregistries.org/news/2006/2006-03-02-01 and http://www.gtldregistries.org/news/2006/2006-03-02-02.pdf. The RyC issued a further statement on 27 April 2006 setting out its ongoing objection to the Task Force's work (http://www.gtldregistries.org/news/2006/2006-04-27-01). On 3 January 2007, the RyC sent in a formal response to the straw poll recommendations which are listed below (http://www.gtldregistries.org/news/2007/2007-01-03-01.pdf).

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

1.7 From a procedural perspective the Task Force's first meeting in Wellington was used to agree a charter and work plan. The work plan was modified at a number of points throughout the process with Chair (Maureen Cubberley) and the replacement Chair (Avri Doria) notifying the GNSO Council of the changes. The original work plan and subsequent modifications are set out in Annex Two.

1.9 The table below was produced for the Issues Report phase of the Task Force's work. It refers to each Term of Reference at a headline level and provided an overview of the state of registry contracts at the beginning of the PDP. A more detailed and completely up to date report will, because of the file size, be posted separately.

2. Recommendation Summary

2.1 This table sets out the recommendations which have majority support. As set out above this is measured as having the support of four or more Constituencies (with some NomCom support) within each Term of Reference. The recommendations and the variations that were discussed by the Task Force are set out in full in the following sections. Support from non-voting NomCom and ALAC members are not included here but are referenced in each of the sections below.

Term of Reference	Recommendation
1A.1	There should be a policy guiding registry agreement renewal.
1A.2	Registry agreements should be a commercially reasonable length.
2A	The present limitations to Consensus Policies are appropriate and should continue.
2B	Certain policy making responsibility should be delegated to the sponsored gTLD operators.
4A	In order to improve ICANN accountability and effective business planning by registries, ICANN staff should immediately implement a system that avoids individual negotiations of ICANN fees and provides consistency unless there is an established justification for disparate treatment.
4B	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.
5	In order to determine whether there is a need for a new consensus policy on the collection and use of registry data, including traffic data, for purposes other than which is was collected, there is first a need for a properly targeted study by an independent third party on the data collected and the uses to which it is put. The study should provide appropriate safeguards to protect any data provided for the purposes of the study, and the confidentiality of which registry, or other group, provides the data. The findings of the study should be published and available for public review. A Statement of Work should be developed by the GNSO Council, with appropriate public review, to cover an analysis of the concerns for data collection and use, the practice involved in collection and use of data - including traffic data, and the availability, when appropriate, for non-discriminatory access to that data. It is recommended that a current processes document be developed, describing the current registry practices for the collection of data and the uses of that data, for example, but not limited to, operating the registry; preparing marketing materials to promote registration of domain names; gathering of 'null' returns, ensuring the integrity of the Registry, or the DNS. This report should be available to the group doing the external study and should be made available to the public for comment. After examining the results of the independent study and public discussions recommended above, the GNSO Council should examine the findings and determine what, if any, further policy process is required.
6A	ICANN should establish baseline requirements for the security and stability of registries and anything above that would be negotiated on a case-by-case basis, if necessary. Baseline requirements should be recommended to the Board by the Security and Stability Advisory Committee (SSAC) after consultation with the gTLD registry operators. In determining those recommendations, the SSAC should solicit and consider public comments.

2. Recommendations Discussion

2.1 There were six Terms of Reference with several suggestions for possible policy recommendations relating to each Term of Reference. The Table in Annex One sets out each of the full set of proposed choices and shows where each Constituency has voted. An email was sent to the PDPFeb06 email list on 25 January 2007[4] 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. Full discussion of each of the recommendations took place at the 24 February Task Force meeting in Los Angeles to confirm levels of support.

2.2 The recommendation text should be read in conjunction with the correspondence from the General Counsel's office[5] in response to Task Force Chair Maureen Cubberley's request for more information about the applicability of the Task Force's recommendations to existing registry contracts. In addition, the participation data in Annex Three provides a full set of data on which constituencies participated in each of the Task Force's calls and Rapporteur Groups. On numerous occasions, several Constituencies were not represented.

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.

Recommendation 1A: There should be a policy guiding registry agreement renewal.

Recommendation 1B: Registry agreements should be a commercially reasonable length.

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

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

3.3 The discussion then turned to what elements that policy should 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 agreement[6] where the term of the agreement is discussed in Article IV.

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

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

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

3.8 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 that 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)[7].

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

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

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

5. Term of Reference 2A: Relationship between registry agreements and consensus policies Recommendation 2A: The present limitations to Consensus Policies are appropriate and should continue.

5.1 In the ICANN context, Consensus Policies are a clearly defined term in all of the existing registry agreements[8]. 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 section[9] which can be used for ease of reference. The limitations on Consensus Policy provisions also provide a guide to areas to which the GNSO policy development process applies.

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

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

5.4 The strongest support was for recommendation 2A.3 that the present limitations to Consensus Policies are appropriate and should continue.

6. Term of Reference 2B: Relationship between registry agreements and consensus policies and delegation of responsibility Recommendation 2B: Certain policy making responsibility should be delegated to the sponsored gTLD operators.

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 http://www.icann.org/registries/agreements.htm and the sponsorship conditions can be found within those agreements, for example in the case of the .mobi agreement at http://www.icann.org/tlds/agreements/mobi/mobi-appendixS-23nov05.htm.

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

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

7.1 This Term of Reference was discussed in detail by Rapporteur Group B (RGB) which took responsibility for TOR 3, 4 and 6[10].

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

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

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

7.5 The NCUC argued that it 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, ISPCP and the CBUC 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.

Recommendation 4A: 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. Recommendation 4B: The ICANN Board should establish a Task Force or Advisory Committee to examine budgeting issues, including the manner and allocation of revenue collection, budget oversight, and budget approval processes. This group should solicit and review public comments on the issues.

8.1 This Term of Reference was discussed by Rapporteur Group B (RGB ) which took responsibility for TOR 3, 4 and 6[11]. The results of its discussion via teleconferences can be found in the report in the footnote below which was supplemented by discussion at the Task Force's meeting in Sao Paulo.

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

8.3 Five constituencies supported the recommendation with the RyC abstaining from the vote.

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.

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

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

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

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

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

9.2 In a straw poll at the Sao Paulo meeting, four Constituencies suggested that further work needed to be done which was followed up by conference calls on 16 January, 23 January, 6 and 15 February 2007[12]. On those calls there was disagreement about the nature of the problem to be solved by considering the question of registry data; scant agreement on what the problems actually were and what kind of information the RyC committed to provide to the group to assist with the discussions.

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

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

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

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.

Recommendation 6: ICANN should establish baseline requirements for the security and stability and security of 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

10.1 This Term of Reference was discussed and the recommendation was 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 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.

Annex One - Recommendation Summary Chart

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

TERMS OF REFERENCE ONE AND TWO

POLICY RECOMMENDATION	1A.1	1A.2	1A.3	1A.4	1A.5	1B.1	1B.2	2A.1	2A.2	2A.3	2B.1

CONSTITUENCIES
CBUC	Y	Y	Y				Y			Y	Y
ISPCPC	Y	Y	Y			Y		P	P	P	Y
IPC	Y	Y**		Y		A	A				Y
NCUC	Y				Y		Y			Y	Y
RC	Y	Y		Y		Y		Y			Y
RyC	N	?	Y		Y	A	A			Y	Y
Doria	Y	Y	Y				Y			Y	Y
Cubberley	Y
Bekele	Y	Y	Y				Y			Y	Y
Fausett	Y
Greenberg
TOTAL - CONSTITUENCIES	5	4	3	2	2	2	2	1		3	6
TOTAL - NV MEMBERS	4	2	2				2			2