Re: Document Plan
To me, the issue is NOT whether the device stores
ballots. To me, the issue is whether the
printout that comes from the device *is* the
official ballot. It's certainly possible for the
device to keep an audit trail, as do some systems
of this category.
I would suggest calling this system an
Computerized Ballot Printer (CBP) or an
Computerized Ballot Marker (CBM) depending on
whether the device prints the ballot from blank
ballot stock (CBP) or marks a fill-in-the-bubble
or connect-the-lines (or other similar)
pre-printed ballot form (CBM).
One technique for activating such a system is to
use the same pre-printed ballot form that can be
marked by hand. Other techniques for activating
such a system include:
any technique that can activate a DRE, and
a pre-printed ballot stock *not* suitable for
hand marking, but that identifies the type of
ballot (e.g., precinct and party).
-----------
The ballot scanner for an CBM will be a standard optical mark scanner.
The ballot scanner for an CBP is a separate class
of machine. I believe there needs to be a
description of the scanner for an DRE with
AVVPAT, where the audit trail can be machine
tallied. I think that there should be a lot of
commonality in the requirements for the CBP
ballot scanner/tally machine and the DRE/AVVPAT
audit trail scanner/tally machine.
------------
There should also be accuracy standards and
functional requirements for the AVVPAT-A for the
DRE with AVVPAT.
-------------
Finally, I recommend to the vendors a different
implementation for the AVVPAT's printer than a
roll of paper and a slicer or a roll of paper and
a take up reel. I recommend using the kind of
printers used for airline tickets and their
corresponding card stock. It should be easier to
machine scan and tally such an audit trail, and
it can avoid the ordering problem. If so, the
system needs to be able to support multiple cards
for an AVVPAT and a technique for spoiling *all*
the cards of a batch if the last one printed is
wrong. That's why more detail about the
requirements of what's printed by an AVVPAT are
needed and how these can be scanned and tallied
if such functionality is supported.
Best regards,
Arthur
P.S. I changed from Electronic Vote Printer to
Computerized Vote Printer because of Kolwicz's
comments.
At 10:33 PM -0500 10/21/04, Deutsch, Herb wrote:
>My take on the current situation.
>
>There is one major thing that has emerged and
>thrown a monkey wrench into our standard since
>it isn't covered. It is the existence and the
>active marketing of a new configuration of
>voting unit. This type of unit does all that
>the traditional DRE unit does except to store
>and tabulate ballots; certainly a significant
>distinction. Its output is a paper ballot that
>requires a separate traditional optical scan
>unit to read and tabulate the ballot content.
>One example of this type of unit is the AutoMark
>which can be a companion to the Diebold
>AccuVote, the ES&S M100, the ES&S/Sequoia Eagle
>and an optical scan version of a punch card
>ballot tabulator. It contains its own election
>definition that must match the election
>definition in the ballot scanner. It is
>activated by inserting the same optical scan
>ballot that can be directly voted by hand and
>determines the ballot style to be used by
>reading the ballot identification code from the
>ballot. This configuration is not covered by
>either the FEC 2002 standard or ours.
>
>I propose that:
>· We define a new acronym and unit
>designation for this configuration and not
>attempt to redefine the "DRE" since it has an
>existing connotation that has existed for a long
>time. My suggestion is Electronic Vote Recorder
>(EVR). This (or whatever designation we agree
>upon) should be added to the definitions.
>
>· We should develop our characteristics
>matrix and create a table of applicable
>requirements sections from the draft that we can
>either put in the beginning of Section 6.0 as a
>testing guide or make it an annex and reference
>it.
>
>We modify the requirements designations to distinguish between DRE & EVR
>We purge any design language from the
>requirements. At least one was brought up in an
>e-mail from John Homewood re: 5.1.3.2.5 a). that
>created an e-mail chain and, I believe, an
>agreed upon resolution.
>Follow through on all comment resolutions to
>ensure that resolutions that are documented are
>included and that comments have been resolved.
--
-------------------------------------------------------------------------------
Arthur M. Keller, Visiting Associate Professor, Computer Science Dept.
University of California, Baskin School of Engineering, Room 153B,
1156 High Street, Santa Cruz, CA 95066-1077
tel +1(831)459-1485, fax +1(831)459-4829, www.soe.ucsc.edu/~ark