RE: [council] Draft Revisions to the ICANN Bylaws Relating to GNSO Restructure

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

I don't understand Alan.  X.5.1 contains language for the revised Bylaws and I 
don't think Bylaws should be approached in a way that defers action to a later 
time and then requires changes to the Bylaws then.  If the intent is to do 
that, then put that language in the Rules and require Board approval of the 
Rules in the Bylaws.  That way, the Bylaws do not have to be changed 
frequently, a process that we all know is long and cumbersome.

Chuck 

> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx 
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Alan Greenberg
> Sent: Sunday, March 29, 2009 5:12 PM
> To: council@xxxxxxxxxxxxxx
> Subject: RE: [council] Draft Revisions to the ICANN Bylaws 
> Relating to GNSO Restructure
> 
> 
> The way I read X.5.1, they were not setting up an ongoing 
> process, but simply deferring the need to address the really 
> difficult question of 
> Constituencies>Seats that the BGC Stakeholder Group model imposed.
> 
> It follows the old adage "Never do today what you can put off 
> 'til tomorrow".  Often a practical way of approaching things 
> in life, but somewhat unusual in Bylaws, I would think.
> 
> In this case, I think that if the Board wants to impose such 
> a rule in the initial implementations, they should do it by 
> means of their control over acceptance of SG charters.
> 
> Alan
> 
> At 29/03/2009 04:55 PM, Gomes, Chuck wrote:
> 
> >Stephane,
> >
> >The last sentence of X.5.1 says, "When the number of 
> Board-recognized 
> >Constituencies reaches three in any Stakeholder Group with three 
> >Council seats or six in any Stakeholder Group with six 
> Council Seats, 
> >the Board will consider any structural or procedural changes 
> that may 
> >be appropriate to ensure that the GNSO Council may continue to 
> >accommodate additional Constituencies consistent with the principles 
> >and provisions of these Bylaws." Unless I am missing something here, 
> >which is certainly possible, this sets of an ongoing need for Board 
> >review everytime the number of constituencies impacts the 
> assignment of 
> >Council seats.  That doesn't scale very well in my mind.  
> Why not just 
> >delete the sentence and allow SG charters to cover this, recognizing 
> >that the charters require Board approval?
> >
> >Chuck
> >
> > > -----Original Message-----
> > > From: owner-council@xxxxxxxxxxxxxx
> > > [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Stéphane Van 
> > > Gelder
> > > Sent: Sunday, March 29, 2009 3:20 PM
> > > To: Tim Ruiz; council@xxxxxxxxxxxxxx
> > > Subject: Re: [council] Draft Revisions to the ICANN 
> Bylaws Relating 
> > > to GNSO Restructure
> > >
> > >
> > > The text about one seat per constituency minimum in X.3.1 also 
> > > raised questions mark with me on first reading, but upon closer 
> > > inspection I thought the last paragraph of X.5.1 covered it.
> > >
> > > But as it seems others have a concern with X.3.1, I would 
> agree that 
> > > deleting the language in question would be a good solution.
> > >
> > > Stéphane
> > >
> > >
> > > Le 28/03/09 12:43, « Tim Ruiz » <tim@xxxxxxxxxxx> a écrit :
> > >
> > > > Thought we should start trying to capture suggested 
> changes in the 
> > > > document. The attached is a red line with the following 
> suggested
> > > > changes:
> > > >
> > > > X.3.1
> > > >
> > > > Deleted the restrictive language about all Constituencies being 
> > > > allocated a Council seat.
> > > >
> > > > X.3.3
> > > >
> > > > Modified with a compromise to address Avri's concern. Just a 
> > > > suggestion, not necessarily supported by the RrC yet.
> > > >
> > > > X.3.6
> > > >
> > > > Deleted the unnecessary and restrictive language regarding
> > > Board seat
> > > > selections.
> > > >
> > > > X.3.8
> > > >
> > > > No changes, but something we need to discuss further. 
> There may be 
> > > > advantages to allowing the Nominating Committee to make this 
> > > > assignment based on criteria provided by the Council as a
> > > whole (for
> > > > the Council level NCA) and by criteria provided by each of
> > > the houses
> > > > for their NCA (but final criteria approved by the Council
> > > as a whole).
> > > > That said, that is just a personal observation for
> > > consideration, not an RrC position.
> > > >
> > > > X.5.1
> > > >
> > > > Modified to be consistent with reality, and the changes
> > > made to X.3.1.
> > > >
> > > > XX.5.4
> > > >
> > > > Modifed the timeline for the new Council to be as soon as 
> > > > practical after Sydney, but no later than the 
> commencement of the 
> > > > meeting in October. Again, just a suggestion but this 
> seems to be 
> > > > more
> > > realistic.
> > > >
> > > > XX.5.5
> > > >
> > > > Modified to be consistent with the changes in X.3.1 and X.5.1.
> > > >
> > > > XX.5.11
> > > >
> > > > Modified to be consistent with the changes to XX.5.4. 
> The voting 
> > > > thresholds will be in place when the new Council is seated,
> > > whenever
> > > > that may be.
> > > >
> > > > XX.5.12
> > > >
> > > > Modified to be consistent with the changes to XX.5.4.
> > > >
> > > >
> > > > Tim
> > > >
> > > > -------- Original Message --------
> > > > Subject: Re: [council] Draft Revisions to the ICANN Bylaws
> > > Relating to
> > > > GNSO Restructure
> > > > From: Avri Doria <avri@xxxxxxx>
> > > > Date: Fri, March 27, 2009 3:16 pm
> > > > To: "council@xxxxxxxxxxxxxx" <council@xxxxxxxxxxxxxx>
> > > >
> > > >
> > > > hi,
> > > >
> > > > A few question/comments on first reading.
> > > >
> > > > -- X3.1
> > > >
> > > >> Each Stakeholder Group may select representatives according to 
> > > >> its Charter procedures subject to the provision that each 
> > > >> Board-recognized Constituency shall be allocated a 
> minimum of one 
> > > >> seat on the GNSO Council.
> > > >
> > > > I question whether this is indeed in keeping with the intent of 
> > > > the Board mandated changes as I thought they intended to break
> > > the direct
> > > > connection between constituencies and council seats.
> > > >
> > > >
> > > > X3.3
> > > >
> > > > I think that this would possibly stifle an outside voice in
> > > one of the
> > > > houses. I think that condition C should apply no matter
> > > what house a
> > > > NCA happens to be in. If the aggrieved house cannot make
> > > its case to
> > > > the entire council then perhaps its grievance is not as
> > > 'for cause' as
> > > > they believe.
> > > >
> > > > X3.6
> > > >
> > > > I thought that this was still an open issue waiting board
> > > consideration.
> > > > As I described in the original report, I still believe that
> > > this will
> > > > lessen the legitimacy of the board member vis a vis the
> > > other members,
> > > > as this person would not have been elected by an SO but
> > > only by part
> > > > of an SO.
> > > >
> > > >>
> > > >
> > > > x3.8
> > > >
> > > >
> > > >> and one voting member appointed by the ICANN 
> Nominating Committee
> > > >
> > > > this read as if the Nomcom is going to determine which NCA
> > > sits where.
> > > > I would recommend removing removing the line from each of the 
> > > > paragraphs and inserting:
> > > >
> > > > c. One of the council members appointed by the ICANN Nominating 
> > > > Committee will be serve as a voting member of each house
> > > >
> > > >
> > > > the way this is done would then be put in the Operating rules
> > > >
> > > >
> > > >
> > > > x4.1
> > > >
> > > > As mentioned above I think the last paragraph is not in
> > > keeping with
> > > > the Board's intent to separate seating on the council from 
> > > > constituency existence. If we do this, I believe we have
> > > negated one
> > > > of the main advantages to be gained from the separation of 
> > > > constituency from stakeholder group.
> > > >
> > > >
> > > > thanks
> > > >
> > > > a.
> > >
> > >
> > >
> > >
> 
> 
> 
>