diff --git a/notes/ram.md b/notes/ram.md
index 4919bfd845ff410f185bf7e4ad050bfffbeaf146..5eb5b80d8720e709e3617136c76dea606cace599 100644
--- a/notes/ram.md
+++ b/notes/ram.md
@@ -227,20 +227,20 @@ When received by server:
   - `prepare` (version/lock checks)
   - `decision` (this phase in background, client already notified)
      ("the transaction is effectively committed once a durable lock record has been written for each of the objects")
+  - **strict serializability** using **optimistic cc**
 - updates deferred until commit request
 - reads executed normally, *versions recorded*
 - writes on commit phase, possibly w/ expected version
+  - commit is two-phase
   - fail *if version-check fails, or locked by another transaction*
+  - **decision** RPCs in background
 - fast case
   - *single server* owns all objects in transaction
   - *read-only*, even in distributed case only a single round
 - on client crash, recovery coordinator finishes, hoping to abort unless already committed
 
 ## Issues
-- worried that storing completion records will not scale well
-  - local operation
-  - either disk or (for RAMCloud) replicating elsewhere
-- why optional version checking in transactions? (atomic operation primitive)
+- background decision RPCs imply longer lock holding
 
 
 ## Questions/comments