[graap-wg] termination versus determination

[Jon MacLaren]

I didn't catch any previous suggestion that agreements would have no 
end date.  Contracts typically have some sort of end date attached to 
them.  The problem for me is having this "terminate" operation, whose 
semantics are hard to define, for ending things ahead of time.

As you already have a system for creating agreements, making an 
amendment is using a system you've already defined.  Whereas adding a 
"terminate" operation is creating a new mechanism.  It would actually 
be simpler to remove "terminate" from the specification.

I believe that you'll find the "terminate" operation to be quite 
complicated to actually use.  At least if you have a second agreement, 
you have a signed record that this has happened.  (With a "terminate" 
operation, the only records you have are in log files.)  And you'll 
need some sort of amendment system if you want to do re-negotiation 
anyway...


Getting back to Karl's message, I agree that you could find scenarios 
where option a) would work.  (I don't think that it would always work 
in job management, though.  There are probably charging models where 
rolling back is not sufficient, and some other form of compensation is 
required for backing out of the contract.

Also, I agree that there can be meaningful early ways out of a 
contract, but that these should be pre-defined.  Like if I was renting 
an apartment for a year, but there is a clause stating that with 2 
months notice, I can leave during the term of the contract.  You can 
agree this sort of stuff, but it's execution should be out of band in 
terms of the agreement protocol.  It's between the two parties to 
arrange this sort of stuff.  (Of course, this complicates the expiry of 
the agreement resource - maybe you want to keep it around until the 
original end-date in any case.)

Jon.


On Feb 28, 2005, at 11:05 AM, Heiko Ludwig wrote:

>
> Conceptually, I agree with the notion that agreements shouldn't be 
> terminated at all and their useful lifetime as a resource int he WSRF 
> sense ends at some point. The validity of agreements should only be 
> terminated by another agreement. However, this raises 2 pragmatic 
> issues:
>
> 1. Agreements not having a reasonable end date don't quite fit the 
> resource lifecycle model since they, in theory, should be available 
> indefinitely. We have to find a pragmatic way of removing them when 
> they are not useful anymeore, e.g., when one cannot claim service 
> against them etc.
>
> 2. Agreeing to "terminate" (not provide service against it) an 
> agreement using another agreement is quite a bit of overhead. It would 
> be good to have a simple standard means that would shortcut this, such 
> as a "terminte" method. Ths could be optional and rejectable.
>
> Trying to keep things simple,
> Heiko
>
> owner-graap-wg at ggf.org wrote on 02/25/2005 10:54:03 PM:
>
>  > On Feb 25, Jon MacLaren loaded a tape reading:
>  > > 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.
>  > >
>  >
>  > I wonder if (a) can work in certain domains, e.g. job
>  > management. First, I think domain-specific terms could imply the
>  > compensation mechanism and have specialized terms to parameterize 
> any
>  > variants allowed in this domain.  Secondly, I think we have to admit
>  > that existing domains may have the ability to cancel requests while
>  > the entire accounting system is understood out of band.  (I can 
> cancel
>  > a job on any Grid system I know of today, and some _unspecified_
>  > accounting takes place.  We need to support these systems in a
>  > transitional sense; we cannot say "no entry" until each domain has a
>  > rich cost modeling language.)
>  >
>  >
>  > > The way that you "get out" of a contract, is by both parties 
> signing
>  > > some sort of "amendment" to the contract - case c).
>  > >
>  >
>  > Yes, I understand that point... the question is, are these 
> amendments
>  > always WS-Agreements?  Or should we admit the fact that some
>  > (lowercase) agreements are formed by simpler interactions that can
>  > terminate a WS-Agreement?
>  >
>  >
>  > > 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!
>  > >
>  >
>  > When I said "resource" I meant the WS-Resource which is nothing but
>  > abstract document state in my mind.  I did not mean computing 
> resource
>  > etc.  I still think it is appropriate and even desirable to say that
>  > this WS-Agreement resource represents the (lowercase) agreement in a
>  > one-to-one manner.  We can mandate that destruction of the resource
>  > implies "retirement" of the agreement and vice-versa.  What I mean 
> is
>  > that we cannot destroy the management interface used to talk about 
> the
>  > obligations until the obligations are "complete", e.g. historical 
> and
>  > no longer constraining the behavior of the parties in the
>  > (domain-specific) service domain.  Retired doesn't mean forgotten, 
> but
>  > transitioned from this on-line systems management regime to some 
> other
>  > audit, accounting, and reconciliation regime.
>  >
>  > The way I really see it is: the WS-Agreement resource for a 
> particular
>  > domain-specific service captures a limited slice of the operating
>  > policies of the domain-specific service provider and consumer. This 
> is
>  > its primary purpose: to allow automated management of 
> domain-specific
>  > operating policies. As long as there are still dynamically-created
>  > operating policies, the WS-Agreement resource should remain to allow
>  > management of these policies.  As soon as the dynamic policies are
>  > removed, whether by the passing of time or some explicit termination
>  > request, the WS-Agreement resource may be safely eliminated. I think
>  > of the domain-specific operating policies as the first-order
>  > obligations of the agreement parties.
>  >
>  > The WS-Agreement resource also may capture how those operating
>  > policies relate to other domains such as accounting, audit, and
>  > payment.  As we have both said, these second-order obligations 
> cannot
>  > be erased or "managed" in the sense that we would like to manage the
>  > first-order operating policies.  When we drop the first-order rock
>  > into the job pool or take it out again, there are ripples through 
> the
>  > second-order accounting system. We cannot just will the ripples
>  > away. :-)
>  >
>  > Fundamentally I see WS-Agreement as the projection of
>  > systems-management platforms into the multi-agent realm: negotiated
>  > system behavior through automated federation of policies.  The
>  > cost/accounting stuff comes up because it is obviously important to
>  > allow reasoning about alternatives in a multi-agent system.  But
>  > WS-Agreement is not _about_ the accounting stuff; it just has to 
> make
>  > nods to it in order to make systems management tasks feasible in a
>  > decentralized environment. (Ignoring, of course, that a 
> domain-specific
>  > WS-Agreement could be about an accounting system!)
>  >
>  >
>  > > 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?
>  > >
>  >
>  > I don't think we should mix up availability and existence.  An
>  > implementation of WS-Agreement may have better or worse QoS.  We can
>  > still talk about Agreements and hope they (or a good copy) will 
> become
>  > available in the future by the same name.  Destruction/termination
>  > means throwing away the name for the obligations and making them
>  > unmanageable forever.  We should never allow, say, a job to keep
>  > existing in the job system if the WS-Agreement job-submission 
> resource
>  > is terminated.
>  >
>  >
>  > > 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.
>  > >
>  >
>  > There is nothing stopping both parties from requiring WS-Security or
>  > equivalent signed-message mechanisms in the binding layer, and
>  > archiving these messages as their "signed copies".  Perhaps this is 
> a
>  > good argument for leaving the full Agreement document in the
>  > acceptance message?  Otherwise, some sort of out-of-spec "offer 
> hash"
>  > would have to be added to the headers, or a signed RP query of the
>  > agreement would be needed to give the initiator his signature proof.
>  >
>  > Separable from this who-signed-what question is the presentation of
>  > the obligations and service delivery---the on-line management
>  > interface. The current client-server interface is obviously 
> asymmetric
>  > and "unfair" in that it doesn't give the initiator a way to report 
> on
>  > his view of the obligation and performance.
>  >
>  > I would like to see the symmetric (peer-to-peer) protocol variant
>  > corrected both for this "fair presentation" reason and for the more
>  > basic asynchronous signaling benefits.  I think both parties in the
>  > symmetric case would present WS-Agreement resources which represent
>  > the (lowercase) agreement obligations and performance, but each
>  > presenting their own view on it.  This gives you the "he said, she
>  > said" view of the system, but of course 3rd-party monitoring and 
> audit
>  > might always be necessary to get the "actually happened" view.
>  >
>  >
>  > karl
>  >
>  > --
>  > Karl Czajkowski
>  > karlcz at univa.com
>  >