On Apr 04, Jon MacLaren loaded a tape reading:

Hi Karl,

Some miscellaneous comments on the revised spec. Comments on symmetry and signed agreements to follow. (I may listen in on the telecon, but I am aware that this will not get round to people in time to be widely read before it happens.)

S1.1.1 - P6 - Composability with negotiation models. I never understood this either. How would you "base" a negotiation protocol which required some sort of lengthy interaction on WS-Agreement? I wondered if this just meant that the document format would be used, and that a different, unrelated messaging protocol would be used. I'd love to see an example of what this means.

I think that is right, at least in the sense that the AgreementFactory messages would not come into play. I do think that an Agreement could appear (or disappear) as a result of this external protocol, so that introspection based on WS-Agreement could happen. Whether this makes sense or not would require a judgement call that is hard to make in the abstract... karl -- Karl Czajkowski karlcz@univa.com

I wondered if this just meant that the document format would be used, and that a different, unrelated messaging protocol would be used. I'd love to see an example of what this means.

Yes, this means that the document format would be used. The original intent of composability with negotiation models was to maintain a separation between the agreement and the way in which you arrived at the agreement. For example: I may run a marketplace or exchange in which providers of services advertise that they have capacity to sell and requestors would submit their capacity requirements. This exchange is similar to an RFQ or reverse auction. In the first round of negotiations, a match-making algorithm would be used to match requestors to providers. In a second stage of negotiation, the requestor and provider may enter a one-on-one negotiation to firm up any agreement details that were not finalized in the first stage. So we wanted the actual agreement to remain independent and composable with any number of negotiation patterns (RFQ, Auction, Reverse Auction, One-On-One, etc.) including multi-stage negotiations that combine different patterns. At least that was the original intent when we wrote that. ;-)

As I said in one of my public comments (which has been decided against) - the document format is useful on its own and should appear in a separate spec.

I really think that there are too many different things for this to be one document.

I agree with you. The agreement document is a valuable artifact all by itself, regardless of whether you use an AgreementFactory or any other means to create it. I also agree that this spec could be multiple specs. For example: The Web Service community might want to use WS-Metadata Exchange to discover agreement templates and not use factories. So discovery of agreements could be a separate spec (or pointer to existing discovery specs). Or for that matter, why are agreement templates special for agreements? They are an expression of service capabilities and are probably more generally applicable as a ?service template? so there is another spec. WS-Agreement certainly does contain several large thoughts (Agreement Document, Agreement Discovery, Agreement Templates, Agreement Protocol, Agreement Monitoring, etc.) we should probably just publish what we have to get a stake in the ground, and pull it apart later as needed. jr Jon MacLaren <maclaren@cct.lsu.edu> Sent by: owner-graap-wg@ggf.org 04/05/2005 12:38 PM To Karl Czajkowski <karlcz@univa.com> cc graap-wg@gridforum.org Subject Re: [graap-wg] updated draft - composability On Apr 5, 2005, at 5:32 AM, Karl Czajkowski wrote:

On Apr 04, Jon MacLaren loaded a tape reading:

...

.... S1.1.1 - P6 - Composability with negotiation models. I never understood this either. How would you "base" a negotiation protocol which required some sort of lengthy interaction on WS-Agreement? I wondered if this just meant that the document format would be used, and that a different, unrelated messaging protocol would be used. I'd love to see an example of what this means.

I think that is right, at least in the sense that the AgreementFactory messages would not come into play. I do think that an Agreement could appear (or disappear) as a result of this external protocol, so that introspection based on WS-Agreement could happen. Whether this makes sense or not would require a judgement call that is hard to make in the abstract...

Ok, so that's not what people mean when they say composability, so this should definitely be clarified in the spec. It's just that someone could "base a negotiation protocol on the WS-Agreement document format". This is a much less bold claim - but it's probably about as far as you can realistically go. As I said in one of my public comments (which has been decided against) - the document format is useful on its own and should appear in a separate spec. I really think that there are too many different things for this to be one document.

karl

-- Karl Czajkowski karlcz@univa.com

Jon.

On Apr 04, Jon MacLaren loaded a tape reading:

Hi Karl,

Comments specifically regarding symmetry. Overall, I think that the spec needs an example working through a case where the initiator is the service provider. I think that there are still gaps in people's understanding about this. Let me know if you need some text - I should be able to find something I've written-up previously about this type of thing.

I agree it needs presentation. One thing though: symmetry in the sense of the initiator-side Agreement facilities is not the same as the "role-reversal" you are describing. We could have a totally asymmetric client-server Agreement where the initiator represents the domain service provider and the responder represents the consumer. We need good terms to distinguish these different ideas...

Section 8 (which I think should be put into Section 3 - the section on how WS-Agreement *works*).

OK, I was trying to get new content down on the page and not worrying so much about position.

In the 2nd paragraph, you say that "the obligations in the agreement are not dependent on the initiator being informed of the decision". If the initiator is the service provider, bidding for work, then this statement cannot be true. You must learn whether your bid has been accepted (and also, presumably, receive/retrieve the precise specification of the work to be done).

We need to resolve this, as it tells me that the role reversal cannot be supported. :-( This text I added was intended to trigger such discussions; it is as explicit of a summary as I could write to capture the results of all those "commitment protocol" discussions we had over the years. As I see it, the initiator (whether a domain specific provider or consumer) must proceed speculatively until he knows for sure. It's the inherent "damned if you do, damned if you don't" hazard of the online binary decision problem; we decided explicitly to always make the initiator the one who "takes the risk" after deciding that role-reversal was equivalent to the more elaborate "solicit/pre-commit/commit" handshake we had before. I do not understand the comment about receiving the "precise specification of the work to be done". If the provider is the initiator, he ALREADY HAS this when he makes the createAgreement or equivalent call. Where he gets it is out of scope, but one assumes it would be from some advertisement system where he saw the "call for bids".

Other symmetry-related comments from earlier in the spec.

S1 - P5 - assumption of roles. I was trying to think of some text to suggest for this. But I think that you are in trouble before you get here. Reading the first couple of paragraphs again, I think that you need to state somewhere in there that the "creational offers" (a phrase which I really don't like!) can be made by either party.

Yes, I think we can work on this more if necessary. You are commenting on text that I haven't modified, right? I'm pretty sure I didn't coin "creational offers". :-)

(Incidentally, I still feel, and always have, that there are obligations on both sides in reality. The consumer is agreeing to consume the service, e.g. provide the work in the case of the job submission example, and also to provide payment of some sort. I note that the specification still views that all obligations are on the side of the service provider.)

I agree with you that there are obligations on both sides, but I do not think the group nor the specification says otherwise. If anything, it just isn't explicit enough yet. So this is a presentation issue, not a debate which needs to be settled...

S3 - P10. The other problem with the diagram is that it completely links the initiator and consumer roles. I agree with the comment about removing the factory - I think that this pattern is often not present.

Jon.

Good point, should it show initiator and responder-side entities with bidirectional arrows? Or do we need an expanding set of diagrams showing different permutations? I think we should stay generic and depend on "primer" work to spell out a dozen use cases. karl -- Karl Czajkowski karlcz@univa.com

One last point... On Apr 5, 2005, at 5:42 AM, Karl Czajkowski wrote:

On Apr 04, Jon MacLaren loaded a tape reading:

...

... (Incidentally, I still feel, and always have, that there are obligations on both sides in reality. The consumer is agreeing to consume the service, e.g. provide the work in the case of the job submission example, and also to provide payment of some sort. I note that the specification still views that all obligations are on the side of the service provider.)

I agree with you that there are obligations on both sides, but I do not think the group nor the specification says otherwise. If anything, it just isn't explicit enough yet. So this is a presentation issue, not a debate which needs to be settled...

What kind of obligations can you have on the initiator side if "the obligations in the agreement are not dependent on the initiator being informed of the decision"? I can't reconcile these two ideas. Jon.

On Apr 5, 2005, at 8:58 PM, Karl Czajkowski wrote:

On Apr 05, Jon MacLaren loaded a tape reading: ...

...

What kind of obligations can you have on the initiator side if "the obligations in the agreement are not dependent on the initiator being informed of the decision"?

I can't reconcile these two ideas.

Jon.

The point is that there is a momentary hazard where the initiator is _possibly_ obligated and does not know whether the Agreement will happen or not. If he is obligated to pay for service, he doesn't know whether he will need to present funds at some point... he might not want to spend them elsewhere, etc.

In many cases, this hazard can be dealt with speculatively: by waiting for the answer. Waiting is not a satisfactory speculative behavior if and only if the Agreement terms include real-time scheduling constraints at the same temporal granularity as the messaging, e.g. if waiting causes a violation.

This is a theoretical corner case, and may not be a practical one if entities are conservative about the kinds of agreements they will negotiate, e.g. not trying to negotiate about services with hard start times that are "too close" to the present.

I agree with this statement. As long as users don't try to agree things in too short a space of time, and as long as providers don't agree to this behaviour, there is no problem. All the more reason, surely, not to chop out large pieces of capability - e.g. the role-reversal case - just for these marginal scenarios!

Another solution might be to deploy WS-Agreement in an environment with better messaging guarantees. If messaging itself were trustworthy, it might make sense for there to be introspective terms in the Agreement that bound the responder's decision time (for example, the responder is in violation if he says "yes" too late). For many best effort cases, the waiting solution can mask this hazard since delay is not a violation for either party.

I really don't know where to go with this discussion. I've been making this point for years too... A phased approach cannot resolve this hazard: someone is always the last to know, and the other party doesn't know if he knows. Pure transactions do not work in this kind of quasi-realtime problem where they cannot be rolled back, i.e. work cannot be undone and resources cannot be unspent. Other compensation actions must be undertaken, e.g. pay a penalty, to offset the costs of the system thrashing and not doing real work.

Well, ultimately, it is for the group of authors to decide. You are the ones doing the writing, and the ones doing the work. I've tried to push a number of ideas into the specification from the position of being a member of the working group, but ultimately, I don't seem to hear anyone else from the group saying "Jon's right about this one." I started reading the spec again when the public comment period came around, because I want whatever the GRAAP working group produces to be as good as it can be. I intended at that time to stick to simple mistakes and inconsistencies, plus a couple of big gripes (e.g. the fact that everything is in one document). Over the last couple of months though, I seem to have been drawn back into these old arguments again. I think it's time for me to just let you get on with it again. Good luck. Jon.

I sympathize with your plight, but in some sense this is exactly what we mean by making it an extension... it is not "in scope" based on the priorities of the group. Does it make sense to provide a normative extension for signature in the basic spec? My feeling is: not unless we can get security people to author it and endorse it so it can be developed concurrently and merged as a small section before the next GGF. Otherwise, I think the best bet is to write a private/community extension and lobby for friendly implementors/users to try it out. This could still happen during the initial wave of experiences with WS-Agreement, and then that experience could feed a small extension specification and/or future revisions of WS-Agreement? karl On Apr 04, Jon MacLaren loaded a tape reading:

Hi Karl,

Last thread, I promise!

On the support for signed agreements, the extensibility point you have provided is sufficient. But, I'm worried that if the only thing in the spec is this extensibility point, then no-one will ever implement the signed agreement stuff. (I note that the signing stuff isn't domain specific; it could be supported regardless of the stuff that is being agreed.)

I'd like to at least see some text showing how this could be supported. Does this belong in the specification, though? Could some words be added to the job submission example in the spec, when it is being revised, stating what might happen with signing?

I just feel that if there's nothing in the spec then I'll be almost back to square one. I won't be able to get any implementation to sign stuff, because the spec doesn't say how this should be done if it is supported. I'll have to go and write a bunch of stuff myself, and won't get any real interoperability.

Jon.

-- Karl Czajkowski karlcz@univa.com

Hi: Karl Czajkowski wrote:

On Apr 05, Toshiyuki Nakata loaded a tape reading:

...

Another tiny question 9.5 Port Type wsag:AgreementState

Is this really Port Type or should it be moved to Resource Property within 9.4 Port Type wsag:Agreement ?

Best Regards

I was hoping someone could explain to me why it was separated. :-) I think that happened during the time I was away from GRAAP-WG last year...

I think a general question is whether PendingAgreement should be an add-on to an Agreement portType and, likewise, whether PendingAgreementFactory should be an add-on to AgreementFactory. If so, I think the shared states should be RPs on Agreement and AgreementFactory, respectively. If not, I think there should be separate AgreementState and AgreementFactoryState RPs that can be included in the RPs for each of the four disjoint portTypes.

I prefer treating the Pending variants as add-ons rather than disjoint options.

Same here.. Remembering that WS and WSRF treat portType names as somewhat

inconsequential, this would show up as "directed" implications that if a particular operation or RP appears, others MUST (or SHOULD?) appear in the port as well.

karl

p.s. was there a call today? I never saw any announcement nor minutes...

there was but lasted for 10 minutes or so. I think Jim is going to post an announcement for meeting on Wednesday.. (evening-night for people in Asia.) Best Regards Toshi.. -- Toshiyuki Nakata t-nakata@cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210)