The Part-Time Parliament
Lamport

This was a pretty whacky paper.  I can definitely understand
why Steve recommended that we read it twice -- not so much 
because the concepts are so complex, but mainly because the
analogy gets a little out of control without referencing the 
computer science context until very briefly at the end.  In
fact, I was really surprised at how little there was to draw
the connections at the end.  I've actually written a paper
with a similar story-telling analogy to describe a computer
science problem before, but I alternated sections of analogy
and the context.  After reading this paper, I think that this
paper would have benefited from that form...I also think that
my paper might have been a little too cute (which is what I 
thought about this paper most of the time).

One could argue that the intended references within the 
analogy are obvious and don't need to be explained, but I 
found myself often thinking of connections to distributed
systems, but I wasn't sure if I was thinking of the same ones
that Lamport was.  Part of the confusion was that many of the
concepts are related to transaction processing, including
two-phase commit, which I believe was published in the 80s.
So, I couldn't be sure if Lamport's 1998 paper was using 
the analogy only to describe the one "synodic protocol" 
that is proven in the appendix, or whether he was using
the analogy to touch upon many other concepts that had
already been published (or maybe both if the protocol 
borrows from many past areas, I suppose).  I did notice
the editorial references explaining that the paper was
submitted in 1990, was only recently "found".  However,
since the editorial also plays within the context of the
analogy to some extent, it was hard to know when it was
joking (maybe I would have been able to figure this out with
a little more sleep).

Regarding the comparisons between the analogy and the 
computer science context, here are some of my observations:
- the notes that disappear (as opposed to the ledger): 
volatile and persistent storage
- telling time with 15 min precision: pointing out the
necessity to add clock drift into wait time calculations
as Cristian's paper mentioned.
- messengers that may deliver more than once or take a 
vacation and come back with the message or never deliver:
obviously the exactly once, at least once, or failed
delivery issue.
- voting in a quorum that requires a unanimous vote:
nodes within a network voting that they are ready to 
commit?
- ballot numbers based on priest name and number: 
obviously machine ids and numbers, or guids.
- Voted(b,q) can be issues many times with no altering
affect: idempotency of voting (voting ready to commit?)
- LastVote message represents a promise not to vote
in any ballot numbered between v_bal and b: I think
this is touching on TP serialization issues.
- president: transaction coordinator
- keeping a list of decrees on a sheet of paper and 
updating the ledger only 2-3 times a week: is this
like flushing a transaction log?
- monotonicity and the "reading the law" decree:
read locks
- weaker version around causality: this reminded me
of TP concepts, such as holding a read lock until the
transaction commits.
- specialists: could this relate to partitioning of
records onto different servers?

Also thought it was too bad that the paper wasn't 
written three years later, just after the 2000 
Presidential election, instead of having to talk 
about a hypothetical result of the 1992 election.