In section 5.2, the accepting server ID should be retained in a write-request. Thus, EQ 5 should read
write-req = {CWID, write, accepting-server-ID, prev write-reply if any} ^ client.
Without knowing the identity of the accepting server, replay attacks could be detected --- but there would be no general way to distinguish the original write-req from replays.
It should also be noted that where ``prev write-reply if any'' is written, we don't want to ask the server to retain state forever for each client it has ever heard from. It is reasonable to expect there to be some notion of ``active sessions'' between clients and servers, and want to allow servers and clients to discard relevant state when a session is terminated. So the ``prev'' can mean ``previous in the same session'', not ``previous in the client's entire lifetime''.
While the general problems posed by corrupt clients are beyond the scope of the paper, one particular issue is in scope: a corrupt client must not be able to make a good server look bad. The design presented in the paper is intended to have this property.
We must say more about the structure of the CWID in EQ 5, so that a client will not submit the same write-req to a good server twice. (We do not expect that the ``prev write-reply if any'' will disambiguate in all cases, because the same write could be the initial write in two different client/server sessions.) The CWID should be something that the server can efficiently check that it has not seen before. Here is a structure with that property:
CWID = (client/server session ID, client's timestamp).
Here the ``client/server session ID'' is a timestamp assigned by the server, and the ``client's timestamp'' is a timestamp assigned by the client. The only requirement on session IDs is that a given server assign them in increasing sequence, and the only requirement on client timestamps is that those of a given session be assigned in increasing sequence.