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