ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [council] Registry Operators et al

  • To: "Avri Doria" <avri@xxxxxxx>
  • Subject: RE: [council] Registry Operators et al
  • From: "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Date: Thu, 16 Jul 2009 08:48:04 -0700
  • Cc: "Council GNSO" <council@xxxxxxxxxxxxxx>
  • List-id: council@xxxxxxxxxxxxxx
  • Reply-to: "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Sender: owner-council@xxxxxxxxxxxxxx
  • User-agent: Web-Based Email 5.0.28

> well defined and well established criteria

Do you feel that exists? I don't think it really does
right now.

> Possibly the SIC, when it gets breathing room, should 
> make sure that this well formed process exists and is 
> well documented.

Agree.


Tim

-------- Original Message --------
Subject: Re: [council] Registry Operators et al
From: Avri Doria <avri@xxxxxxx>
Date: Thu, July 16, 2009 8:57 am
To: Council GNSO <council@xxxxxxxxxxxxxx>



Hi,

I think we need to be careful that we do not make the threshold too 
high. I think it is also very important that the incumbent 
constituencies not have the ability to thwart the aspirations of new 
constituencies. One of the key virtues of the reorganization was 
supposed to have been the ability to add new constituencies. As 
things are progressing, I sometimes worry that we will find we have 
gone through all of the restructuring 'improvements' and will have 
left the scenario still closed to new constituencies.

I think this is one of the reasons that it is reasonable that the 
authority to create new constituencies must reside with the Board, and 
that the conditions should be set out in a way where no incumbent 
constituency, or group of constituencies, can prevent the creation of 
a new constituency if it meets well defined and well established 
criteria (including the right of community and constituency comment) 
and follows a proper course of candidacy.

Possibly the SIC, when it gets breathing room, should make sure that 
this well formed process exists and is well documented.

a.




On 16 Jul 2009, at 09:44, Terry L Davis, P.E. wrote:

>
> Tim
>
> I very much share your concerns with the creation of new 
> constituencies and the associated disruptions necessary to 
> accommodate them. As you said, the threshold needs to be extremely 
> high.
>
> Take care
> Terry
>
>
>> -----Original Message-----
>> From: owner-council@xxxxxxxxxxxxxx [mailto:owner-
>> council@xxxxxxxxxxxxxx] On Behalf Of Tim Ruiz
>> Sent: Wednesday, July 15, 2009 7:21 AM
>> To: GNSO Council
>> Cc: Bruce Tonkin
>> Subject: RE: [council] Registry Operators et al
>>
>>
>> Some personal thoughts not vetted with the RrC: I think the bar for 
>> new
>> constituencies should be set fairly high. One of the main puposes of
>> the
>> restructuring is to focus the actual policy work within the WG model,
>> and less at the Council level.
>>
>> Do backend registry service providers (not contracted with ICANN)
>> really
>> need to be represented through membership in any new or existing
>> constituency? Or are their likely interests already well represented
>> through the RyC and/or RrC?
>>
>> Do City/Geo gTLD operators truly represent interests unique enough to
>> be
>> considered a consitituency? Or can there primary interests already be
>> well represented through membership in the existing RyC? They may 
>> well
>> represent a special interest group within the RyC, but it seems
>> unnecessary to form an entirely new constituency.
>>
>> Do users whose special interest is security or safety truly 
>> represent a
>> new constituency? Is there any valid reason why those users' 
>> interests
>> cannot be dealt with in one of the existing User constituencies
>> depending on whether they are commercial or non-commercial?
>>
>> It seems dangerous and unnecessary to me to start splintering off
>> special interest groups into their own constituencies. And remember,
>> anyone can participate in the PDP WGs, and under the new structure 
>> that
>> should be a bigger concern than having your own special interest
>> represented on the Council.
>>
>> Regarding gTLD applicants, or entities intending to become accredited
>> as
>> registrars, etc. Is there any reason they cannot be allowed as
>> observers
>> into the appropriate constituency until such time as they qualify 
>> to be
>> members?
>>
>> I think that where we are seemingly headed right now with regards to
>> new
>> constituencies is too complicated and ultimately unworkable. Th
>> threshold needs to be extremely high. In fact, I think it would be
>> difficult to identify an interest group that is cannot fit into an
>> existing consituency AND is large enough to warrant its own.
>>
>> Tim
>>
>> -------- Original Message --------
>> Subject: [council] Registry Operators et al
>> From: "Philip Sheppard" <philip.sheppard@xxxxxx>
>> Date: Wed, July 15, 2009 3:10 am
>> To: "'Council GNSO'" <council@xxxxxxxxxxxxxx>
>> Cc: "'Bruce Tonkin'" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
>>
>>
>>
>> As I pointed out months ago on this list, there is a fundamental
>> disconnect in
>> two significant GNSO changes:
>> a) the bicameral model
>> b) new constituencies.
>>
>> The bicameral model compromise thrashed out last summer was an
>> agreement
>> between
>> the existing constituencies who all neatly fit into the two Houses.
>> The subsequent belief that new constituencies are needed has exposed
>> the
>> impossibility of the bicameral compromise: they do not fit.
>>
>> Trying to fit supply-related constituencies to the user-related House
>> introduces
>> such conflict and dilution that it brings the very credibility of 
>> ICANN
>> into
>> question.
>>
>> There are solutions:
>> a) change the Houses to be Supply-side and User-side
>> b) abandon new Constituencies
>> c) abandon the bicameral approach and remove contract parties from 
>> the
>> GNSO
>> leaving their main ICANN involvement as bilateral negotiators (and as
>> participants in GNSO working groups)
>>
>> I suggest none of these solutions has universal appeal.
>>
>> Philip
>>
>>
>
>
>
>
A





<<< Chronological Index >>>    <<< Thread Index >>>