ICANN ICANN Email List Archives

[gnso-arr-dt]


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

Re: AW: [gnso-arr-dt] Re: Finalizing the RT process

  • To: gnso-arr-dt@xxxxxxxxx, "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Subject: Re: AW: [gnso-arr-dt] Re: Finalizing the RT process
  • From: William Drake <william.drake@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 28 Apr 2010 11:09:12 +0200

Hi

Consolidated response to Chuck's recent posts...

On Apr 26, 2010, at 10:18 PM, Gomes, Chuck wrote:

> Here are the personal comments I sent to Marco and the SOAC list regarding 
> the draft call for candidatures.

All made sense to me..


On Apr 26, 2010, at 10:01 PM, Gomes, Chuck wrote:

> Regarding the timing of our work, note that the draft request for 
> applications that I forwarded from Marco today says the following: 
> "Applicants interested in being considered for endorsement by the [name of 
> SO/AC] are also invited to include in their candidature the additional 
> information required by [name of SO/AC, hyperlink]."  If this stays this way, 
> then we will need to have our requirements for additional information 
> approved by the Council prior to the final annoncement being posted by ICANN. 
>  Ideally, it would be great if we were able to get Council approval of the 
> those on 20 May; but if not then, then 10 June at the latest.  If this DT 
> could focus specifically on those requirements in time to make a proposal to 
> the Council by 12 May, that would be very helpful. We could then refine the 
> rest of the process for the 10 June meeting.

Wolf raised a concern about the ten hours per week workload description, and 
Chuck brought up with Marco the call's formulation of "between 15 and 20 days." 
 Assuming the latter will be tweaked and retained in the general call, perhaps 
we can just drop mention of the time commitment from ours? 

Otherwise, nobody has raised any other points on the way our additional 
requirements are framed.  Did anyone receive any feedback from their SGs or 
applicants about these that we should consider, or can we treat them as ready 
for prime time?


On Apr 26, 2010, at 3:12 PM, Gomes, Chuck wrote:

> Here is a first draft of the ICANN Call for Applicants.  Please provide me 
> any comments you have and I will forward them on.  I plan to submit some 
> comments later today that I will send to this list.
>  
> Note that the document emphasizes that the applicants being sought in this 
> requesat are supposed to be "in representation of a Supporting Organization 
> or Advisory Committee."  Also note that feedback on this announcement is 
> needed by mid-May. 

I guess they're really seeing this as a sort of corporatist interest 
representation model, and the call adds, "Candidatures to serve as independent 
experts will not be considered."   Personally I think this is too limiting and 
might move the process further away from the DT's January reply in the PCP that 
members  should be broadly neutral and focused on the collective good, and that 
SO/ACs should be able to suggest independent experts etc.   We can still 
nominate unaffiliated experts as potential GNSO reps, but one suspects they're 
generally not going to be viewed as coequal with SG reps.


On Apr 26, 2010, at 10:48 PM, Gomes, Chuck wrote:

> You are absolutely correct Wolf.  Our process changes considerably if we only 
> get one or two or even three seats.

Sorry to be dense, but I'm not getting the point Wolf and Chuck are making 
here.  The number of seats will be assigned to GNSO  could well vary across the 
RTs, e.g. 2-4, but how does that affect our standing process?  I would have 
thought we'd follow the same system regardless, e.g. we put forward up to five 
names (one per SGs + independent, in model 1) or more (in Tim's 2 or Chuck's 
SGs + multiple possible unaffiliateds) and then the selectors do their thing, 
it being understood not all SGs or unaffiliated nominees are necessarily going 
to be included in all RTs in a given cycle.  What's wrong with that, and if 
there is something, is the idea that we'd construct some more complex structure 
with different nomination procedures for each conceivable RT size?
> 
> From: owner-gnso-arr-dt@xxxxxxxxx [mailto:owner-gnso-arr-dt@xxxxxxxxx] On 
> Behalf Of Gomes, Chuck
> 
> I added more to the discussion below in just one place.
> 
>> 
>> [Gomes, Chuck] As of today (26 Apr), we know that Staff wants applications 
>> sent directly to them so the only process we need to firm up is how they 
>> will be handled after they are forwarded to us.  I would think that would be 
>> fairly simple but it probably should still be spelled out so that it is 
>> handled in a timely and orderly manner.  We probably should post the GNSO 
>> process on the GNSO website. 
Ok great, that's what I thought...I couldn't imagine they'd want each different 
submission procedures for each SO/AC.  And this presumably also means, per 
previous, that they envision posting to the web a consolidated list of all apps 
submitted, including those that were not endorsed.  So the selectors see them, 
nobody gets buried. However, "Only those applicants whose candidature has been 
endorsed by their selected SO/ACs will be retained for selection."  So that 
clears up another ambiguity we'd discussed.

Which then brings us back to the outstanding issues here:


On Apr 24, 2010, at 10:42 AM, William Drake wrote:

> *Whether SGs should be able to endorse more than one
> *If a) above applies, whether the SG selections are at least normatively 
> "binding" on the selectors, or rather all the names are on equal footing for 
> selection, in which case the selectors have broader discretion in picking our 
> reps
[the draft call answers this question]
> *Whether there should be a council-level process for endorsing an 
> unaffiliated, or leave this to SGs' discretion
[and Chuck's suggestion that if Council votes it, there could be multiple 
unaffiliated nominees alongside the SG ones]
> *Whether diversity should be pursued by the selectors at the RT level or by 
> the council at the GNSO level


Thanks,

Bill





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

Privacy Policy | Terms of Service | Cookies Policy