Hi I think some of the confusion around the Reservation State Machine (RSM) comes from that a connection can have multiple revisions and that each revision can actually go through the states. This makes it very tricky to have a state machine that works across multiple revisions. A better approach might be to have an RSM per revision. I have attached a PDF of how I think such a state machine could look. Reserve_Aborted is now a stable state, indicating that the revision has failed. A new revision can be started from all stable states. This makes it very clear where each revision is in its lifecycle. There could be a state after Reserve_Committed to indicate that the reservation has been superseeded by a new revision, but since we probably wouldn't expose that, I don't think it is strictly needed. The Provision State Machine (PSM) and Lifecycle State Machine (LSM) should be per connection. On a side note: I think having 2PC will create more problems than it solves, as getting that to work in a multi-domain environment is going to be very tricky. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet