ICANN/GNSO GNSO Email List Archives

[council]


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

RE: [council] URGENT AOC RT Voting Clarifications


I prefer b as well but time permitting would be willing to go another
round if it appears that it might produce better results.

The RySG finished its work on this today: 1) We endorsed one candidate
for the RySG slot; 2) we endorsed one candidate for the unaffiliated
slot; 3) out of the remaining candidates, we identified the ones that
our Councilors could support in any votes for the fully open slot.  I
believe that our Councilors then will have all the information they need
to participate in the voting process. 

It is difficult to plan a process for this until we see the ET
recommendations so I think we will have to decide on that at the
beginning of the meeting. Of course, the ET is welcome to recommend a
process in addition to making recommendations regarding candidates for
the two open slots.

Chuck 

> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx 
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of William Drake
> Sent: Tuesday, March 09, 2010 7:45 AM
> To: GNSO Council List
> Subject: [council] URGENT AOC RT Voting Clarifications
> 
> 
> Hello,
> 
> I'm afraid there are two outstanding issues about the 
> election process, sigh...
> 
> I.  Pool Subject to Voting
> 
> Since a) the council will be having an open meeting tomorrow 
> in which we may need to explain details of the process, b) I 
> am told that some members of other SGs gathered here in 
> Nairobi have concerns about possible RT election scenarios, 
> and c) Tim has raised concerns about the process winnowing 
> the pool, I want to make sure everyone is on the same page on 
> a key point regarding the house election for the 5th and 6th 
> RT pool slots.  Wolf raised this with me the other day as well.
> 
> Based on discussions in the drafting team, some weeks ago 
> Chuck notified SG chairs that they could endorse up to two 
> candidates for the "open" (not the "unaffiliated") slot that 
> is subject to election by the House  (actually I think the 
> initial bracketed language he used was two "alternates").   
> Nobody ever objected so we let that stand as a limitation.   
> Alas, during the frenzied Council call when we adopted the 
> motion minutes after finding out the revised dates for the 
> process, we were focused on other issues and didn't manage to 
> discuss and draw it into the process document that was the 
> subject of the motion.  One could argue then that since the 
> Council didn't formally specify and approve this element, we 
> can interpret it however we want without doing any violence 
> to the agreed process.
> 
> I can see two ways to interpret what we agreed:
> 
> 1.  SG endorsements of up to two candidate for the open 
> elected slot simply signals SG support for two out of the 
> list of competitors.  So, for example (the precise number is 
> pending agreement within the ET) it appears that there may be 
> five candidates that are affiliated with the CSG.  The CSG 
> endorses (i.e. says "we favor") two, which the houses may 
> wish to take into account in voting, but the other three 
> remain in the pool that will be voted on.  
> 
> 2.  Instead,  SG endorsements of up to two candidate for the 
> open elected slot means that they select only those two to 
> stand for election, and the others fall out and are not on 
> the ballot.  
> 
> By my personal not-ratified-by-the-ET count, the twelve 
> candidates should be classified as follows:
> 
> 1 person who will be held out of the pool as his first choice 
> is to be considered for the Security and Stability RT
> 1 RgySG person
> 1 RgrSG person
> 5 CSG persons
> 2 NCSG persons
> 2 independent/unaffiliated persons
> 
> Without prejudging the decisions they will make, I would 
> guess that the RgySG and RgrSG would choose the people 
> affiliated with them for the allocated slots, which are not 
> subject to the election.  NCSG has selected a person for its 
> allocated slot.  This would mean then that the potential 
> competition for the open elected slot is between 4 of the 5 
> CSG people (assuming they choose one for the allocated slot) 
> and one NCSG person.  (Of course the RgySG and RgrSG could 
> opt not to put the two into the allocated slots, in which 
> case you'd have to add one or two to the pool being voted on).
> 
> So: for that election, would the Council like to 
> 
> 1.  Have all five people competing, with CSG's endorsement of 
> up to two meaning only that they prefer them, or 2.  
> Interpret the endorsement as meaning that only those two can 
> stand for election, in which case the pool for the vote would 
> be 2 CSG + 1 NCSG?
> 
> My preference would be that it be open, option 1.  Per Tim, 
> this also gives everyone a chance at being elected.  
> Moreover, I would add that if we don't view SG endorsements 
> of x as taking y out of the pool, there's another option, 
> namely that CSG could choose not to endorse any of them, so 
> that it doesn't have to make uncomfortable choices among 
> colleagues and all get to stand.
> 
> 
> II.  Voting Process
> 
> I raised this before with the DT and ET, didn't get a clear 
> answer, and there was no further pre-travel discussion.  If 
> on the voting call no candidates get majorities of both 
> houses, we can either a) stop there and say nobody wins that 
> slot; b) do a second vote, in which hopefully enough people 
> would shift their positions to put someone over the top, and 
> if the 2nd doesn't work either, just agree nobody wins; or c) 
> keep doing voting rounds until someone wins.
> 
> Obviously, a) is the easiest, but b) or c) would be fairer to 
> the candidates.  I'd personally prefer b).
> 
> The same would presumably apply to the vote for the unaffiliated slot.
> 
> 
> It would be really great to clarify these two items before 
> the open meeting.  Can we do this by consensus or do we need 
> to have a quick motion?  Responses would be very much appreciated.
> 
> Sorry...i can assure you nobody is more tired of this than I.
> 
> Bill
> 
> 
> 
> 
> 
> 




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