I think the best solution to this termination/expiration mess is to separate completely the notions of "lifetime of obligations" and "lifetime of Agreement interface". A. The lifetime of obligations should be captured solely in term-level meta-data and/or domain-specific lifecycle models. Individual service or guaranatee terms MAY have expiration times on them that are set statically or renegotiated by a mechanism outside the scope of our first specification. Additionally, some obligations MAY last indefinitely or until some domain-specific events occur. B. The lifetime of the service interface SHOULD be greater than the effective lifetime of any obligations, but I guess I can accept that this may not be possible with limited Agreement implementation QoS. It is hard to be normative about such failure modes. C. I suggest that we drop (for now) any notion of terminating the obligations using WS-Agreement mechanisms. If we can find a clear proposal for handling such ammendment of obligations before the spec is done, I am not personally against reincorporating it in some form. D. I suggest that we defer to WS-ResourceLifetime for handling the termination of the Agreement resource itself, with the specification advocating the above "SHOULD" about Agreements outlasting their embedded obligations (B). E. We should introduce an agreement-wide state, complementing the proposed Pending/Rejected/Observed states, to represent the Complete or PostObserved condition where all terms have passed "out of scope" and into history. What is the best state name for this? F. Should we introduce any kind of "linger" time to indicate an interaction with WS-ResourceLifetime to commence an automatic countdown to Agreement destruction once it has reached the Complete or PostObserved state? karl -- Karl Czajkowski karlcz@univa.com