IEEE Working Group P1622 Meeting February 24-25, 2013 National
Institute of Standards and Technology Gaithersburg, MD
Slide 2
Exits and Facilities -Building 222 has two long hallways, A and
B, with connecting corridors in-between and at both ends -You are
on the A hallway -Exits are at either ends and in the middle (we
are closest to the exit where you entered) -Mens/Womens restrooms
are at either ends of central corridor (Womens on A, Mens on B)
2
Slide 3
Introduction -Welcome: John Wack, Arthur Keller -Agenda
overview: John Wack -IEEE call for patents: Arthur Keller 3
Slide 4
NIST support for P1622 Organizing and hosting meetings Building
membership Technical editor of standard Technical support Schema
development Data models Standard development Website re-vamp 4
Slide 5
Meeting Agenda Day 1 All times given are in Eastern Time, GMT
-5. 1pm 1:15pm - Introduction -Welcomes: John Wack, Arthur Keller
-Agenda overview: John Wack -IEEE call for patents: Arthur Keller
1:15pm 2pm - Policies and Procedures revisions -Revision to
policies and procedures for membership criteria: Arthur Keller
-Policies and procedures updates for sponsoring committee for
P1622: Arthur Keller 2pm 2:30pm - Election Assistance Commission
-Increasing participation in P1622: Brian Hancock -Conformance
testing versus interoperability testing: Brian Hancock, Mark Skall
2:30pm 2:45pm Break 2:45pm 4:30pm - Election results reporting
standard -Overview of standard: John Wack -EML 520 schema
discussion: John Wack, Kim Brace, David Webber 4:30pm 4:45pm Break
4:45pm 6pm - Election results reporting standard continued 6pm -
Wrap-up and Adjourn 5
Slide 6
Meeting Agenda Day 2 All times given are in Eastern Time, GMT
-5. 8:30am 9am - P1622 membership and elections -New member
announcements: Arthur Keller -P1622 officer elections: Paul Eastman
9am 10:30am - Continuation of election results reporting standard
-Review of day one discussions: John Wack -Comparison with
Associated Press reporting formats: Don Rehill -Vote to incorporate
changes and prepare draft for balloting: P1622 chair 10:30am
10:45am Break 10:45am 12:15pm - Event logging standard -Overview of
recent event logging work in SC: Duncan Buell -Discussion on
forming a PAR for an event logging standard: Duncan Buell 12:15pm
1:30pm - Lunch NIST cafeteria suggested 1:30pm 3pm - Open Source
Digital Voting -Modifications to EML 310, 330: Anne O'Flaherty 3pm
3:15pm Break 3:15pm 4pm - NIST Election data model development
-Creation of comprehensive UML data model: John Wack 4pm 5pm -
Other business -Cast vote record audit discussion: Neal McBurnett
5pm - Wrap-up Adjourn 6
Slide 7
The IEEE-SA strongly recommends that at each WG meeting the
chair or a designee: Show slides #1 through #4 of this presentation
Advise the WG attendees that: The IEEEs patent policy is described
in Clause 6 of the IEEE-SA Standards Board Bylaws; Early
identification of patent claims which may be essential for the use
of standards under development is strongly encouraged; There may be
Essential Patent Claims of which the IEEE is not aware.
Additionally, neither the IEEE, the WG, nor the WG chair can ensure
the accuracy or completeness of any assurance or whether any such
assurance is, in fact, of a Patent Claim that is essential for the
use of the standard under development. Instruct the WG Secretary to
record in the minutes of the relevant WG meeting: That the
foregoing information was provided and that slides 1 through 4 (and
this slide 0, if applicable) were shown; That the chair or designee
provided an opportunity for participants to identify patent
claim(s)/patent application claim(s) and/or the holder of patent
claim(s)/patent application claim(s) of which the participant is
personally aware and that may be essential for the use of that
standard Any responses that were given, specifically the patent
claim(s)/patent application claim(s) and/or the holder of the
patent claim(s)/patent application claim(s) that were identified
(if any) and by whom. The WG Chair shall ensure that a request is
made to any identified holders of potential essential patent
claim(s) to complete and submit a Letter of Assurance. It is
recommended that the WG chair review the guidance in IEEE-SA
Standards Board Operations Manual 6.3.5 and in FAQs 12 and 12a on
inclusion of potential Essential Patent Claims by incorporation or
by reference. Note: WG includes Working Groups, Task Groups, and
other standards-developing committees with a PAR approved by the
IEEE-SA Standards Board. Instructions for the WG Chair (Optional to
be shown)
Slide 8
Participants, Patents, and Duty to Inform All participants in
this meeting have certain obligations under the IEEE-SA Patent
Policy. Participants [Note: Quoted text excerpted from IEEE-SA
Standards Board Bylaws subclause 6.2]: Shall inform the IEEE (or
cause the IEEE to be informed) of the identity of each holder of
any potential Essential Patent Claims of which they are personally
aware if the claims are owned or controlled by the participant or
the entity the participant is from, employed by, or otherwise
represents Personal awareness means that the participant is
personally aware that the holder may have a potential Essential
Patent Claim, even if the participant is not personally aware of
the specific patents or patent claims Should inform the IEEE (or
cause the IEEE to be informed) of the identity of any other holders
of such potential Essential Patent Claims (that is, third parties
that are not affiliated with the participant, with the participants
employer, or with anyone else that the participant is from or
otherwise represents) The above does not apply if the patent claim
is already the subject of an Accepted Letter of Assurance that
applies to the proposed standard(s) under consideration by this
group Early identification of holders of potential Essential Patent
Claims is strongly encouraged No duty to perform a patent search
Slide #1
Slide 9
Patent Related Links All participants should be familiar with
their obligations under the IEEE-SA Policies & Procedures for
standards development. Patent Policy is stated in these sources:
IEEE-SA Standards Boards Bylaws
http://standards.ieee.org/develop/policies/bylaws/sect6-7.html#6
IEEE-SA Standards Board Operations Manual
http://standards.ieee.org/develop/policies/opman/sect6.html#6.3
Material about the patent policy is available at
http://standards.ieee.org/about/sasb/patcom/materials.html Slide #2
If you have questions, contact the IEEE-SA Standards Board Patent
Committee Administrator at [email protected] or visit
http://standards.ieee.org/about/sasb/patcom/index.html This slide
set is available at
https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.ppt
Slide 10
Call for Potentially Essential Patents If anyone in this
meeting is personally aware of the holder of any patent claims that
are potentially essential to implementation of the proposed
standard(s) under consideration by this group and that are not
already the subject of an Accepted Letter of Assurance: Either
speak up now or Provide the chair of this group with the identity
of the holder(s) of any and all such claims as soon as possible or
Cause an LOA to be submitted Slide #3
Slide 11
Other Guidelines for IEEE WG Meetings l All IEEE-SA standards
meetings shall be conducted in compliance with all applicable laws,
including antitrust and competition laws. l Dont discuss the
interpretation, validity, or essentiality of patents/patent claims.
l Dont discuss specific license rates, terms, or conditions. l
Relative costs, including licensing costs of essential patent
claims, of different technical approaches may be discussed in
standards development meetings. l Technical considerations remain
primary focus l Dont discuss or engage in the fixing of product
prices, allocation of customers, or division of sales markets. l
Dont discuss the status or substance of ongoing or threatened
litigation. l Dont be silent if inappropriate topics are discussed
do formally object.
--------------------------------------------------------------- See
IEEE-SA Standards Board Operations Manual, clause 5.3.10 and
Promoting Competition and Innovation: What You Need to Know about
the IEEE Standards Association's Antitrust and Competition Policy
for more details. Slide #4
Slide 12
Policies and Procedures revisions -Revision to policies and
procedures for membership criteria: Arthur Keller -Policies and
procedures updates for sponsoring committee for P1622: Arthur
Keller 12
Slide 13
Election Assistance Commission -Increasing participation in
P1622: Brian Hancock -Conformance testing versus interoperability
testing: Brian Hancock, Mark Skall 13
Slide 14
Break -2:30pm 2:45pm 14
Slide 15
Election results reporting standard -Overview: John Wack
-Districting and its complications: Kim Brace -EML 520 schema
discussion: David Webber -Next steps discussion: John Wack 15
Slide 16
Task force members Kim Brace EDS Joseph Hagerty SOS, CA Justin
Hankins ESS Matt Masterson SOS, OH Neal McBurnett Election Audits,
CO John McCarthy Verified Voting Jan van Oort Ian Piper Dominion
Paul Stenbjorn ESS Beth Ann Surber SOS, WV John P Wack NIST Webber,
David RR - Oracle Sarah Whitt SOS, WI Additional: Don Rehill, David
Stonehill AP 16
Slide 17
1622-2 PAR - Scope This standard defines common data
interchange formats for information reported about election
results. Election results information is based on data from vote
capture devices and resultant tabulation data or other information
about the election from election management systems. This standard
focuses on the OASIS EML version 7 schemas 510, 520, and 530, which
contain data elements and structures for contest totals and
associated counts used for reconciliations and audits. 17
Slide 18
1622-2 PAR - Purpose This standard facilitates the import and
export, in a common format, of election results data that is
typically reported from distributed voting places to central
offices of local jurisdictions, from local jurisdictions to state
election systems, and from local and state election offices to news
media and the general public. It can also facilitate post-election
auditing of election results. 18
Slide 19
Use cases supported 1.A state/county reporting outward to the
public/media on election day using an EML 520 file very simple
aggregated counts, possibly broken down by reporting unit 2.A
county or similar reporting unit reporting upward to a central
elections office on election day using an EML 520 file simple
aggregated counts or more detailed counts as available
3.Post-election reporting in more detail or certified results or
election archive using an EML 520 file - more detailed counts,
broken down by reporting unit Note: Use case 3 is almost identical
to use case 2 in that reporting election results in detail on
election day ends up being mostly the same as a post-election
election archive. 19
Slide 20
Optional counts and tags Counts include ballots cast, ballots
read, ballots counted, contest vote totals, and
overvotes/undervotes. Capability to "tag" counts with the manner of
voting, e.g., absentee, in person, etc. Capability to tag counts
with voting technology, e.g., op scan, DRE, manual count paper,
etc. This includes tagging overvotes/undervotes with voting
technology if possible. Note: most counts and tags are the result
of requirements analysis of EACs VVSG 20
Slide 21
Additional capabilities added Reduce file sizes by associating
contest and candidate and reporting unit names with IDs First send
of the file contains the mapping Subsequent files use only IDs Be
able to report on virtually any level of district breakdown First
send of file identifies district breakdowns and their associated
IDs 21
Slide 22
Districting is complicated 22
Slide 23
By Kimball Brace, President Election Data Services, Inc.
February, 2013 Basic Election Administration: A Summary of
Findings
Slide 24
Basic Election Administration Facts Diversity is the
underpinning of Elections. 50 States 3,140 Counties 1,620 NE
Townships 5,312 Midwest Townships 10,072 Election
Jurisdictions
Slide 25
Basic Election Administration Facts Size is important to
remember Question: What is the mean size of jurisdictions in nation
in terms of registration? 1,492 registered voters Over 1/3 rd of
nations counties have fewer than 10,000 registered voters in them
Half of the nations counties have less than 16,000 registered
voters Only 343 jurisdictions have more than 100,000 registered
voters Only 14 counties have more than 1 million voters Smallest
County: Loving County, Texas: 136 voters Largest County: Los
Angeles, CA: 3.9 million voters Take 930 smallest counties to reach
LAs total.
Slide 26
Basic Election Administration Facts
Slide 27
Slide 28
Census Geography
Slide 29
Hierarchy of Census Geographic Entities
Slide 30
30 Census Geography Overview
Slide 31
State is composed of Counties
Slide 32
Counties are composed of Precincts (VTDs)
Slide 33
Precincts are composed of Census Blocks
Slide 34
Census Block Level
Slide 35
Address Points within Blocks
Slide 36
Thank you Kimball Brace President Election Data Services, Inc.
6171 Emerywood Court Manassas, VA 20112 (703-580-7267 or
202-789-2004)
[email protected]@electiondataservices.com or
[email protected][email protected] www.electiondataservices.com
Slide 37
Current status Several revisions of schema, current version
implements most but not all optional counts Starting to examine and
compare with other schemas and formats to ensure completeness
Discussions with AP have been fruitful AP focused more on election
night reporting Would opt for as much standardization as possible,
include IDs for contest/candidates/districts 37
Slide 38
Open questions Has schema gotten too complicated for use in all
three use cases Should a simplified schema be used for election
night (does it matter if multiple schemas)? Should the standard be
divided into two standards so as to make faster progress? Should
this be a brand-new schema? 38
Slide 39
Next steps Complete a simple data model and ensure that schema
implements the model The model should respond to requirements, thus
requirements above/beyond VVSG must be documented A need to study
other reporting formats being used (AP, other states, etc) to
ensure completeness 39
Slide 40
Break -4:30pm 4:45pm 40
Slide 41
Election results reporting standard continued 41
Slide 42
Wrap-up and Adjourn 42
Slide 43
Meeting Agenda Day 2 All times given are in Eastern Time, GMT
-5. 8:30am 9am - P1622 membership and elections -New member
announcements: Arthur Keller -P1622 officer elections: Paul Eastman
9am 10:30am - Continuation of election results reporting standard
-Review of day one discussions: John Wack -Comparison with
Associated Press reporting formats: Don Rehill -Vote to incorporate
changes and prepare draft for balloting: P1622 chair 10:30am
10:45am Break 10:45am 12:15pm - Event logging standard -Overview of
recent event logging work in SC: Duncan Buell -Discussion on
forming a PAR for an event logging standard: Duncan Buell 12:15pm
1:30pm - Lunch NIST cafeteria suggested 1:30pm 3pm - Open Source
Digital Voting -Modifications to EML 310, 330: Anne O'Flaherty 3pm
3:15pm Break 3:15pm 4pm - NIST Election data model development
-Creation of comprehensive UML data model: John Wack 4pm 5pm -
Other business -Cast vote record audit discussion: Neal McBurnett
5pm - Wrap-up Adjourn 43
Slide 44
P1622 membership and elections -New member announcements:
Arthur Keller -P1622 officer elections: Paul Eastman 44
Slide 45
Continuation of election results reporting standard -Review of
day one discussions: John Wack -Comparison with Associated Press
reporting formats: Don Rehill -Vote to incorporate changes and
prepare draft for balloting: P1622 chair 45
Slide 46
Break -10:30am 10:45am 46
Slide 47
Event logging standard -Overview of recent event logging work
in SC: Duncan Buell -Discussion on forming a PAR for an event
logging standard: Duncan Buell 47
Slide 48
Lunch NIST cafeteria suggested -Resume at 1:30pm 48
Slide 49
Open Source Digital Voting -Modifications to EML 310, 330: Anne
O'Flaherty 49
Slide 50
Bringing Transparency to Voter Registration and Absentee
Voting: OSDV/VA-SBE Use of CDFs in 2012 NIST CDF Workshop 2013
Slide 51
Why we are here: to brief the Workshop on real-world use of
both standard and proposed common data formats in 2012 Who, What,
Where, When: In collaboration with Virginia State Board of
Elections and others in FVAP-funded project, all year long
Background: OSDV, TrustTheVote, who we are, what we do Background:
VA 2012 Project The Main Event: details about the project, CDFs,
lessons learned More: more details on a new data format and use
case Whats Next: continuing work, related work CDFs in Real Use in
2012
Slide 52
OSDV Foundation: pending non-profit corporation to support the
election technology reform mission OSDV Team: Managing directors,
board of trustees, general counsel, outside counsel for open-source
licensing and IP, outside CPA, I.T. provided by Open Source Labs at
Oregon State U. TrustTheVote Project: Open-source election
technology development project supported by OSDV TTV Team: CTO,
Project Leaders, UI designers, spec writers, data interchange
experts, software developers TTV Stakeholders: Adopters - U.S.
election officials; legislators; good-government groups; election
integrity advocates; grant making organizations, individual donors
OSDV: Who We Are
Slide 53
Mission: Develop publicly owned technology blueprints and
implementations of election technology components Scope: Tech for
election administration, ballot casting and counting, the whole
electoral process from voter registration to reporting election
results Transparency: All work product is open-source, open-data,
and supports public access to detailed data recording everything
about election administration and results of elections Work
Product: White papers, Request for Comments (RFCs), architecture,
component specifications and requirements, data format definitions,
reference implementations of specifications, software OSDV and TTV:
What We Do
Slide 54
Donors: provide funding for Foundation operations, and for
directed development projects Stakeholders: provide responses to
white papers, RFCs, spec, etc. Collaborators: stakeholders who help
us develop work product Volunteers: Do tech work (spec dev,
reference software, ) on funded and unfunded projects within the
TTV Project Contractors: Do tech work on funded projects Adopters:
LEO or SEOs, stakeholders who adopt and adapt open source software,
deploy it for internal use or to deliver services to the public
OSDV and TTV: Who and How We Do What We Do
Slide 55
SBE: received one of the first EASE grants from FVAP, to make:
Online voter services for voters to properly complete voter
registration and absentee ballot application forms Digital ballot
delivery and marking service for UOCAVA voters Audit and reporting
to FVAP of voter usage and outcomes Forms and ballots use existing
print/sign/mail model Participants: In addition to SBE and OSDV:
Democracy Live: commercial vendor of online ballot product
Microsoft: application hosting & system integration of DL with
VA Cyber-Data: application hosting & SI of Portal and Analytics
TTV and Virginia State Board of Elections: Collaboration in 2012
SBE: Virginia State Board of Elections EASE (Electronic Absentee
Systems for Elections) UOCAVA ((Uniformed and Overseas Citizens
Absentee Voting Act) FVAP (Federal Voting Assistance Program) MOVE
(Military and Overseas Voter Empowerment ) Act
Slide 56
SBE IT: System integration of legacy systems with new systems
OSDV: provide open-source software for project : Adapt online VR
tool to become Voter Services Portal Integrate Portal with legacy
voter record system Integrate Portal with Democracy Live product
deployed by MS Develop Analytics tool Support Cyber-data deployment
of OSS from public repo Democracy Live: Data integration with
legacy voter record system, web services integration with Portal,
data integration with Analytics, support Microsoft deployment of DL
product MS and CyberData: deploy application software in the
hosting environment, provide ongoing system and application support
VA SBE EASE Project Team
Slide 57
The Big Picture: poster of the world after the project Voters:
workflows for online (Portal or DL) and offline voter registration
request, voter record update request, absentee ballot request, FPCA
request, absentee ballot or FWAB Online: print, sign, mailOffline:
scrawl, sign mail LEOs: process request forms and ballots, on- or
off-line generated receive forms in mail, approve or deny, log
decision receive absentee ballots in mail, count or deny, log
decision receive provisional ballots from polls, count or deny, log
decision receive poll books from polls, update voter records SBE:
pull log data from other 3 system, push into Analytics generate and
pull reports and aggregated data Project Outcome
Slide 58
Now that you know how it ended, how did we get there? Project
Details
Slide 59
Voter Services Portal Workflow Print, sign & mail form.
Voter Statu s Chec k Registered? No Democrac y Live System Virginia
Existing Systems Eligible to get electronic ballot? Yes Assist
completing voter registration Assist completing voter forms No
Portal: Web Application for Voters Voter (via Web Browser) Print,
(mark), sign, & mail UOCAVA Absentee Ballot. County / City
Registrar County / City Registrar
Slide 60
Open Source: software should be open source, freely available
to other election officials to adopt and adapt Open and Flexible:
SBE unconstrained in future as to who/how to expand, enhance,
scale-up, etc. Open Data: data interchange and data output using
public common data formats, using standards where available Cloud
Hosting: public facing software with out-sourced hosting,
cost-effective, and flexible for scaling State Hosting: Voter
records and other data repository remain hosted and managed by SBE,
with web services interface to new software, with both hosting orgs
implementing appropriate security measures Portal and Analytics
Software Goals
Slide 61
EML Usage and APIs for Data Interchange Voter Statu s Chec k
Registered? Democrac y Live System Virginia Existing Systems
Eligible to get electronic ballot? Assist completing voter forms
Portal: Web Application for Voters Voter (via Web Browser) Web
services API Request: Voter ID or SSN4 and name + Locality and DOB
Web services API Response: No match, or Match + EML 330 record Web
services API Push: EML 310 record with Voter-supplied information
that was included in the PDF document sent to user, and PDF
document tracking ID for later scan/lookup by LEOs when form is
received HTTP Post: Voter ID and precinct ID used by DL determine
which ballot to present
Slide 62
What Worked: excellent starting point for representing all the
contents of a Virginia VR form for domestic voter registration,
UOCAVA registration (VA FPCA), domestic voter record update,
domestic absentee ballot request, UOCAVA update (VA FPCA)
Extensions Needed: Several voter checkboxes (e.g. military,
overseas) FPCA voter type (which of 4 kinds) FPCA military info
(branch, rank, ID number) VA FPCA extensions VA residence
(un)available VA eligibility felony or incapacity history, restore
dates Address confidentiality !!! including VA-specific related
info What Didnt Work: Schema validation problems; needed more
examples for clarity and to explain to non-tech stakeholders EML
310 Usage
Slide 63
Example: Check Boxes
Slide 64
Example: Extensions for VA Specific Registration or Absentee
Form Info
Slide 65
Add a Status element and @status attribute status to Voter
after the DateTimeSubmitted element at the bottom @status to
VoterInformation element and to VoterIdentification element status
values: New, Updated, Removed, Pending, Expired, Deceased @status
values: New, Updated, Removed, Pending, Expired All VToken elements
need to be a repeatable - right now they are simply optional; we
need to be able to track multiple events and information exchanges
in the extended use cases What is the difference between
VTokenQualified and VToken? The definition text is obtuse - we need
this more clearly explained in the text. 1.VTokenQualified: VToken
that is permitted to be used for the purpose and context of a
particular process and event. 2.VToken: A unique identifier for a
device or entity involved in the voting process. Status (Proposed
3/2012 David Webber)
Slide 66
What Worked: excellent starting point for representing all the
contents of a Virginia voter record needed to (1)Determine
eligibility to use DL ballot system (2)Enable voter record updates
Extensions Needed: Several voter attributes Election list Past
election list elements for voting history Future election list
elements for absentee status or lack thereof UOCAVA specific
information, e.g. absentee status expiration What Didnt Work:
slightly poor fit with VA voter model generally; very poor fit with
VA model of absentee voting EML 330 Usage
Slide 67 2012 May City General 2012 May City General