<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-consensus-wg] Voting Thresholds Update
- To: "Nevett, Jonathon" <jnevett@xxxxxxxxxxxxxxxxxxxx>, <gnso-consensus-wg@xxxxxxxxx>
- Subject: RE: [gnso-consensus-wg] Voting Thresholds Update
- From: "Metalitz, Steven" <met@xxxxxxx>
- Date: Mon, 7 Jul 2008 06:35:21 -0700
Thanks Jon, I stand corrected on that point.
Steve
________________________________
From: Nevett, Jonathon [mailto:jnevett@xxxxxxxxxxxxxxxxxxxx]
Sent: Saturday, July 05, 2008 5:46 PM
To: Metalitz, Steven; gnso-consensus-wg@xxxxxxxxx
Subject: RE: [gnso-consensus-wg] Voting Thresholds Update
Steve:
Just so there is no confusion, under Section 13(f) of Annex A of the
ICANN Bylaws, all it takes is a simple majority vote (not 2/3rds vote)
of the ICANN Board to approve a Consensus Policy offered by a simple
majority vote of the GNSO. Whether this has happened in the past or not
(I have no idea) should be irrelevant. If the voting structure is
changed to something like what you have been advocating for, it most
assuredly would occur in the future.
Thanks.
Jon
________________________________
From: Metalitz, Steven [mailto:met@xxxxxxx]
Sent: Saturday, July 05, 2008 4:35 PM
To: Nevett, Jonathon; gnso-consensus-wg@xxxxxxxxx
Subject: RE: [gnso-consensus-wg] Voting Thresholds Update
Thanks for the chart Jon, this is very helpful.
I believe you are correct that it is possible for a consensus policy to
be adopted by a simple majority vote of the Council if it is then
approved by a supermajority (2/3+) of the Board. Could the staff look
into whether this scenario has ever occurred and if so on what issue(s)?
The much more common scenario would seem to be the supermajority
approval of a policy by GNSO, followed by Board ratification unless 2/3
of the Board rejects it. Indeed, even on the issue we are engaged in
discussing, although it did not arrive before the Board in the form of
actual votes taken at the Council level, the Board clearly perceived
that there was no supermajority in support of either of the proposals
before it (BGC or Joint Users Group) and deferred action in the hope of
achieving a consensus (again, not in the sense of a formal Council
vote).
Indeed, the argument we heard against the Joint Users Group proposal in
Paris and before was that it would enable the "users" to command a
supermajority vote against the "suppliers," and thus force the latter to
comply contractually with consensus policies that they opposed, unless
the suppliers could convince a supermajority of the Board to reject
them. Of course, that objection can be satisfied in many ways that do
not require an equalization of votes between "suppliers" and "users."
More broadly, what is the justification for any special consideration
for "suppliers" on any issue other than development of consensus
policies to which "suppliers" may become contractually bound over their
objection? Whether or not "parity" were maintained on approval of
consensus policies, should we be looking at a different vote allocation
altogether for all other categories of GNSO Council activity? Put
another way, if a vote is on something for which a registrar or registry
would not become contractually bound, why should a group of registrars
or registries cast as many votes as all ""users" put together, or
indeed, why should they cast any votes at all as a separate group?
Steve
________________________________
From: owner-gnso-consensus-wg@xxxxxxxxx
[mailto:owner-gnso-consensus-wg@xxxxxxxxx] On Behalf Of Nevett, Jonathon
Sent: Saturday, July 05, 2008 11:01 AM
To: gnso-consensus-wg@xxxxxxxxx
Subject: RE: [gnso-consensus-wg] Voting Thresholds Update
Corrected a typo in the attached (8 Board members constitutes a
majority). Thanks. Jon
Per our discussion yesterday and Steve Metalitz's request, attached is a
chart that I have prepared with the various GNSO voting thresholds.
Please note that I believe it to be accurate, but it would be great if
Robert would review to make sure that I didn't leave anything out.
As I review the chart, I see the large number and great importance of
issues that are decided by a majority vote, including 1) appointing a
Task Force; 2) approving PDP policy recommendations through majority
adoption of a Final Report or Supplemental Recommendation (which the
Board could adopt as binding Consensus Policy with a majority vote (i.e.
a vote of 8 Board members)); 3) electing a GNSO Chair; 4) electing Board
Seats 13 and 14; and 5) all other procedural and substantive business of
the GNSO that is not otherwise delineated in the Bylaws.
This is the reason why I support the BGC recommendation of continuing
the current parity between contracted and non-contracted parties. Under
the current structure and the BGC proposal, neither "side" enjoys over
the other a majority or an advantage in getting a majority. Therefore,
neither can dictate the operations of the GNSO. It requires that we all
work together and we have the benefit of Nom Com reps to perform the
tie-breaker function if necessary. Parity seems to be the most
equitable and balanced solution.
In an attempt to reach a resolution, therefore, I'd like to focus as
much of our discussions as possible on issues that don't impact this
balance. A wholesale increase in the voting thresholds on all of these
important issues is not the answer, as it would likely result in more
gridlock. What other changes could we make that would address the
concerns that certain users have raised without giving one "side" a
majority over the other? Philip mentioned in his paper taking a look at
the allocation of Board seats. We should continue to discuss the merits
of this idea. Under the BGC proposal, the balance between commercial
users and non-commercial users would change from the current 9-3-1 (1
being the non-voting ALAC rep) to 4-4. We probably should spend some
time understanding that balance as well. What else?
We are a creative group with a very short time frame to succeed. I hope
that we can get some other interesting ideas in the mix and look forward
to our upcoming discussions.
Best,
Jon
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|