>>> Mawaki Chango <[log in to unmask]> 12/5/2006 3:20 PM >>> >Policy Recommendation C: >There should be a reasonable expectation of renewal for >all registry agreements. > >Policy Recommendation D: >There should be a renewal expectancy for all registry agreements. > >Policy Recommendation E: >There should be a presumption of renewal for all registry >agreements > >NCUC: The constituency initially coined the option D, but may have to >consider C which is new and implies there will be a competitive bid >before renewal. Our position on this was worked out. We opposed competitive bidding, except for .net. So we would favor D combined with G (see below). Except that "market power" is not really the problem with .net, so G would have to be reworded. Basically, it is acceptable to rebid the TLDs that VeriSign had legacy control of and were supposed to be re-assigned under the agreement that led to the reassignment of .org. (i.e., .net) That does not include .com, which they get to keep under the same renewal expectancy. >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 (SP consensus) >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. > >NCUC: J (SP consensus) yuk. that's horrible. too discretionary. I would favor something like a 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.) >TERM OF REFERENCE 3 >Policy for price controls for registry services >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 Yeah! Good stuff. Also, the "market dominance" analysis in the Option 1 is fallacious from an economic point of view. To an individual registrant with an established domain, opportunistic pricing hurts them whether or not the registry is dominant in the total market. >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 and P: > >NCUC: Yes (SP consensus) Fine by me. >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) Yes. duh. >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. Hmm, why make it avvailable at all? good work y'all!