Re: [gnso-vi-feb10] Preamble

[Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>]

Thanks Mike.

Stéphane

Le 11 févr. 2010 à 18:30, Mike Rodenbaugh a écrit :

> 
> Stephane, that is correct, additional Staff work need not delay the
> Charter... though indeed it could start even before Council approves a
> Charter, in effort to keep this PDP moving on the very tight schedule set by
> Council.
> 
> Mike Rodenbaugh
> RODENBAUGH LAW
> tel/fax:  +1 (415) 738-8087
> http://rodenbaugh.com 
> 
> 
> -----Original Message-----
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx]
> On Behalf Of Stéphane Van Gelder
> Sent: Thursday, February 11, 2010 3:10 AM
> To: icann@xxxxxxxxxxxxxx
> Cc: gnso-vi-feb10@xxxxxxxxx
> Subject: Re: [gnso-vi-feb10] Preamble
> 
> 
> Thanks Mike,
> 
> The BC's request are duly noted. I have asked Margie to group all comments
> made so far (Milton, Avri, yourself) into the draft charter she sent the DT
> after our call earlier on in the week. As the deadline we set for edits is
> today, I have asked Margie to send to the list the updated draft later on
> today.
> 
> Once that is done, may I remind the group that comments should be made by
> Monday Feb 15 at the latest. Margie and I will then work to include the
> consensus points into the charter and present the group with a finalized
> charter for approval by Tuesday 16 if we can make that deadline.
> 
> That being said, I presume that when you request further Staff analysis, you
> are suggesting that the WG request that analysis and include it in their
> work, rather than have the charter delayed until Staff can provide said
> analysis?
> 
> Stéphane
> 
> Le 11 févr. 2010 à 02:04, Mike Rodenbaugh a écrit :
> 
>> 
>> Avri said:  i do not believe we can make consensus policy on current
> gTLDS,
>> only recommend future actions
>> 
>> I respectfully disagree.  Wasn't this battle fought over PDP '06 --
>> Contractual Conditions, and resolved that in fact the Registry Agreements
>> mean what they say... Consensus Policy generally can be adopted so long as
>> the issue is not excluded within the 'picket fence'?  
>> 
>> I think it was.  So I also support Stephane's call for more info and
>> analysis from ICANN counsel as to how they came to that (contrary)
>> conclusion again now, and how that harmonizes with PDP '06 policy.  We
> also
>> should see their analysis of the relevant RAA language, since the Issues
>> Report only addressed the .ORG registry agreement language on this issue.
>> That portion of the Issues Report (p. 18-21) seems to ignore the plain
>> meaning of the words "without limitation" in the Consensus Policy
> clause...
>> 
>> "Consensus Policies shall relate to one or more of the following... (4)
>> registry policies reasonably necessary to implement Consensus Policies
>> relating to registry operations or registrars; ....  Such categories of
>> issues referred to in the preceding sentence shall include, without
>> limitation: ....  
>> 
>> While #4 is somewhat circular and thus poorly drafted, it cannot be
>> disregarded.  I interpret it to mean that Consensus Policy may be
> developed
>> as to any issue affecting registry operations, unless excluded by the next
>> section of the contract, which lists the nine topics on which Consensus
>> Policy cannot touch -- and this issue is not excluded.  This
> interpretation
>> makes sense, not only in light of the English language, but also in light
> of
>> the entire point of Consensus Policy, that it must also have the input and
>> advice of the contract parties in order to be approved. 
>> 
>> I agree with Avri that there has long been de facto policy in place, as
> set
>> forth in the com/net/org agreements and only recently eviscerated in a few
>> of the newer TLDs, via bilateral negotiations between ICANN Staff and
> those
>> registries.  That policy clearly affects registry operations insofar as it
>> limits their cross-ownership of registrars.  So even if #4 above is
>> circular, this situation is even more clearly within the scope of GNSO
>> policy purview, for any gTLDs.  
>> 
>> Re new gTLDs, the Business Constituency urges Staff to preserve the status
>> quo as set forth in com/net/org agreements, within the new gTLD registry
>> agreement, unless and until such time as the policy is changed by
> Consensus
>> Policy.  If Consensus Policy is developed which would loosen those
>> restrictions, then we are confident that would be welcomed by the new
>> contracting parties at that time.  However, if Staff continues on the
>> present course, it will substantially loosen these restrictions for new
>> gTLDs on its own volition.  If Consensus Policy later is developed which
>> would require more restrictions than the Staff has implemented, then it
>> could be extremely difficult and costly to impose them retroactively, if
>> even possible.  
>> 
>> Staff says we should trust them, and re-evaluate their policy decision in
>> two years.  But they do not attempt to explain how this genie could be put
>> back in the bottle later, and I do not see how it could realistically be
>> done.  So it would be a dangerous precedent, effectively allowing Staff to
>> create intractable policy on an important issue like this.  
>> 
>> The BC would like these concepts addressed in the Charter, to the extent
>> they are not already there.  Specifically:  
>> 
>> 1.  We would like this sentence stricken from the Preamble:  As explained
> in
>> the Issues Report, the working group may be restricted in its ability to
>> create Consensus Policies under existing registry agreements.  
>> 
>> 2.  We suggest that Objective 4 incorporate a call for Staff to maintain
>> status quo in the DAG, so the new gTLD program need not be delayed, nor
>> subject to controversy over this issue.
>> 
>> 3.  We call for further analysis from ICANN Staff as to their reasoning
>> within the Issues Report (p. 18-22) as discussed in this thread, including
>> analysis of relevant RAA language.
>> 
>> Thanks,
>> Mike
>> 
>> Mike Rodenbaugh
>> RODENBAUGH LAW
>> tel/fax:  +1 (415) 738-8087
>> http://rodenbaugh.com 
>> 
>> 
>> -----Original Message-----
>> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx]
>> On Behalf Of Avri Doria
>> Sent: Wednesday, February 10, 2010 2:13 PM
>> To: Gnso-vi-feb10@xxxxxxxxx
>> Subject: Re: [gnso-vi-feb10] Preamble
>> 
>> 
>> 
>> 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.
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> 
>