ICANN/GNSO GNSO Email List Archives

[council]


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

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.
>
>
>
>






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