Re: [gnso-vi-feb10] Preamble

[Avri Doria <avri@xxxxxxx>]

Hi,

The reason I think it is necessary to go back and ascertain that current gTLDS 
meet any new policy/guidelines on VI and to recommend changes were it may 
appear necessary is, as much as it is possible, to bring old gTLD and new gTLDs 
under the same policy rules.


a.


On 12 Feb 2010, at 04:28, Jean Christophe VIGNES wrote:

> 
> I too would like to know more but would also need to be convinced from a
> practical standpoint.
> 
> The main reason the VI debate is so "hot" right now is because of new gTLDs:
> what would we be looking to achieve with regards to existing ones? Even if
> it would be possible from a legal standpoint (which remains to be confirmed)
> I don't see the point.
> 
> So as far as drafting goes, I believe the Charter should only cover new
> gTLDs.
> 
> On Objective 1, standard is too imprecise since history shows there has been
> variation -- as stated on the call I believe "current" would be a better
> choice.
> 
> As for Objective 2, I agree CO should be mentionned as a separate concept
> and reference should be made to "equal access"  as it is a key factor in the
> VI debate.
> 
> I'm not sure Objective 3 is even practical, to be honest...
> 
> Objective 4 is a must.
> 
> JC
> 
> Le 11/02/10 02:04, « Mike Rodenbaugh » <icann@xxxxxxxxxxxxxx> 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.
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> ______________________
> Jean-Christophe Vignes
> 
> Executive Vice-President & General Counsel
> DCL Group
> 2, rue Léon Laval
> L-3372 Leudelange
> 
> Tel.:  +352  20 200 123
> Mobile : +352 691 600 424
> Fax.:   +352 20 300 123
> Mailto: JCVignes@xxxxxxxxxxx
> 
> www.datacenter.eu   | www.eurodns.com   | www.voipgate.com
> 
> 
> --------------------------------------------------------
> 
> This e-mail and any attached files are confidential and intended solely for 
> the use of the individual or entity to whom they are addressed. If you have 
> received this e-mail by mistake, please notify the sender immediately and 
> delete it from your system. You must not copy the message or disclose its 
> contents to anyone.
> 
> Think of the environment: don't print this e-mail unless you really need to.
> 
> --------------------------------------------------------
>