OK with me, Mawaki. --c.a. -----Original Message----- From: Milton Mueller <[log in to unmask]> To: [log in to unmask] Date: Fri, 29 Dec 2006 21:51:48 -0500 Subject: Re: [NCUC-DISCUSS] NCUC final position on PDP-Feb06' TORs > Looks good to me, Mawaki. > > --MM > > Dr. Milton Mueller > Syracuse University School of Information Studies > http://www.digital-convergence.org > http://www.internetgovernance.org > > >>> Mawaki Chango <[log in to unmask]> 12/27/06 1:39 PM >>> > Folks, > please find below the updated NCUC position on the TORs for the PDP > on existing registry contractual conditions (PDP-Feb06). If there is > no objections, I will forward it before the end of the year as our > final position. If there are objections, please propose a workable > formulation for the other to agree on. If there is no workable > alternative formulation, or no consensus (or agreement with those > involved in crafting the previous draft,) I will forward the current > version. > > Thanks for your understanding, and Happy New Year! > > Mawaki > > > TERM OF REFERENCE 1 > > ToR 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. > > Policy Recommendation A: > There should be a policy guiding renewal. > > NCUC: Yes > > Policy Recommendation B: > There should be a standard term for all gTLD registries that is a > "commercially reasonable length." > > NCUC: Yes (SP consensus), subject to the definition of "Commercially > reasonable" to be provided. > > Policy Recommendation C: > There should be a reasonable expectation of renewal for all registry > agreements. > > OR > > Policy Recommendation D: > There should be a renewal expectancy for all registry agreements. > > OR > > Policy Recommendation E: > There should be a presumption of renewal for all registry agreements > > NCUC: > > Current Option 3: no rebid unless there are repeated material > breaches. > > (Note: this is the Renewal Expectancy/Presumption of Renewal > Option as essentially expressed in the current .com etc contracts.) > > 1b. Registry agreement renewal standardization > ---------------------------------------------- > 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. > > Policy Recommendation F: > The 'right of renewal' should be standardized for all gTLD registry > agreements. > > OR > > Policy Recommendation G: > The 'right of renewal' should be standardized for gTLD registry > agreements except when there is an exceptional situation, such as a > situation of market dominance or market power. > > NCUC: G > > TERM OF REFERENCE 2 > Relationship between registry agreements and consensus policies > > 2.a > > Policy Recommendation H: > Consensus policies limitations are inappropriate. > > OR > > Policy Recommendation I: > Consensus policies should always apply to all gTLD registries. > > OR > > Policy Recommendation J: > Consensus policies should always be applied to all gTLD registries. > On an individual basis, during the contract negotiation, a registry > could present a situational analysis and justification, which should > be posted for public comment before acceptance/inclusion in the > contract, for an exception/or modification from a particular > consensus policy, due to unique circumstances of how a particular > policy would affect that registry. Such an exception will not create > any prejudice for extension to any other gTLD registry. > > OR > > Policy Recommendation K: > The present limitations to Consensus policies are appropriate and > should continue. > > NCUC: > Modified Policy Recommendation I: "Consensus policies should apply to > all gTLD registries after the nearest contract term ends." (Shouldn't > change a contract in mid-stream. After the contract ends if they > don't like it they can get out.) > > 2b. > > Policy Recommendation L: > > Certain policy making responsibility should be delegated to the > sponsored gTLD operators, but variations can be made, based on > 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: > > - Charter and scope of 'sponsored community' > - Eligibility to be in the 'sponsored category' > - Eligibility for a particular name > - The concept of a conflicts/dispute process as a service to the > sponsored community > > NCUC: Yes > > > TERM OF REFERENCE 3 > Policy for price controls for registry services > > Policy recommendation M (option 1) > > 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. > > If the panel determines that there is a situation of market power, > then the registry agreement must include a pricing provision for new > registrations, as currently is included in all of the largest gTLD > registry agreements. If the panel determines that there isn't market > power, then there would be no need for a pricing provision related to > new registrations, as is the practice in the recent round of sTLD > registry agreements. > > Regardless of whether there is market dominance, consumers should be > protected with regard to renewals due to the high switching costs > associated with domain names. Therefore, this policy recommendation > is to continue the system of pricing provisions in the current > unsponsored TLD agreements with regard to domain name renewals. > > The price for new registrations and renewals for market dominant > registries and for renewals for non-market dominant registries should > be set at the time of the renewal of the registry agreement. Such a > price should act as a ceiling and should not prohibit or discourage > registries from providing promotions or market incentives to sell > more names. In agreeing on such a price ceiling, ICANN should > consider the domain name market, the price of names in the prior > agreement, the market price in cases of competition through rebids, > and the specific business plans of the registry. > > The pricing provision should include the ability for an increase if > there is cost justification for such an increase, as is required in > the current registry agreements with pricing provisions. Such > increases should be evaluated and approved by a third party entity, > such as an accounting or financial analyst firm. > > Differential pricing between domain names should be prohibited > whenever there is a set price/price cap and should be permitted when > there isn't such a price constraint. In other words, non-dominant > registries may differentially price for new registrations, but not > for renewals. Dominant registries may not differentially price for > new registrations or renewals. > > Finally, as is the current practice, all registries should provide > equitable pricing opportunities for all registrars and at least six > months notice before any price increase. > > Policy Recommendation N (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.") > > Thus, another option is to keep the status 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). > > NCUC: N > > TERM OF REFERENCE 4 > ICANN fees > > 4a. Examine whether or not there should be a policy guiding registry > fees to ICANN, and if so, what the elements of that policy should be. > > > Policy Recommendation O: > 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. > > NCUC: Yes (SP consensus > > 4b. Determine how ICANN's public budgeting process should relate to > the negotiation of ICANN fees. > > Policy Recommendation P: > 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. > > NCUC: Yes (SP consensus) > > 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. > > Policy Recommendation Q: > There should be a policy regarding the use of registry data [which > includes traffic data] for purposes other than that for which it was > collected. > > NCUC: Yes (SP consensus) > > 5b. Determine whether any policy is necessary to ensure > non-discriminatory access to registry data that is made available to > third parties. > > Policy Recommendation R: > There should be a policy to ensure non-discriminatory access to > registry data that is made available, but that policy should include > safeguards on protection against misuse of the data. > > Agreed by all the TF members that further work is needed at the Task > Force level. > > NCUC: Yes (SP consensus) > > > 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. > > Policy Recommendation S: > There should not be a policy guiding investments in development and > infrastructure. ICANN should, however, establish baseline > requirements for the security and stability of the registries and > anything above that would be negotiated on a case-by-case basis, if > necessary. Such a baseline requirements should be recommended to the > Board by the Security and Stability Advisory Committee ("SSAC") after > consultation with the gTLD registry operators. In determining these > recommendations, the SSAC also should solicit and consider public > comments. > > Notes: Revised text developed by Jeff Neuman and Jon Nevett > > NCUC: Abstention until further clarification (there was no clear > consensus expressed here, but my suggestion ītaking into account > Avri's opinion and after reflection.)