RE: [gnso-vi-feb10] Preamble

[Jeff Eckhaus <eckhaus@xxxxxxxxxxxxxxx>]

I have a few comments /questions on the statements below:

Is there such a thing as defacto policy? Either there is a policy that all must 
abide by or contracts can be negotiated on an individual basis. I need some 
help understand this and how a negotiated contract between two parties can 
"eviscerate" this.

The other question I have is that if there is evidence or historical fact that 
shows that reversing a policy is "extremely difficult and costly"? I have not 
seen this to be a true or proven , but if it has been I would like to see the 
evidence.
If the statement is that it "could be extremely difficult and expensive" and 
this is just a guess, then I would like the wording to be changed to "extremely 
easy and unbelievably cheap" which is my guess or we could just refrain from 
using prejudicial language.

Thanks


Jeff



-----Original Message-----
From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
Behalf Of Mike Rodenbaugh
Sent: Wednesday, February 10, 2010 5:04 PM
To: gnso-vi-feb10@xxxxxxxxx
Subject: RE: [gnso-vi-feb10] Preamble


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