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

Task Force Report

Policies for Contractual Conditions

Existing Registries (PDP Feb 06)

8 March 2007

Author: Dr Liz Williams

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

8 March 2007: draft Task Force Report posted for 20 day public comment period ending 28 March 2007

Glossary

Acknowledgments

1. Introduction

2. Recommendation Summary

3. Term of Reference 1A: Registry agreement renewal

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

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

6. Term of Reference 2B: Relationship between registry agreements and consensus policies and delegation of responsibility

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 - Recommendation Summary Chart

Annex Two - Policy Development Process Background Information

Annex Three -- Participation Data

Annex Four -- Constituency Statements and Rapporteur Group Input

References

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.

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

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

TERMS OF REFERENCE THREE, FOUR, FIVE AND SIX

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.

Annex Two - Policy Development Process Background Information

1.1   The Task Force has held a series of meetings, the minutes of which are available online[14]. The first meeting of the Task Force, conducted during the ICANN Wellington meeting in March 2006, elected Nominating Committee representative Maureen Cubberley as Task Force Chair and set out the work of the group by agreeing a Task Force Charter and work timeline. During the course of the Task Force's work, Avri Doria took over the chairing of the group.

1.2   At the 6 June 2006 meeting, the detailed work of the Task Force began with discussion of the first draft of the Preliminary Taskforce Report[15]. 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 http://gnso.icann.org/issues/gtld-policies/issues-report-02feb06.pdf.

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

1.7   At its meeting on 6 February 2006^[16], 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 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 agreements[17].

Annex Three -- Participation Data

The data found here is designed to show the nature and frequency of participation in the Task Force's work. A full and complete chart will be included in the Board Report after the Task Force has completed its deliberations. Maureen Cubberley was elected Task Force Chair at the Wellington meeting. Avri Doria was appointed Interim Chair when Ms Cubberley's Nominating Committee term expired. Ms Doria then replaced Ms Cubberley as the Chair and completed the work of the Task Force.

Rapporteur Group A: Attendance List[18]

Rapporteur Group B: Attendance List[19]

Annex Four -- 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 http://www.icann.org/announcements/announcement-11apr06.htm.

2. The Registries' Constituency submitted its Statement in conformance with the PDP guidelines[20].

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.

8.One response to the Call for Papers was submitted from Mr Matt Hooker, President of LowestPriceDomain, a domain name supplier found at 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).

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

CS: 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... "The Constituency believes that an attempt to set a policy guiding renewal is not properly within the scope of a GNSO PDP.^[21]

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.

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

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.

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

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

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

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.

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

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.

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

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

RGA^[22]: 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.

RyC... "...for the reasons stated above, this is not a proper question for this PDP."

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

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

NCUC... did not address this question directly.

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

ISPCP... "The ISPCPCP Constituency holds that rights of renewal should be standardized across all future agreements."

RGA: TOR 1b

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

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

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

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

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

6. Further discussion about the level of support for the proposed policy recommendation is required to reconcile, for example, the Registry Constituency's position that this area is outside the scope of the GNSO's policy development remit with that of, for example, the Alistair Dixon Business Constituency, which argued that "...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 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"^[25].

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

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

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

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

RGA: TOR 2a

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

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

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

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

[3.1](b) Consensus Policies.

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

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

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

(iv) Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders. Consensus Policies shall relate to one or more of the following: (1) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, Security and/or Stability of the Internet or DNS; (2) functional and performance specifications for the provision of Registry Services (as defined in Section 3.1(d)(iii) below); (3) Security and Stability of the registry database for the TLD; (4) registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; or (5) resolution of dISPCPutes regarding the registration of domain names (as opposed to the use of such domain names). Such categories of issues referred to in the preceding sentence shall include, without limitation:

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

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

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

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

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

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

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

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

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

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

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

CS: TOR 2b: Delegation of policy making

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

RC... "...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... "...such delegation is appropriate only to the extent it does not conflict with ICANN policies (or is specifically justified, see preceding answer). The gatekeeping/charter enforcement role of sponsored TLD operators should be given paramount importance".

NCUC... made no further direct comment on this section.

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

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

ISPCP... "The ISPCPCP recognizes that sponsored TLDs may need to establish policies regarding membership in their respective communities. These policies should be developed according to a well-defined, transparent process in cooperation with the GNSO."

RGA: TOR 2b

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

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

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

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

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

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

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

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

9. .museum sponsorship agreement at Attachment 2 of the .museum registry agreement (http://www.icann.org/tlds/agreements/museum/sponsorship-agmt-att2-20aug01.htm)

CS: 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"^[26].

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

a) We must not assume that ICANN contracts are the proper mechanism

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.

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.

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.

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

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

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

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... "...a registry must justify any price increases if there are price caps in the registry agreement. Such justification should be objectively evaluated by an independent 3^rd party".

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

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

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

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.

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

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

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] [ISPCP] [any other constituency] fees to ICANN?"

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

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

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

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

ISPCP... "The ISPCPCP Constituency favors the development of policy regarding registry fees paid to ICANN. Fees must be uniform across registry contracts. ICANN must make a convincing case for any change to fees, based on its operating and strategic plans. The process of raising fees must be open and transparent."

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

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

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

ISPCP... " See 4a."

RGB: TOR 4a & 4b

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

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

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

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... "...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".^[27]

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

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

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

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

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

Overall, the purpose of collecting such data should be limited to the fulfillment of the business functions within the delivery of registry services-e.g. the purpose for which the data is gathered."

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

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

RyC... "...this is also an area where local law must be considered".

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

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

NCUC had no further comments to add on this part.

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

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

ISPCP... "The ISPCPCP Constituency believes non-discriminatory access to registry data that is made available to third parties is essential."

RGA: TOR 5a & 5b

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

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

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

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

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

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

CS: TOR 6 -- Investments in development and infrastructure

6a. Examine whether or not there should be a policy guiding investments in development and infrastructure, and if so, what the elements of that policy should be.

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

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

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

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

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

RGB: TOR 6

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

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

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

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

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

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 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 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 (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 Preliminary Task Force Report. (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. (http://gnso.icann.org/issues/gtld-policies/tld-contract-policies-16jun06.pdf)

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

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

9.       After feedback from the Task Force, the updated Expert Materials were released in September 2006 (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-agreements-20061009.htm)

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

Guermazi, Boutheina and Isabel Neto, Mobile License Renewal: What are the issues? What is at stake?, available at http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/23/000016406_20050923113019/Rendered/PDF/wps3729.pdf

Matsui, Masayuki, Comparing Domain Name Administration in OECD Countries, available at 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 http://www.oecd.org/dataoecd/14/45/36471569.pdf

Further detailed materials are contained with the Expert Materials documentation reference above.