[GRAAP-WG] Modification to the wiki Page on Renegotiatinganestablished Agreement

[Toshiyuki Nakata]

Karl: Thank you very much for your comments 
(and your patience in wating for my reply)

The repli


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

> 
> Toshi, I have the following comments/observations after reviewing your
> wiki page... sorry I have not been able to keep a close watch on the
> recent activities of the group.
> 
> 1. The idea of negotiation of alternatives is difficult and I think
>    requires a better negotiation protocol.

OK

<snip>
> 
>    What I would suggest is that you try to keep this aspect of
>    negotiation protocol orthogonal to the underlying notion of
>    renegotiation.  First, work on the semantics for renegotiation of
>    an agreement as you have done, e.g. replacement/superceding of an
>    agreement.  Then, admit that basic or advanced protocols could be
>    used to negotiate either the initial or subsequent agreement.
> 

I think this is fine as *much* discussion would have to be made for
negotiation of alternatives.

> 
> 2. I think the idea of superceding an agreement is fine, but I have
>    trouble seeing a distinction between this and the general use of
>    agreements in the context of other agreements.  For example, the
>    advance reservation scenario allows "claiming" of a resource
>    reservation, and you can interpret this as adjusting an initial
>    resource agreement to include binding to an application, with the
>    same results as if someone simply negotiated an application with
>    the same QoS terms in one shot...
> 
>    What I would point out is that this claiming/context model allows
>    many:many derivation of agreements in the general case.  E.g. I
>    could reserve a large resource (in space-time) and consume it with
>    multiple applications which either run serially or in parallel.  I
>    could also combine several resources (in separate agreements) into
>    a complex application.  Couldn't a renegotiation also be temporary,
>    e.g. "boost this resource reservation for the next hour, but then
>    fall back to the previous terms"?

Your points are exactly what we had in mind in the business grid project..
(The scenarios are included in HPCC2006 paper
http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0050.pdf 
I've also uploaded an excerpt from the presentation we made onto the Wiki.
The last slide exactly shows the point  I wanted to make.)


> 
>    I am not sure how "supercededby" would be applicable here. 

I think Supercededby could be useful for some purposes.
eg. Logging purposes to show which Agreement had been effective until when
then
Superceded/replaced by which Agreement to check for SLA violation etc.

>    Is it
>    worth having one more general metalanguage for discovery/navigation
>    of agreements which are linked to other agreements?  We could use
>    the extensibility of the wsag:Context to enumerate the actual
>    claimed or superseded agreements, 

 I think this could be one way of realizing this feature.
 (I had intended to put the 'Superceded-by " in the wsag:Context)

> and it seems useful to have a
>    dynamic resource property which could provide reverse-lookup of new
>    agreements which list an agreement in the new wsag:Context too.
> 
> 
> 3. Also, a general concern I have is that the discussions are not
>    crisp about the uses of the agreement.  The talk of race conditions
>    makes me nervous, as it seems to combine denotation of service
>    terms with the implementation of resource managers.  In my view,
>    WS-Agreement is completely focused on the establishment of terms
>    between the two parties, and says nothing about how one of the
>    parties is implementing the protocol. 

I agree that this is a bit of an implementation issue but
I think the discussion we had in Terminating was that Termination could take
a long time to
be decided and we extended the Agreement State wiht such states as
ObservedAndTerminating
so I had wanted to be consistent in this sense.

##As an off track issue,  It seems in creating the official pdf, 
# http://www.ogf.org/documents/GFD.107.pdf

Figure in Section 7.1 got corrupted..  Any way to remedy this?

> 
> 
> 4. The question of having "responder initiated renegotiation" was
>    foreseen in the optional symmetric protocol mode. In essence, if
>    EPRs are exchanged so that both parties have an EPR representing
>    the other party's view of the agreement, then they can switch roles
>    and become initiator for further rounds of communication.  In order
>    to use this feature, one would need to define an extension to the
>    protocol, e.g. have the symmetric agreement resources support an
>    extended protocol which includes the renegotiation operations as
>    well as the basic monitoring/cancellation operations.
> 
>    I think it would be appropriate to define a new negotiation
>    protocol as a profile on this feature, so that a specific SDT would
>    demand the presence of a renegotiation facility which would then be
>    available as extended operations and resource properties on the
>    Agreement resource.
> 
>    Again, if we consider the fuzzy case of many:many renegotiations,
>    the best approach might be a simple RP in the agreement that holds
>    an EPR to the renegotiation service, thereby separating discovery
>    (via lookup of this RP an existing agreement) from claiming/context
>    references which might involve more than one agreement at a time.
> 

This is an interesting (if stagering) point.
I had naively assumed that AR would be maintaining the Agreements
A third party Agreement Factory could solve the problem with No.7 but
this might have quite an impact on other parts of WS-Agreement Spec.

Comments from other people also appreciated.

Best Regards and Thanks
Toshi
> 
> karl
> 
> 
> -- 
> Karl Czajkowski
> Software Architect
> 
> Univa Corporation
> 1001 Warrenville Road, Suite 550
> Lisle, IL 60532
> 
> karlcz at univa.com
> www.univa.com
> ________________________________________________________________
> www.univa.com.
> 
> The Leaders of Open Source Cluster and Grid Software
> 
-------------- 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/20070829/da6be532/attachment.bin