<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [council] Resolutions on reform 2 - amended after NC discussion
> The Council is of course free to state its views on anything, but I would
> think it ought not do so in ways that are obviously based on logical flaws.
With all due respect, the view is a little different from inside the DNSO and
outside the Board.
> The proposed resolution says that the ERC position is unacceptable because
> it gives the contracting parties a veto over the development of consensus
> policy.
Yes.
> This of course depends on the following logic chain:
No, it doesn't. It has to do with guarding against potentialities.
why did the House of Lords vote to eliminate its substantive power in 1911? one
of the reasons was that the sovereign ultimately had a trump card, going back to
Queen Anne: the ability to stuf the House with life peers. The potential of
nuke is itself a powerful force, whether you ultimately use it or not.
Thus, the mere _potential_ that the "contracting parties" will outweigh users
creates an impbalance within the Council that inevitably warps the process.
Furthermore, as representatives of our consticuencies, it is out role to prevent
against the potential for problems.
In short, it does not require us to beleive that the propoesed restructuring
creates a powerful hostile voting block in perpetuity. It is enough to know tht
it creates a voting block capable of imposing its will and capable of using its
veto threat to extort concessions.
> the
> registries and registrars constituencies will always vote together;
Again, "always" is not required. when you negotiate a contract, do you depend
upon the god will that exists at the time of the deal or worry about what will
happen when the parties become disenchanted with one another? we hope for the
best but plan for the worst. Public policy is no different, except that the
stakes are higher and the number of "parties" includes those not yet in
existence. fun, huh?
>they
> will be disincented to try to create consensus because they see no need to;
A more concrete fear is that they will be able to extort conessions because of
their ability to vote as a block, or that the perception that they can use such
a tactic will negatively effect the debate. As al Capone said "you get more
with a kind word anda gun than with a kind word."
> and if they refuse to come to agreement with the users constituencies, this
> will eliminate the possibility of the development of a consensus policy.
> Following this same logical chain, the current situation gives the
> remaining constituencies, all of which are directly or indirectly user
> constituencies, a veto over the development of consensus policy, assuming:
> the user constituencies will always vote together, they will be disincented
> to try to create consensus because they see no need to, and if they refuse
> to come to consensus with the contracting constituencies, this will
> eliminate the possibility of the development of a consensus policy. Or
> worse from some perspectives, they will outvote the contracting
> constituencies 4-2, and then assert that this represents a consensus. Oh,
> but they might say in response to this last point, the NomCom reps will be
> a litmus test; only if they go along with the 4-2 can it reasonably be
> called a consensus position. But putting aside the fact that these same
> constituencies have objected to the very concept of NomCom representatives
> on the NC, this same argument works on the other side too -- if the vote is
> 4+3 NomCom vs the 2 contracting constituencies, it seems to me that it
> would be fully within the range of possibilities, depending on the reasons
> for objection advanced by the contracting parties, that the Board could
> find that the recommended policy is supported by a consensus within the
> community. Consensus does not require unanimity.
>
> So let me be clear on how this debate looks to those outside the current NC
> environment: each side jockeying for relative position, with neither side
> really trying to find ways to improve the chances for the development of
> consensus policy. This is exactly what drove the Board (through the ERC,
> although this approach came originally from the Board itself) to call for
> the use of NomCom representatives on the NC, in an effort to improve those
> chances. Indeed, there were strong voices on the Board for a larger number
> of NomCom reps, with some believing that it might be appropriate to have an
> equal or greater number of NomCom reps to constituency reps, but the ERC
> was ultimately persuaded that was not necessary. But the ERC was also
> persuaded that (1) some NomCom reps was a good idea, and (2) that the most
> likely structure to create maximum incentives for both sides to come to a
> consensus position was to make sure that neither side thought it could
> control the outcome. Now we get reps from the current majority side saying
> they like the status quo just fine, thank you; this is hardly surprising,
> but at least from the ERC's perspective, they have already concluded that
> the status quo is not fine, and they are, IMHO, highly unlikely to
> recommend it.
>
Joe, this is a messy process. the fewer the decision makers, the more efficient,
but the less buy in.
Since its inception, you and th rest of th ICANN staff/Board have attempted to
rade efficiency for buy in. this has been, in my opinion, a mistake. It has
generated suspcion outside the circle of decisionmakers and hinder the
maturation of ICANN processes. I would urge ome tolerance for the messiness of
politics as a trade off for greater buy in.
> Therefore, if there are legitimate concerns with the current state of the
> ERC recommendations, I would suggest that those who are unhappy with them
> spend some energy on suggesting substitutes that will at least arguably
> deal with the issue that the ERC (and quite frankly almost everyone that
> talks to them OTHER than the current NC member constituencies) sees with
> the status quo. Simply saying "I like the status quo," which is clearly
> the most common refrain the ERC hears from many different quarters in the
> community that for one reason or another resist change, is not likely to be
> very persuasive.
You overlook two things. 1) the ability of the Council to give detailed advice
is limited because the council is a consensus building body. It speaks with
broad messages on general matters of policy because the more narrow and detailed
the message, the harder to get conensus. this is inevitable and criticizing the
DNSO for this is not helpful.
If this system is to work, then we accept the fact the the NC provides broad
guidelines and approves the work of the NC's bodes (e.g. task forces an working
groups). the indivdual consticuencies then provide input and the ERc (and
Board) end up synthasizing the mess, implemented by staff and representatives
from the stakeholder communities (e.g. DNSO task forces).
Heinlein once remarked that more than three people can't agree on where to have
lunch, let alone on policy. the value contributed is therefore broader
consensus guidelines.
Let me put it another way, if a proposed course of action gives a substantial
percentage of the stakeholders represented here heartburn, the ERc and the Board
should take that as valuable input that the proposal is bad instead of carping
that the DNSO can't stomach it.
>And just to deal preemptively with the inevitable
> "top-down" arguments, the members of the ICANN Board have a fiduciary
> responsibility to use their best judgment to reach decisions that advance
> the interests of the organization -- the whole organization.
True, but the organization's mission is to "lighten the burden of government" by
seving the Internet community and performing specific quasi-governmental
functions. hus, the Board fulfills its fiduciary duty by ensuring that the
corporation fulfills its mission.
All
> recommendations from various parts of the organization do not inevitably
> pass this test, and thus could not, consistent with that fiduciary
> obligation, be accepted by any responsible ICANN Board member. The
> solution to this problem is to propose solutions that could fall within
> that standard; my sense is that the ERC, at least, does not find the status
> quo on the NC to fit that criteria.
>
and the NC, as the representative of the the community the corporation titularly
serves, infrm the ERc that its considered judgment is wrong.
> Joe Sims
Harold
> Jones Day Reavis & Pogue
> 51 Louisiana Avenue NW
> Washington, D.C. 20001
> Direct Phone: 1.202.879.3863
> Direct Fax: 1.202.626.1747
> Mobile Phone: 1.703.629.3963
>
>
>
> "Philip
> Sheppard" To: "NC \(list\)"
<council@dnso.org>
> <philip.sheppard cc:
> @aim.be> Subject: [council] Resolutions on
reform 2 -
amended after NC
> discussion
> Sent by:
> owner-council@dn
> so.org
>
>
> 09/27/02 06:16
> AM
>
>
>
>
>
>
> Proposed NC resolution (2) amended (some whereas clauses deleted)
> 1. Whereas the ICANN Evolution and Reform Committee (ERC) has published its
> second implementation report
>
http://www.icann.org/committees/evol-reform/second-implementation-report-02sep02.htm
>
> 2. Whereas the basis for stakeholder representation in ICANN SOs to date
> has been to give equal votes to each affected stakeholder constituency;
> 3. Whereas the report suggests a significant change in the voting balance
> of ICANN stakeholders to be represented in the new Generic Name Supporting
> Organisation (GNSO) council whereby it gives twice as many votes to the two
> stakeholders who have contracts with ICANN (gTLD registries and
> registrars);
> 4. Whereas the 4+4+3 proposed voting structure gives a veto to the
> contracted suppliers over all ICANN consensus policies, thus negating the
> balancing role of the three neutral council members,
>
> The NC therefore resolves that:
> any variation from the principle of equal stakeholder constituency
> representation and votes in the proposed GNSO council is unacceptable.
>
>
>
>
>
>
>
> ==========
> The preceding e-mail message (including any attachments) contains
> information that may be confidential, be protected by the attorney-client
> or other applicable privileges, or constitute non-public information. It
> is intended to be conveyed only to the designated recipient(s). If you are
> not an intended recipient of this message, please notify the sender by
> replying to this message and then delete it from your system. Use,
> dissemination, distribution, or reproduction of this message by unintended
> recipients is not authorized and may be unlawful.
> ==========
>
>
>
>
---------------------------------------------
This message was sent from webmail.his.com.
http://www.his.com/
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|