I wish to raise the discussion again regarding what I find as confusing facets of lifecycle in the WS-Agreement draft spec. In my earlier note about asynchronous/asymmetric operation patterns, I suggested that one way to address the message correlation problem is to return to something like our earlier Agreement state-machine: We could return an Agreement resource EPR immediately and have the Agreement start in a "not committed" state, which I will call "DecisionPending" to avoid confusion with the removed negotiation facilities. The initiator (client) can then monitor/poll the Agreement resource to determine whether the responder (service) accepts the offer or not. I think this would be a good change to allow an application-level asynchronous creation or other future negotiation patterns to compose with the basic Agreement presentation. I see the lifecycle then being basically: 1. DecisionPending 2. Observed (passively or actively) [violated or satisfied] 3. Complete (no longer observed) [violated or satisfied] These three phases are demarked by the state of the obligations between the two parties: there are no obligations yet in (1); in (2) the obligations are present but whether they affect service delivery has to do with the precise scoping of the terms; and in (3) the obligations are still present in a historical sense, but they are permanently out of scope and no longer affect service delivery. During observation (2), we can also consider whether the obligations are presently being satisfied or violated. This relates to the monitoring/enforcement discussion as to whether we wish to capture this in any way. During both (2) and (3), we can consider historically whether the obligations were satisfed or violated and by "how much". This relates more to audit and accounting. This notion of satisfied/violated is represented in the Guarantee States diagram as not-determined, fullfilled, and violated. As I read it, this section refers to the present conditions of phase (2) only, without any memory of past delivery. The basic state phases described above sound similar to the Service Runtime States diagram, but this part of the spec is scoped to individual services rather than the agreement as a whole. I think the states here are are embedded in the Observed (2) phase, except when all service terms are in the "Completed" state then the agreement as a whole is Completed as well. I have minor quibbles with the states "Ready," "Not Ready," and "Processing" which I think are straying towards domain-specific extensions. I think a generic state would be more like "Out of Scope" and "In Scope", e.g. is the service present according to the scoping conditions of the agreement terms. Orthogonally, we can consider readiness as whether the service terms are fullfilled or violated according to this scoping. Thoughts? Rotten fruit? karl -- Karl Czajkowski karlcz@univa.com