Re: [ga] on using appropriate tools

["James Love" <james.love@cptech.org>]

Thomas, while you work on a proposal a new method of recording the views
of the Internet community of issues concerning ICANN, there is a rapid
process for reshaping ICANN into an unaccountable and undemocratic
institution with a very broad policy mandate.   It seems to me that *now*
is the time to use whatever tools are left to oppose the worst features of
that.  It seems to me that refusing to use those tools now is a strategic
effort to protect the ICANN board from effective criticism during the
period when they will attempt to persuade the world they have consensus
for thatwever is done in Bucharest.   What you propose below is to stop
the GA from having an effective voice in the current reform debate, which
is taking place right now.
     Jamie

PS... the deep seated hostility to the use of voting by the public, even
in cases where the votes have no binding legal significance, for anything
important in the reform process, is of course consistent with the "reform"
process proposals....


> Thinking a bit more about some of the recent discussions here, I
> arrive at the conclusion that a considerable part of the problems we
> are experiencing is caused by the use of an inappropriate tool:
> Votes like we are using them right now are _not_ the tool we
> _should_ be using in order to make declarations of the intent of the
> members of the GA.
>
>
> More precisely, a vote is an instrument by which some well-defined
> body comes up with a collective decision.  The accountability for   the
> outcome of the vote is collective; individual members are not   held
> accountable for their individual votes.  For this reason, votes  are
> held in secret. In particular, a vote deliberately withholds a
> considerable amount of information from the public.
>
> It is also bad to arbitrarily add new members to the voting registry
> for a particular vote: Suddenly, the body making the decision is no
> longer well-defined; the result of the vote ("body x says y") itself
> becomes ill-defined as a consequence.
>
> Such votes are an appropriate tool when the GA actually acts as a
> homogeneous body, that is, when it elects a chairman or
> representatives to task forces, or when it votes on its internal
> procedures: Votes are appropriate whenever the question at hand is  how
> the GA as a group of individuals can best organize its
> activities.
>
>
> Votes are, however, not appropriate when GA statements are made on
> substance.  There are several reasons for this.
>
> Most importantly, the GA is _not_ acting as a homogeneous body when
> it comes to substantial topics: We are a mix of constituency members
> and interested individuals, of stakeholders and slashdotters.  We   may
> even want to take into account outside support for substantial
> statements (Jamie tried this; similarly, it may be interesting to
> shop for support for a uniform deletions policy or certain transfer
> policies at nsihorrorstories.com).  What the resolutions discussed
> here are about is not a _decision_ within a homogeneous body, but a
> demonstration of support (and, possibly, objection!) from those who
> want to demonstrate that support (or objection).
>
> For such a demonstration, the deliberate loss of information which   is
> connected with the current voting mechanism is not desirable: An
> explicit list of supporters of a resolution makes a lot more sense
> than the apples-and-oranges statement that "the DNSO's GA has voted
> for xyz".  In fact, I'd even go a step further than just making the
> voting process transparent: Let's get rid of the voting registry and
> the complex apparatus we are using altogether, as far as substantive
> resolutions are concerned (as opposed to questions of the internal
> organization of the GA).
>
>
> So, here's my suggestion for how to deal with future resolutions:   Set
> up separate web archives where support and objection are
> collected.  The easiest way to do this is to have two separate mail
> addresses, like <resolution-[veryshorttitle]-support@dnso.org> and
> <resolution-[veryshorttitle]-object@dnso.org>.  Connect each of
> these addresses to a web archive.  Distribute a message like the
> following one widely (very rough draft), including to the members of
> the voting registry:
>
>
> 	If you support the above resolution, please send an e-mail
> 	message to <...-support@dnso.org>; if you object, please
> 	send an e-mail message to <...-object@dnso.org>.  If you
> 	want to explicitly record your abstention, send a message to
> 	<...-abstain@dnso.org>.
>
> 	In your message, please indicate your name, and possible
> 	membership in a DNSO constituency.  Please use the following
> 	template:
>
> 	Name:
> 	Membership: {ga/ga-voting-registry/constituency/external}
>
> Define a deadline for the submission of these messages, and produce
> the final report when that deadline is over: Namely, the
> resolution's text, and the lists of supporters and objectors,
> including their kind of DNSO membership.
>
> To summarize, the process suggested has the following benefits over
> the current approach:
>
> - The resulting statement is well-defined.
> - The process is transparent and can be implemented with
>   considerably less effort than the voting process; in particular,  the
>   safeguards necessary to ensure the integrity of a secret vote are not
>   needed here.
> - The very concept of capture does not make any sense, since it is
>   reasonably transparent who does and says what.  In particular,  there
>   is no voting registry to be stuffed.
>
> Of course, one may argue that this approach is relying on the
> integrity of the Internet e-mail system too heavily; indeed, faking   a
> statement of support is as easy as faking an e-mail message.
>
> If this is a concern, the software used would have to be somewhat
> more complex: The software would have to send a message to the
> e-mail address given which contains the resolution's text and asks
> for confirmation.  The simplest approach to implement this is like
> this: For each incoming message at one of the -support, -object, or
> -abstain addresses, create a random unique secret string [from a
> well-defined and safe to handle set of characters].  Use that as the
> file name under which you temporarily store the message.  Demand   that
> confirmations be sent to ...-{support,object,abstain}-<magic>.  Have a
> mail bot listening at that address strip the magic out of   the
> address, and move the saved message into the archive.  After the  end
> of the vote, move unconfirmed messages into separate archives.
>
> Shouldn't be hard to do.
>
> (If you're unsure about the process I'm describing - it's the same
> thing which is commonly done to confirm mailing list subscriptions
> nowadays.)
>
>
> Comments?
> --
> Thomas Roessler                          http://log.does-not-exist.org/
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html


-- 
James Love
http://www.cptech.org mailto:james.love@cptech.org
mobile +1.202.361.3040


--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html