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

Alan Greenberg alan.greenberg at mcgill.ca
Sun Mar 29 21:12:21 UTC 2009


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 at gnso.icann.org
> > [mailto:owner-council at gnso.icann.org] On Behalf Of Stéphane Van Gelder
> > Sent: Sunday, March 29, 2009 3:20 PM
> > To: Tim Ruiz; council at gnso.icann.org
> > 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 at godaddy.com> 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 at psg.com>
> > > Date: Fri, March 27, 2009 3:16 pm
> > > To: "council at gnso.icann.org" <council at gnso.icann.org>
> > >
> > >
> > > 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.
> >
> >
> >
> >






More information about the council mailing list