RE: [gnso-vi-feb10] Preamble

["Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>]

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