[GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement

[Dominic Battre]

Hi Toshi,

(I am resending this mail because I used the wrong email address and it
bounced)

> Hi: Dominic：
> Thank you very much for your thoughtful comments.
> I'll just address the first one. For the rest, please give me some
> time.
>
>> ad "New EPR or re-write the current WS-AG document?"
>> during the renegotiation the agreement is in some kind of
>> intermediate change (i.e. it might be in a proposed
>> new status that is not yet accepted by the other party), don't we
>> need a new EPR for that?
>
> The reason that I wanted to re-write the current WS-AG rather than a
> new EPR was that one could never know
> who might be using the old EPR. In a complex scenario like the one I
> mentioned in Business Grid Computing case or
> some  broker case, old EPR might be propagated to other parties who
> would be using it.

For that reason I mentioned the "superseded by" information that could
be added to the context. A third party might need to check whether the
SLA is superseded by another SLA periodically. Kind of ugly...

> So I thought that it would not be realistic to assure that the NEW EPR
> would be propagated to all the
> bodies who might be referring to the old EPR.
>
> On the other hand, re-writing the current WS-AG document kept by the
> Agreement Responder does cause
> a serious race condition when the AR is the requestor for modifying
> the Agreement.
> (ie. it must be re-written only after the AI says he agrees, but
> when?)

oh, does this imply that you want a simple two way communication?

AI ------ 1. please change SLA like this ------> AR
                                           2. AR changes SLA
   <------ 3. confirms change ------------------

or

AI ------ 1. please change SLA like this ------> AR
                                           2. AR rejects change
   <------------- 3. exception ------------------


I am not sure whether this is sufficient. Suppose that the SLA carries a
price tag that needs to be calculated by the AR. I would like to see
some kind of two phase protocol...

AI ------ 1. please change SLA like this ------> AR
                                2. AR decides that it can change SLA
                                3. AR calculates price of modification
   <----------- 4. new offer ------------------
5. AI decides whether change is worth the price
   --------- 6. confirmation/rejection --------->


In my opinion, for negotiation and for renegotiation we need this kind
of request-offer-commit protocol. So it is no easier if the AR initiates
the renegotiation than if the AI initiates the renegotiation. But I
think that we see the same issue there: "What do the resource properties
of the agreement look like if an offer has been sent but not confirmed?"

I agree that creating a new agreement EPR is not very beautiful. Maybe
one could create such an EPR for negotiation until a party commits. At
that time Context, SDTs and GTs are copied to the old agreement.

Best regards,

Dominic