Hi,

You have obviously ignored my point that there is a continuum between the subjects - that they are not totally separate - some of the things you consider not vertical integration can function as if they were vertical integration.    I think you are missing this critical point.  And if you cover just VI and not the others, you will be leaving in the invitation to workaround, and gaming the system.

fine, we will disagree on this.  Please feel free to cal me confused for disagreeing with yo.  I can live with it.

I think the only way it can be resolved is in one PDP that covers both and you see that as a disaster.    I guess the others will have to decide

a.

On 21 Jan 2010, at 21:03, Milton L Mueller wrote:

> I realize it is too late to change this probably, but you all need to benefit from the following observations.
> 
> First, I truly appreciate the efforts that have been made to incorporate my views into the resolution. Ultimately, that effort failed rather badly, as I will explain below, but it was clearly not intentional and was, instead, based on the persistent confusion that surrounds proper use of the term "vertical integration" and the proper scope of the PDP.
> 
> For me, yesterday was a very bad day for this to be happening and my responses were truncated and distracted. Now that I have time, let me catalogue what I see as the remaining issues. And notice that I am copying NCUC-discuss. I have noticed an alarming tendency for policy discussions to get pushed into NCSG-policy. This is inappropriate. NCSG-policy is a list Avri created that contains exactly 9 people, and whatever goes on there excludes our membership entirely. When debating constituency positions, lets include the constituency, OK?
> 
> Joint marketing and Cross ownership are not vertical integration.
> No one who knows anything about the proper economic use of the term will disagree with that.
> 
> I have supported a PDP on Vertical Integration. VI is a long term issue that we need to consider.
> 
> Here is the key problem. EITHER we favor a PDP that takes up the issue of whether JM/CO as proposed in the Draft Applicant Guidebook (DAG), is allowable or not. This is a short-term issue.
> 
> OR we favor a PDP that takes up the issue of whether VI should be allowed in some form in the future. This is a long-term issue.
> 
> By conflating the two in the same PDP proposal, you are creating a great deal of confusion and opening a policy can of worms that will, in the end, make the proposed PDP fail for sure.
> 
> THE SAME PDP CANNOT SERVE BOTH FUNCTIONS!!! The first, short-term issue is basically a matter of classifying existing practices and would have as its output a modification of the next version of the DAG. The time line for such a PDP would be, necessarily, very short.
> 
> The long-term issue is a matter of changing fundamental policy regarding registry-registrar relations. Its output would be basic contractual modifications, and even a re-examination of ICANN fee policy.  The timeline for this will be very long, at least two years. (Mark my words).
> 
> If you want to have a long-term, policy changing PDP about VI, do it - and you have my support. If you want to have a PDP addressing the short term issue of whether JM/CO is an "implementation" of current policy, do that (without my support).
> 
> But you can't do both in the same PDP.
> 
> What will  happen now is that a) Registrars will, and rationally should, actively oppose this PDP when they would have supported a long-term PDP on the VI issue; b) the issue of what is vertical integration will be confused rather than clarified, because registries and registrars will carry their short-term fight over the content of the DAG into the longer-term issues; c) we will not reach a timely agreement because the long term issues are so deep, so yet another obstacle to new entry and a new DAG will have been erected.
> 
> Bad move.
> 
> 
> (1) Initiation of a Policy Development Process (PDP) in relation to the following tasks:
> (a)  Follow up on the Issues Report by reviewing (i.e. documenting, categorizing and differentiating between) the current existing approaches being used by incumbents for vertical integration between and among Registries, Registrars, Registrar Service Providers and Resellers, and proposals relating to vertical integration received or proposed by ICANN. Such analysis shall include an evaluation of the DAGv3 proposal and consider its appropriate categorization within the current framework. Such analysis shall proceed on the basis that "vertical integration" is a broader concept than certain current Registry and Registrar practices that may more accurately be described as "joint marketing" and/or "cross ownership".  
> 
> (b) Review and propose conditions under which each of the approaches documented in item 1(a) may be appropriate, including determining (where applicable) when a particular approach is or is not a matter of policy. Such review shall also consider whether there are appropriate circumstances where joint marketing and/or cross ownership may be desirable as a matter of policy.
> 
> (c) Make recommendations for clarifying and revising (if warranted) ICANN policies on vertical integration, joint marketing and cross-ownership.  In relation specifically to new gTLDS, an alternate recommendation shall be made if the it is determined that the DAGv3 recommendation on Registrars marketing 100,000 in an affiliated Registries TLD is not appropriate. Such alternate recommendation shall make provisions for private strings and for strings that have a limited market appeal.
> (2) Establishment of a Working Group (WG) to develop recommendations for adoption by the GNSO Council, regarding the tasks identified in item (1) above. The Working Group will operate according to the Process as defined by the PDP Working Team on Working Group Processes, in https://st.icann.org/data/workspaces/icann-ppsc/attachments/working_group_team:20100113101755-0-1556/original/Working%20Group%20Guidelines%20-%20FINAL%20-%207%20January%202010.pdf.
> 
> (3) Creation of a GNSO Council drafting team to draft a charter for the WG, recruit volunteers from the GNSO constituencies and the ICANN community, and appoint a liaison between the WG and the GNSO Council. The GNSO Council shall review and approve the charter by [date], upon which the WG shall commence its work. 
> 
> (4) Request ICANN Staff to begin documentation of existing approaches to vertical integration (as described in item 1(a) above) and collect constituency statements within four weeks of the establishment of the WG.
> 
> 
> 
> Mary W S Wong
> Professor of Law & Chair, Graduate IP Programs
> Franklin Pierce Law Center
> Two White Street
> Concord, NH 03301
> USA
> Email: [log in to unmask]
> Phone: 1-603-513-5143
> Webpage: http://www.piercelaw.edu/marywong/index.php
> Selected writings available on the Social Science Research Network (SSRN) at: http://ssrn.com/author=437584
> 
> 
>>>> 
> From:	Avri Doria <[log in to unmask]>
> To:	NCSG-Policy <[log in to unmask]>
> Date:	1/20/2010 5:04 PM
> Subject:	[ncsg-policy] Re: Fish or cut bait time
> 
> On 20 Jan 2010, at 16:17, Mary Wong wrote:
> 
>> we can unearth common ground on that with Milton.
> 
> In another airport - Newark this time.
> 
> If Milton accepts my rewrite and we stealing some  the Wheras from the staff, we get:
> (If Milton does not accept, please suggest wording changes)
> 
> A council member would need to send this in.
> 
> a.
> 
> 
> -----
> 
> Whereas, 
> 
> On 24 September 2009, the GNSO Council requested ICANN Staff to prepare an Issues Report on the topic of vertical integration between registries and registrars;
> 
> On 11 December 2009, the Issues Report on Vertical Integration between Registries and Registrars was delivered to the GNSO Council and has been discussed in the council and in the various Stakeholder Groups,
> 
> Resolved:
> 
> A PDP will be initiated with the following tasks
> 
> 1.  Document, categorize and differentiate the current existing approaches being used by incumbents and proposed for Vertical Integration, Joint Marketing and Cross Ownership among Registries, Registrars, Registar Service Providers and Resellers. This analysis will include an evaluation of the DAGv3 proposal and its place in the categorization.
> 
> 2. Review and Document the conditions under which each of the approaches documented in item 1 are appropriate. If certain approaches are determined to not be subject to ICANN policy document that.
> 
> 3. Make recommendations for clarifying and revising, if warranted, the policies on vertical integration, joint marketing and cross-ownership.  In terms of new gTLDS, If the WG does not support the DAGv3 recommendation on Registrars marketing 100,000 in an affiliated Registries TLD, make an alternate recommendation that makes provisions for private strings and strings that have a limited market appeal.
> 
> The PDP wil use establish a Working Group to respond to the issues and will not establish a Task Force.   The Working Group will work according to the  Process as defined by the PDP Working Team on Working Group Processed defined in https://st.icann.org/data/workspaces/icann-ppsc/attachments/working_group_team:20100113101755-0-1556/original/Working%20Group%20Guidelines%20-%20FINAL%20-%207%20January%202010.pdf.
> 
> The PDP will proceed on a  schedule according to the following:
> 
> Week 1,2  - Council Drafting team will create a charter for the group ad the original recruitment for group members wil go out to the constituencies and the ICANN community. Staff begins documentation on existing approaches and practices.  
> 
> Week 3 - Council review charter and appoint liaison.
> 
> week 4 - Group begins work.  
>               (Collect Constituency statement weeks 1-4)
> 
> week 5,6 - Review of existing document and commentary. Publish Staff document on existing approaches and practices
> 
> week 7,8 - Review staff document and constituency and public comments
> 
> week 8-10 - Discuss condition under which various practices are appropriate
> 
> week 11-12 - Discuss policy recommendations
> 
> week 13-  Public review Starts
> 
> Any amendment to this schedule will require review by the GNSO council.
>