[graap-wg] termination versus determination

[Jon MacLaren]

 From your list, I think that only c) and d) can work.  a) and b) assume 
a lot about when payment occurs, etc.  I'm not sure that it's always 
possible to roll things back.

The way that you "get out" of a contract, is by both parties signing 
some sort of "amendment" to the contract - case c).

It is possible that there would be some sort of clause pre-written into 
some agreements - your case d).  These could be used to handle specific 
things like, "if the resource falls over during the execution of your 
job, you get any money back, and there's nothing else to happen between 
us".  Note that these are not something special - they are simply the 
"compensation" clauses that we used to talk about in GESA.

I think you need to able to do c) - to just have d), you need to be 
able to predict all the conditions that might arise, which is (of 
course) impossible.  (Incidentally, I argued for c) strongly in the 
past, when I first saw the "terminate" operation.)


I think that one of the reasons that thinking about this is complicated 
is that you have a resource, fronted by a service, to represent the 
agreement.  It's a very odd responsibility model - essentially a single 
(potentially third) party is trusted for maintaining the definitive 
version of the agreement.  I disagree with Karl's statement that the 
resource IS the agreement - if this were true, some accident befalling 
the resource can eliminate it!

In Grid computing, resources are fallible.  They can disappear.  What 
happens when a WS-Agreement resource fails?  Is it equivalent to 
contracts disappearing into thin air?  Or do we say that WS-Agreement 
resources have to be reliable, and always available?  If so, how is 
this achieved?

If the agreement was represented by a signed document, which both 
parties had a copy of, then these strange issues about the meaning of 
terminating the service would not present themselves.  Both parties 
have a responsibility to look after their copy of the agreement...just 
like that paper based system which has worked for hundreds of years.

Jon.


On Feb 25, 2005, at 12:43 AM, Karl Czajkowski wrote:

> The whole idea of an abstract "agreement" that is separable from the
> Agreement resource is troublesome.  In order to make sense of it, I
> have taken to understanding the "agreement" word to mean "the
> obligations to which the parties are bound as a result of this
> WS-Agreement interaction."
>
> I cannot readily accept the idea that the Agreement resource can be
> destroyed and yet the "agreement" still exists in some state other
> than "all obligations are now historical and let's balance the
> accounting."  If the agreement terms have obligations that are still
> within scope, I think it should be impossible to destroy the Agreement
> resource which represents the management interface to those
> active/pending behavioral obligations.
>
> The spec currently says, I think, that the resource SHOULD outlast the
> agreement and I think the spec should read that the resource MUST
> outlast any obligations denoted in the agreement.
>
> I think, but am not sure, that Heiko's idea of terminating an
> agreement (not the Agreement resource) is to release the parties from
> these obligations. If I understand Jon's objection, I think it is that
> such a notion is not really well defined.  Releasing parties from the
> obligation can mean a number of different things:
>
>   a) Truncate the scope of obligations and resolve accounting as if
>      the obligations had been scoped from their original start time
>      until the time of this truncation.
>
>   b) Act as if the obligations never existed, and each party absorbs
>      their own costs incurred so far.
>
>   c) Form a new Agreement which amends the obligations of the old;
>      resolve accounting based on the new terms, which could encode a
>      detailed transitional cost model, etc.
>
>   d) Trigger some existing "escape" clause in the agreement terms
>      which specified how to amend the obligations as in (c).
>
> Of course, in all of these there is an assumed change in behavior of
> the parties to coincide with these changes in obligation.
>
> I think it is a fair point that one cannot simply talk about
> terminating the Agreement resource or its represented obligations
> without identifying which of these avenues (or some other) are to be
> followed.  In the real world of contracts and agreement, things are
> not destroyed so much as ammended and obsoleted.  The old stuff is
> never forgotten, and in fact can be dragged in to court as evidence to
> help resolve later conflicts.
>
> At the same time, we have practical use for cancelling the obligations
> in some domains, e.g. cancel a job halfway through the run.  What we
> need to do is capture the right form of ammendment.  I think for jobs,
> the flavor (a) is about right; the job execution gets truncated and
> the user gets billed for time spent so far.  If we get into fancier
> resources or advance reservation, we might need some additional
> penalty clause to be triggered as in (d).  The general case is (c)
> where another offer/accept cycle can explicitly "ammend" or "obsolete"
> an existing agreement.  I don't know if this should always create a
> new Agreement resource or simply operate on the existing one.
>
> In practice when two people decide to "tear up" a contract they are
> really making a token gesture that destroys some physical records and
> creates a new verbal agreement that they will ammend the old agreement
> as described above in (b)!
>
> What I think all of this gets at is that the Agreement resource
> universe of WS-Agreement is a subset of the "agreement" universe where
> our WS-Agreement parties live.  An Agreement resource MAY be retired
> because its agreement obligations have become historical curiosity.
> The various actions that can cause obligations to become "past tense"
> range from timer expiration, to explicit destroy-resource requests or
> replacement Agreement creation.  When this happens, history is not
> erased but rather system management state is ammended and pertinent
> information is recorded into audit and accounting systems.
>
> Do we need more explicit Agreement content to denote what forms of
> ammendment can (or have) been applied to the obligations of an
> Agreement?  Or can that be implicit in the domain-specific terms?
>
>
> karl
>
> -- 
> Karl Czajkowski
> karlcz at univa.com
>