| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Stephen, Our reaction to Annex I and VVPAT: 1. On the last
MIT / Caltech voting project conference October 1 and 2, 2004 Adam
Stubblefield, the speaker of the Hopkins University, recognized that software
can be checked 100% if there are not too many lines. 2. In the Ted Selker and J. Goler paper
“The SAVE system - Secure architecture for voting electronically”
BT Technology Journal Vol 22 No 4 October 2004 we
noticed the same trend. 3. In We can conclude that VVPAT or comparable measures are not
necessary if one can have the system completely tested (firmware and hardware
alike). In fact this has been a comment made during the last IEEE meeting
(visited by As we are following this direction we think it is totally
wrong to make a VVPAT normative as the VVPAT is a superfluously addition to a
system which is a simple voting registration structure. This distinctive difference is not yet reflected in the IEEE
recommendations. To avoid misunderstandings we strongly suggest splitting the
DRE groups into 2 categories as suggested earlier (NEDAP comments on Concept 5)
If this split is not possible anymore we kindly request to
get the opportunity to add an annex where this observation is explained N.V.
Nederlandsche Apparatenfabriek "Nedap" + 31 (0) 544 471 162 (Phone); + 31 (0) 544
463 475 (Fax) + 31 (0) 6 53718821 ( Parallelweg 2, NL-7141 DC Groenlo or P.O. Box 6, NL-7140 AA Groenlo, The -----Original Message----- Jacques, I believe I understand the intent of your comment but this is not best accomplished by the use of NORMATIVE and INFORMATIVE. I think to accomplish your purpose either a scope statement should be prominently added, e.g.
The requirements of this section apply only to .... An alternative is the appropriate use of shall/should/may to identify mandatory requirements,
from different levels of suggested or advisory material. Even mandatory requirements can be appropriately scoped, e.g. DREs that utilize a
touch screen shall ... Best Regards, Stephen Berger TEM Consulting, LP Web Site - www.temconsulting.com E-MAIL - stephen.berger@ieee.org Phone - (512) 864-3365 FAX - (512) 869-8709 -----Original Message----- From: owner-stds-1583-stg3@listserv.ieee.org [mailto:owner-stds-1583-stg3@listserv.ieee.org] On Behalf Of Jacques
Hulshof Sent: To: Arthur Keller; Jim Adler Cc: David Aragon (E-mail 2); stds-1583-stg3@IEEE.ORG; Sanford
Morganstein; David Patterson; Robert Oliver Subject: RE: AVVPAT-ABP revised draft Dear All, One of NEDAP's comments was: Change Annex I to Informative and not Normative. Normative indicates that if a vendor wants to get an
approval of a DRE he shall include a AVVPAT. This is then compulsory. This i9s not what we want. Jacques Hulshof N.V. Nederlandsche Apparatenfabriek "Nedap" + 31 (0) 544 471 162 (Phone); + 31 (0) 544 463 475 (Fax) + 31 (0) 6 53718821 ( Parallelweg 2, NL-7141 DC Groenlo or P.O. Box 6, NL-7140 AA Groenlo, The -----Original Message----- From: Arthur Keller [mailto:ark@SOE.UCSC.EDU] Sent: dinsdag To: Jim Adler Cc: Arthur Keller; David Aragon (E-mail 2); stds-1583-stg3@IEEE.ORG; Subject: RE: AVVPAT-ABP revised draft Dear Jim, the changes to I.3.2.1 are relatively minimal, except renumbering to I.3.2.2.
This section refers to DRE/AVVPAT.
A new section I.3.2.1 refers to ABP (EBM and EBP) for which input was received from Populex only.
The Automark system would also be handled in this section, but no input has been received from them. I suggest we go with what I have and give them a chance to comment/revise it later. I've included a new section I.3.2.1 (ABP-20041130.doc) that should precede the existing section I.3.2.1 or follow it. For convenience, I've shown the changes from the existing I.3.2.1 (even though this section is an addition, not a replacement). Regarding the existing I.3.2.1: Comment 40, BO061 change conflicts with the split of ABP (EBM/EBP), so I made a different clarifying change instead. Comment 44, BO063, is replaced by the split of ABP. Comment 55, ISP034. I made
this change, but the proposed fix is infeasible. It is also
incompatible with I.3.2.1.2.3.4 Comment 65, BO064. I
suggest replacing the prescriptive "is expressly permitted" (for physically adding write-in candidates)
by "may be permitted."
The proposed edit *enforces* an alternative design to using the keyboard or a keyboard metaphor. Comment 66, BO065. I did
not make this change, since it does not apply to DRE with AVVPAT.
It instead applies to EBP/EBM's. Comment 73, BO069. I made
the change, except for the replacement of "accept" to "cast". In a AVVPAT, the paper trail is not
cast, since it's an audit trail. On an
EBM/EBP, the paper is cast. This is
part of the confusion for which EBM/EBP category was created. Comment 75, BO070, applies to EBM/EBP's not DRE/AVVPAT's. Comment 77, BO071, ditto. Comments 80-82, ISP049-051.
This change is inconsistent with change 84, BO072. I've made an
alternative change to Jim Adler's and left it for him to edit further.
I changed the first sentence to "any of the languages" and added "supported by the DRE in this
jurisdiction" Comment 89, ISP056. I put "for a reasonable ballot length" in
a different place where it fit better. Comments 90 and 91 conflict, so I deferred them for a group lead. Similarly Comment 92 was deferred I don't know how to reflect Comment 94. So I didn't. I've included a version of AVVPAT section I.3.2.1 reflecting the split with ABP(EBM/EBP) and comments 40-94 except as noted above. Sanford Morgenstern suggested this addition to end of the existing I.3.2.1.3.1.1.1. It's a
substantive change that requires change by group lead. All testing shall be performed on an end-to-end basis such that ballot information shall be prepared, loaded onto the DRE, cast on the DRE/AVVPAT, verified on the DRE/AVVPAT and tallied on such system intended for use with the AVVPAT.
Since in some jurisdictions, the AVVPAT may service as the determinant of the voter's intent, the AVVPAT must be capable of being tallied with the same accuracy as provided elsewhere in this Standard. At >Arthur - Do you have consensus on the change of I.3.2.1 from the
major >proponents of VVPB? I have no problem inserting it in its entirety,
I just >want to make sure we have some consensus. > >-- Jim > >-----Original Message----- >From: Arthur Keller [mailto:ark@SOE.UCSC.EDU] >Sent: >To: stds-1583-disc@IEEE.ORG; stds-1583-stg3@IEEE.ORG >Cc: Stanley A. Klein; Sanford Morganstein >Subject: AVVPAT-ABP revised draft > > >This is a replacement for section I.3.2.1 > >This reflects most of the comments from Stanford Morgenstern. > >The organization discussion group on stds-1583-disc identified
three >types of electronic voting machines that produce paper: > >DRE with an AVVPAT - Direct Recording Electronic with an Accessible >Voter-Verified Paper Audit Trail >EBM - Electronic Ballot Marker (a computerized device that marks a >paper ballot suitable for hand marking) >EBP - Electronic Ballot Printer (a computerized device that prints
a >paper ballot, including the selections for each contest) > >Before those terms were defined, I started working on a revision to >Rebecca Mercuri's AVVPAT annex, separating out something I called
an >ABP (Accessible Ballot Printer). It turns out that there is enough >in common between an EBM and an EBP that I was able to cover them >together (in the write up for an ABP), along with making the >appropriate distinctions along the way. Separating out the ABP from >the DRE-AVVPAT did simplify matters, however. I apologize to the EBM >community that I called the combination category an Accessible
Ballot >PRINTER. I'm open to an
alternative term. > >Stan Klein wrote a section he submitted on November 14. He wrote >about that section: >The title could remain "ancillary devices for optical scan
ballots" >or, if the EBM and EBP terminology becomes formalized, for >consistency it could be called "electronically assisted manual
ballot >marking" (EAMBM). > >We need to settle on a name for the combination of EBP/EBM, and we >need to harmonize Stan Klein's document with this document. > >Thanks. > >Best regards, >Arthur > >-- >----------------------------------------------------------------------- ----- >--- >Arthur M. Keller,
Visiting Associate Professor, Computer Science Dept. > > >tel +1(831)459-1485, fax +1(831)459-4829, www.soe.ucsc.edu/~ark -- ------------------------------------------------------------------------ ------- Arthur M. Keller, Visiting
Associate Professor, Computer Science Dept. tel +1(831)459-1485, fax +1(831)459-4829, www.soe.ucsc.edu/~ark |