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