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

[Toshiyuki Nakata]

HI Dominic:
Thanx for the response.

> 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...

I see. I had been wondering what you meant by "superseded by"..
It might be necessary to have a Notification sent to all the bodies using
the old EPR...

> 
> 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 ------------------
> 
for AI to AR yes, for AR to AI this becomes a bit more complex..
(Please cf. the ppt attached in the Wiki page)

> 
> 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 --------->
> 

I agree that this is more beautiful.
OTOH I think that this raises the issue related to two phase commit protocol
that had been discussed
for a long time and in a heated manner by quite a number of people (before
my time actually) 
and finally got rejected in the original WS-Agreement protocol.

I  am a bit afraid of waking the sleeping monster, but I welcome people's
comments..

Best regards
Toshi

-----
Toshiyuki Nakata 中田　登志之
Executive Chief Engineer, Central Research Lab. NEC
1753, Shimonumabe, Nakahara-Ku,
Kawasaki,Kanagawa 211-8666,Japan
Tel +81-44-431-7653 (NEC Internal 22-60035)
Fax +81-44-431-7609 (NEC Internal 22-60509)
 

> -----Original Message-----
> From: Dominic Battre [mailto:mailinglists at battre.de] 
> Sent: Thursday, August 23, 2007 5:25 PM
> To: Toshiyuki Nakata
> Cc: 'GRAAP-WG'
> Subject: Re: [GRAAP-WG] Modification to the wiki Page on 
> Renegotiating an established Agreement
> 
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4038 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070823/ebcfa662/attachment.bin