Re: [gnso-vi-feb10] Preamble

[Avri Doria <avri@xxxxxxx>]

On 10 Feb 2010, at 19:57, Stéphane Van Gelder wrote:

> Thanks Avri,
> 
> 2 questions:
> 
> - Why do you think not making the Feb 18 meeting time would push the charter 
> back 3 weeks? We should be able to finish the charter on or around the 18th 
> and therefore submit to the Council, maybe for discussion on list. As there 
> is a 16-week time limit on this PDP, I'm sure Council would like to start 
> looking at the charter asap. Maybe even discuss online approval...

my assumption is that the approval of the charter will wait until Nairobi.  If 
I am wrong and it is approved sooner, great.   i thought it could be done today 
and look how wrong I was about that. it will take 4 weeks for the charter, 
though that may extend to six.


> 
> - The Issues Report implied that we face restrictions if we attempt to set 
> policy for existing gTLDs. If would like to get clear indications from Staff 
> on this. As a reminder, the motion states that the PDP "shall evaluate which 
> policy recommendations, if any, should be developed on the topic of vertical 
> integration between registrars and registries affecting both new gTLDs and 
> existing gTLDs, as may be possible under existing contracts and as allowed 
> under the ICANN Bylaws". We should therefore not proceed under the given 
> assumption that policies should be developed for existing gTLDs. The wording 
> is "if any". However, should this be the case, I would like to have some 
> instructions from Staff on whether we are able to set policy for existing 
> gTLDs through this process or not.

As I said, i do not believe this PDP can make consensus policy foe existing 
gTLDs.  I would think that we would need a very specific motion to do that. 
I do believe this PDP can investigate and make recommendations on whether any 
current practice is not harmonious with the policy/guidelines defined in 
objective 1.  i believe that once we see what those issue are, we can determine 
whether they can be fixed via consensus policy or by asking the registrar and 
Registries to pretty please change their practice to match the 
policy/guidelines.

I think it is only reasonable that when we define policy and guidelines in a 
space where the staff says there is not policy, though I believe there is  
defacto policy, we need to check current practice against that new policy, and 
if there is a discrepancy look at whether and how we can fix it.  I also 
beleive tat is what is mandated in the PDP the council approved.

BTW, I do not believe staff can answer the question of whether recommendation A 
based on the criteria developed in objective 1 regarding gTLD XYZ  is in scope 
for a consensus policy until such time as we have resolved the criteria in 
objective  1 and know what recommendation A and gTLD XYZ are.

but I repeat while we may be able to create policy that would be applied to new 
gTLDS, with the board's blessing, i do not believe we can make consensus policy 
on current gTLDS, only recommend future actions.  and we cannot know whether 
the recommendation of objective 3 warrant such a recommended future action 
until we have completed objectives 1 & 3.


> 
> The GNSO is overworked enough as it is. I don't think we want to see it 
> applying itself on things that aren't useful.

I think this is useful.  and I  believe that it was voted in as a PDP (though 
the future consensus policy actions, if any, weren't).
the GNSO may be busy, but I for one do believe this is an essential task.

a.

> 
> Stéphane
> 
> Le 9 févr. 2010 à 23:57, Avri Doria a écrit :
> 
>> 
>> Hi,
>> 
>> I wanted to make a few follow-up comments to those I made about consensus 
>> policy and refer them to the preamble.
>> 
>>> Preamble:  The working group on vertical integration shall evaluate policy 
>>> recommendations for [new gTLDs only] [new gTLDs and existing gTLDs.  As 
>>> explained in the Issues Report, the working group may be restricted in its 
>>> ability to create Consensus Policies under existing registry agreements.] 
>>> [The working group expects to define the range of restrictions on vertical 
>>> separation that are currently in effect, to serve as a baseline to evaluate 
>>> future proposals.]
>> 
>> I think that the policy/guidelines this group recommends should be 
>> applicable across gTLD registries, old and new.  
>> 
>> Once approved, I believe they should apply to the new GTLDs in this first 
>> round.  The policy/guidelines do not necessarily have to be complete for the 
>> next DAG, but they do need to be completed, community reviewed and board 
>> voted on before the final guidebook.  While I think we should be done before 
>> DAGv4 (does anyone know the real schedule on that), if we aren't then the 
>> DAGv4 should leave a place holder on this topic.
>> 
>> On the question of their applicability to existing gTLDS, I think the issue 
>> is more complex.  I do _not_ see this PDP as being able to produce consensus 
>> policy on that - I think in the case of  consensus policy that would change 
>> the condition in an existing arrangement,m the PDP question would have to be 
>> quite specific.  What I think this PDP can do, and should do, in relation to 
>> the existing arrangements is measure then against the policy/guideline 
>> produced in this PDP and recommend whether further work on consensus 
>> policies should be considered by the GNSO and GNSO Council.  In doing this 
>> the WG should produce a list a very specific areas/questions, if any are 
>> found, in which a consensus policy PDP would be recommended.
>> 
>> In deference to 
>> 
>>> {Objective 4:  To perform the PDP activities in a manner that does not 
>>> delay the launch of the New GTLD Program. }
>>> 
>> 
>> We may want to set two deliverables, 
>> - one the Policy/guideline on all gTLDS and the analysis of the options on 
>> VI included in DAGv3.   (Obj 1,2)
>> - and the other the recommendation for consensus policy action, if any, for 
>> existing gTLDs. (Obj 3)
>> 
>> The part of me that wants to be optimistic about our ability to get this all 
>> done in 6 weeks wants to argue against this approach.  But some aspects of 
>> reality dawned on me today when it became obvious we could not have a 
>> charter in time for the meeting on 18 Feb.  The extra 3 weeks spent on the 
>> charter means we probably could not deliver objective 3 in 16 weeks - if 
>> ever we could have (with  deference to MM having called it impossible from 
>> day 1).  But in deference to Objective 4, delivering on Objectives 1&2 by 
>> May 14 might be a start. With Obj 3 a month later.
>> 
>> 
>> a.
>> 
>> 
>