[graap-wg] termination versus determination

[Jon MacLaren]

I think that escaping from an agreement should always be considered 
domain specific, and remain outside of the scope of the protocol.  The 
proposed standard already encompasses agreement discovery, creation and 
monitoring.  I think including specific support for acceptable 
scenario-specific escape conditions introduces another facet.

Introducing the terminate operation tries to do this too.  In my view, 
it provides a false panacea - it encourages people to believe (and 
perhaps even expect) that they can simply and generically escape from 
an agreement...

Jon.


On Mar 2, 2005, at 8:40 PM, Karl Czajkowski wrote:

> On Mar 02, Heiko Ludwig loaded a tape reading:
> ...
>> I figure the notion of an "contract end date" refers mostly to a
>> colloqialism implying the time when all obligations relating to 
>> service
>> of the contract are over and is particularly applicable to services
>> that are provided for a particular time.
>>
>
> I agree. If I am understanding the objections raised, it is that even
> this "simple" case is underspecified.  Even if termination is meant
> for things like "end my job", I think Jon has raised the issue that
> you really need to know in what way (with what amended obligations)
> the job will be ended... who gets paid what, etc.
>
> I think it would be more clear if we just had a way to annotate
> service descriptions w/ temporal scoping (start+end times) and leave
> the whole Agreement expiration as the latest of all service
> description end times.  To adjust the end time(s) would require
> amendment of the scope of these services.
>
>
>> Q: Do we want to make the resource lifetime the equivalent of the time
>> of the main service; and what if the model doesn't fit, e.g., in case
>> of a set of services, disputes or services where an end time doesn't
>> really apply.
>>
>
> I had assumed from the start (until I read that bit in the draft about
> the separate agreement expiration time) that the times were the same.
> I realize now that this becomes murky when one pays attention to cases
> with more than one service or when the "second-class" obligations,
> like accounting and payment, become an issue...
>
>
>>>      Q: Should retirement ever be allowed while service-domain
>>>      obligations are still in scope?  Can we even distinguish what I
>>>      referred to before as "first class" obligations (like running a
>>>      job) from "second class" obligations (like making payment)?
>>>      Perhaps some extra markup could annotate such terms?
>>
>> This means that the AgreementProvider will se tthe resource lifetime
>> according to the (domain-specific) times the terms indicate and will
>> only really end the resource when the last "main" obligation is
>> fulfilled. What happens if it never is, if something goes wrong?
>>
>
> Then the resource would stick around and hopefully indicate a
> "something has gone wrong, please help me" status? :-) Note, however,
> that I think obligations could equally go out of scope after having
> been satisfied or violated and abandoned.  Once there is no more
> service action that will result, we are just talking about knowledge
> of past obligations for accounting.
>
> I don't think there is ever a time when it is impossible that an
> amendment could be made, so I am willing to admit that some amendments
> will happen after the Agreement resource has been retired.  For
> example, contested payment obligations could be reversed or even just
> refunded on a basis of generosity (or any arbitrary domain-specific
> policy).  I am not advocating that Agreement resources must persist
> forever to allow for these cases.
>
>
>> I am not sure whether we want to bring too much contract-specific
>> semantics to the notion of recource lifetime. If we cannot map
>> reasonably, we should keep it separate.
>>
>
> I think we could (must?) avoid mandating a behavior because it is so
> dependent on domain-specific semantics.  But I think we could appeal
> to intuition and abstraction in trying to clarify the difference
> between "retiring" the resource and actually amending obligations; I
> think it would be best for most domain-specific deployments of
> WS-Agreement to resist tearing down the management interface before
> the interesting obligations are met or terminally rejected.
>
>
>> Following approach 2 entails extending the obligation and rights
>> semantics that we have. At the moment we don't have the explicit 
>> notion
>> of an option on an agreement level, just service terms and guarantee
>> terms. However our service description terms might contain this on the
>> domain-specific level. We could extend our term model to distinguish
>> options, guarantees and services (what will be done without exercising
>> the option). That's what WSLA provides and it worked well. On which
>> level, though, will the AgreementProvider offer an operation to
>> exercise an option, if we assume that also the initiator might want to
>> exercise it: Agreement or service?
>>
>
> I could accept the "options" being encoded explicitly or implicitly in
> domain-specific terms/extensions.  The only question then is whether
> obligation termination or amendment can be addressed through a generic
> "terminate" operation or whether domain-specific "exercise option Foo"
> operations must always be introduced for this?
>
>
>> 2 and 3 point to a model where agreements basically modify the set of
>> rights and obligations that are in force between 2 parties. That's a
>> model that is not uncommon in service management but would require 
>> some
>> adjustments to the expressivness of the agreement spec and it raises
>> the issue of how to expose the state monitoring. A per-agreement state
>> monitoring might not be appropriate in this case.
>>
>
> I am not sure this introduces as much complication as you imply.  I
> think all agreements always "modify the rights and obligations that
> are in force between 2 parties", because these parties live in a
> stateful and finite universe.  So I've _always_ viewed WS-Agreement as
> modifying the universe of policies based on a particular set of
> "transient" goals.  The specification is more or less aligned to
> support this now, and I think we just need to clean up some rough
> edges.
>
> As for monitoring, I think any realistic scenario will always admit
> that there are external services and parties who may play parts in
> monitoring, detection, adaptation, audit, and accounting.  When I say
> "external", I mean external to the WS-Agreement specification and
> quite possibly external to any domain-specific Agreement that is
> established.  WS-Agreement only needs to establish the parts that are
> being dynamically established and adjusted by automated entities; it
> does not have to presume an initial context of nothingness between the
> parties.
>
>
>> Amending the spec in the proposed sense might be worth the effort but
>> it will take some time. Furthermore, the proposal puts quite some more
>> requirements on the implementors of the spec. Finally, we still don't
>> have a very simple mechanism by which initiator or provider can
>> terminate the agreement consensually and easily. The terminate
>> opreation was meant do provide this, probably still requiring all 
>> those
>> mechanism you listed above.
>>
>
> I'm not sure how much more requirements are placed on implementors.
>
> Again, I see this mostly as trying to clarify the semantics of what we
> are proposing (and adjusting the mechanisms if they aren't consistent
> with a reasonable semantics).  The only implementor burden I see is in
> understanding the domain terms well enough to decide if
> termination/amendment should be allowed or not, and I think this
> burden already existed; I think this discussion is just about how to
> render the mechanisms to clarify their meaning as it relates to the
> domain-specific environment.
>
>
>> <rest removed>
>>
>> Heiko
>
> karl
>
> -- 
> Karl Czajkowski
> karlcz at univa.com
>