From nakata at mtg.biglobe.ne.jp Sat Apr 2 00:42:02 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Sat, 02 Apr 2005 15:42:02 +0900 Subject: [graap-wg] updated draft In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <424E3EBA.2040908@mtg.biglobe.ne.jp> Hi: I read the updated document ( FYI Netscape doesn't seem to work IE 6.0 does...) I concentrated on the asynchorous part so, my comments opnly apply to the asynchronous part. I think Section 8 8 Acceptance Model really clears up the various scenarios.. My two cents' worth would be to comment on that 9.3 9.3 Port Type wsag:AgreementAcceptance It might be safer to mention that this is a porttype on the Agreement Initiator side.. best Regards Toshi Karl Czajkowski wrote: > Jim has kindly posted version 12 of the draft, including comments and > revisions by me. The comments emphasize my concerns about the existing > presentation and content of some sections. > > The revisions attempt to add the extensibility needed for Jon's > signature problem (without actually defining any signature-related > syntax) and the "async" interfaces. I also removed the Terminate > operation. I am sure there are presentation problems and > inconsistencies, but hopefully this is a more concrete basis for > further discussion of these proposed changes. > > Please ignore the appendix entirely. The main sections are intended > to be normative and the appendix is unknown older content that I did > not touch. > > > karl > > https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en/12 > > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From nakata at mtg.biglobe.ne.jp Sun Apr 3 01:38:35 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Sun, 03 Apr 2005 16:38:35 +0900 Subject: [graap-wg] updated draft In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <424F9D7B.1040405@mtg.biglobe.ne.jp> Hello: Karl Czajkowski wrote: > Jim has kindly posted version 12 of the draft, including comments and > revisions by me. The comments emphasize my concerns about the existing > presentation and content of some sections. > > The revisions attempt to add the extensibility needed for Jon's > signature problem (without actually defining any signature-related > syntax) and the "async" interfaces. I also removed the Terminate > operation. While I do agree that the lifecycle of a generic service agreement could last much longer than the service itself, I am a bit uncomfortable with Agreement as defined in the WS-Agreement would last much longer after the service itself has terminated because of resource problems (like a malloc without explicit free-ing (I am afraid I am used to c-style rather than java style programming..) Would it be possible to specify terminate/expiration of Agreement after the service has finished and leave the rest of the SLA / accounting etc problems to logging services? Best Regards Toshi >I am sure there are presentation problems and > inconsistencies, but hopefully this is a more concrete basis for > further discussion of these proposed changes. > > Please ignore the appendix entirely. The main sections are intended > to be normative and the appendix is unknown older content that I did > not touch. > > > karl > > https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en/12 > > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From t-nakata at cw.jp.nec.com Sun Apr 3 23:59:51 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Mon, 04 Apr 2005 13:59:51 +0900 Subject: [graap-wg] updated draft In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <4250C9C7.8000303@cw.jp.nec.com> I've updated the lists to include Karl's draft as most of what Takuya wanted to address are in Karl's Draft. Best Regards Toshi. PS I'll try to be in today/tomorrow's telecon but have to wake up silently so might not make it. If so, apologies.. Karl Czajkowski wrote: >Jim has kindly posted version 12 of the draft, including comments and >revisions by me. The comments emphasize my concerns about the existing >presentation and content of some sections. > >The revisions attempt to add the extensibility needed for Jon's >signature problem (without actually defining any signature-related >syntax) and the "async" interfaces. I also removed the Terminate >operation. I am sure there are presentation problems and >inconsistencies, but hopefully this is a more concrete basis for >further discussion of these proposed changes. > >Please ignore the appendix entirely. The main sections are intended >to be normative and the appendix is unknown older content that I did >not touch. > > >karl > >https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en/12 > > > > -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050404/7a44744e/attachment.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050404/7a44744e/attachment-0001.htm From maclaren at cct.lsu.edu Mon Apr 4 15:55:46 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 4 Apr 2005 15:55:46 -0500 Subject: [graap-wg] updated draft - misc comments In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <5ff687c7979c35a042827c10d824aea8@cct.lsu.edu> 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. S2.1 P8. I think you could greatly simplify this example by rewriting it to reflect the explanation on the list, i.e. that WS-Agreement can be used as a successor to GRAM, carrying a job description as a payload. The example as currently written has a lot of detail, and is unclear. S3 - P10, 11 Leaving symmetry to one side, I agree with the comments. I think perhaps the whole of S3 could be re-written, and greatly simplified in the process. There are sections, like the one you suggest might be out-of-scope, which can be removed. Jon. On Mar 31, 2005, at 1:23 AM, Karl Czajkowski wrote: > Jim has kindly posted version 12 of the draft, including comments and > revisions by me. The comments emphasize my concerns about the existing > presentation and content of some sections. > > The revisions attempt to add the extensibility needed for Jon's > signature problem (without actually defining any signature-related > syntax) and the "async" interfaces. I also removed the Terminate > operation. I am sure there are presentation problems and > inconsistencies, but hopefully this is a more concrete basis for > further discussion of these proposed changes. > > Please ignore the appendix entirely. The main sections are intended > to be normative and the appendix is unknown older content that I did > not touch. > > > karl > > https://forge.gridforum.org/projects/graap-wg/document/WS- > AgreementSpecificationDraft.doc/en/12 > > > -- > Karl Czajkowski > karlcz at univa.com > From maclaren at cct.lsu.edu Mon Apr 4 16:10:27 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 4 Apr 2005 16:10:27 -0500 Subject: [graap-wg] updated draft - symmetry In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <1855d71061d7e3134d10fe6f1efb5a07@cct.lsu.edu> 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. Section 8 (which I think should be put into Section 3 - the section on how WS-Agreement *works*). 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). 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. (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.) 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. On Mar 31, 2005, at 1:23 AM, Karl Czajkowski wrote: > Jim has kindly posted version 12 of the draft, including comments and > revisions by me. The comments emphasize my concerns about the existing > presentation and content of some sections. > > The revisions attempt to add the extensibility needed for Jon's > signature problem (without actually defining any signature-related > syntax) and the "async" interfaces. I also removed the Terminate > operation. I am sure there are presentation problems and > inconsistencies, but hopefully this is a more concrete basis for > further discussion of these proposed changes. > > Please ignore the appendix entirely. The main sections are intended > to be normative and the appendix is unknown older content that I did > not touch. > > > karl > > https://forge.gridforum.org/projects/graap-wg/document/WS- > AgreementSpecificationDraft.doc/en/12 > > > -- > Karl Czajkowski > karlcz at univa.com > From maclaren at cct.lsu.edu Mon Apr 4 16:28:19 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 4 Apr 2005 16:28:19 -0500 Subject: [graap-wg] updated draft - signed agreements In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <9aef731e6f469b3d6e84e9c7beaaf083@cct.lsu.edu> 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. On Mar 31, 2005, at 1:23 AM, Karl Czajkowski wrote: > Jim has kindly posted version 12 of the draft, including comments and > revisions by me. The comments emphasize my concerns about the existing > presentation and content of some sections. > > The revisions attempt to add the extensibility needed for Jon's > signature problem (without actually defining any signature-related > syntax) and the "async" interfaces. I also removed the Terminate > operation. I am sure there are presentation problems and > inconsistencies, but hopefully this is a more concrete basis for > further discussion of these proposed changes. > > Please ignore the appendix entirely. The main sections are intended > to be normative and the appendix is unknown older content that I did > not touch. > > > karl > > https://forge.gridforum.org/projects/graap-wg/document/WS- > AgreementSpecificationDraft.doc/en/12 > > > -- > Karl Czajkowski > karlcz at univa.com > From nakata at mtg.biglobe.ne.jp Tue Apr 5 03:57:41 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Tue, 05 Apr 2005 17:57:41 +0900 Subject: [graap-wg] updated draft In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <42525305.7090804@mtg.biglobe.ne.jp> Hello: One minor editorial issue is that 9.2.2 Resource Property wsag:Template has been pushed to a part of 9.2 Port Type wsag:PendingAgreementFactory But I think this also applies to, 9.1 Port Type wsag:AgreementFactory as well. Is there any way to merge the two port types? Best Regards Toshi Karl Czajkowski wrote: > Jim has kindly posted version 12 of the draft, including comments and > revisions by me. The comments emphasize my concerns about the existing > presentation and content of some sections. > > The revisions attempt to add the extensibility needed for Jon's > signature problem (without actually defining any signature-related > syntax) and the "async" interfaces. I also removed the Terminate > operation. I am sure there are presentation problems and > inconsistencies, but hopefully this is a more concrete basis for > further discussion of these proposed changes. > > Please ignore the appendix entirely. The main sections are intended > to be normative and the appendix is unknown older content that I did > not touch. > > > karl > > https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en/12 > > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From nakata at mtg.biglobe.ne.jp Tue Apr 5 04:08:46 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Tue, 05 Apr 2005 18:08:46 +0900 Subject: [graap-wg] updated draft In-Reply-To: <20050331072305.GE19228@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> Message-ID: <4252559E.5040108@mtg.biglobe.ne.jp> 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 Karl Czajkowski wrote: > Jim has kindly posted version 12 of the draft, including comments and > revisions by me. The comments emphasize my concerns about the existing > presentation and content of some sections. > > The revisions attempt to add the extensibility needed for Jon's > signature problem (without actually defining any signature-related > syntax) and the "async" interfaces. I also removed the Terminate > operation. I am sure there are presentation problems and > inconsistencies, but hopefully this is a more concrete basis for > further discussion of these proposed changes. > > Please ignore the appendix entirely. The main sections are intended > to be normative and the appendix is unknown older content that I did > not touch. > > > karl > > https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en/12 > > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From karlcz at univa.com Tue Apr 5 04:54:29 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 5 Apr 2005 16:54:29 +0700 Subject: [graap-wg] updated draft In-Reply-To: <4252559E.5040108@mtg.biglobe.ne.jp> References: <20050331072305.GE19228@moraine.localdomain> <4252559E.5040108@mtg.biglobe.ne.jp> Message-ID: <20050405095426.GA22126@moraine.localdomain> 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. 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... -- Karl Czajkowski karlcz at univa.com From nakata at mtg.biglobe.ne.jp Tue Apr 5 05:16:02 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Tue, 05 Apr 2005 19:16:02 +0900 Subject: [graap-wg] updated draft In-Reply-To: <20050405095426.GA22126@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> <4252559E.5040108@mtg.biglobe.ne.jp> <20050405095426.GA22126@moraine.localdomain> Message-ID: <42526562.2040705@mtg.biglobe.ne.jp> 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 at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From karlcz at univa.com Tue Apr 5 05:32:22 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 5 Apr 2005 17:32:22 +0700 Subject: [graap-wg] updated draft - composability In-Reply-To: <5ff687c7979c35a042827c10d824aea8@cct.lsu.edu> References: <20050331072305.GE19228@moraine.localdomain> <5ff687c7979c35a042827c10d824aea8@cct.lsu.edu> Message-ID: <20050405103222.GD22126@moraine.localdomain> 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 at univa.com From karlcz at univa.com Tue Apr 5 05:42:45 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 5 Apr 2005 17:42:45 +0700 Subject: [graap-wg] updated draft - symmetry In-Reply-To: <1855d71061d7e3134d10fe6f1efb5a07@cct.lsu.edu> References: <20050331072305.GE19228@moraine.localdomain> <1855d71061d7e3134d10fe6f1efb5a07@cct.lsu.edu> Message-ID: <20050405104245.GE22126@moraine.localdomain> 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 at univa.com From karlcz at univa.com Tue Apr 5 05:46:44 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 5 Apr 2005 17:46:44 +0700 Subject: [graap-wg] updated draft - signed agreements In-Reply-To: <9aef731e6f469b3d6e84e9c7beaaf083@cct.lsu.edu> References: <20050331072305.GE19228@moraine.localdomain> <9aef731e6f469b3d6e84e9c7beaaf083@cct.lsu.edu> Message-ID: <20050405104644.GF22126@moraine.localdomain> 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 at univa.com From maclaren at cct.lsu.edu Tue Apr 5 11:38:06 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Tue, 5 Apr 2005 11:38:06 -0500 Subject: [graap-wg] updated draft - composability In-Reply-To: <20050405103222.GD22126@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> <5ff687c7979c35a042827c10d824aea8@cct.lsu.edu> <20050405103222.GD22126@moraine.localdomain> Message-ID: 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 at univa.com Jon. From maclaren at cct.lsu.edu Tue Apr 5 14:21:03 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Tue, 5 Apr 2005 14:21:03 -0500 Subject: [graap-wg] updated draft - symmetry In-Reply-To: <20050405104245.GE22126@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> <1855d71061d7e3134d10fe6f1efb5a07@cct.lsu.edu> <20050405104245.GE22126@moraine.localdomain> Message-ID: On Apr 5, 2005, at 5:42 AM, Karl Czajkowski wrote: > 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... I mentioned symmetry issues to the group a couple of years ago, and I meant that it should be possible to have provider-initiated agreements as well as consumer-initiated. So I can claim first use of symmetry within the GRAAP context, if that counts. (I don't suppose it does.) All my comments were supposed to be about this, and not the initiator-side Agreement stuff (which I didn't read). I hope everyone can read them as such. > >> 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. Yeah - it was just a suggestion for later on. >> 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. :-( Well, I've explained a number of times (a long time ago) why I think that this is important. I don't know if it's important to anyone else, though. Does someone else want to say something here? > 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". Yes - that's fine if the entire job description is what is bidded against, and it probably would be. If you try to follow your suggested semantics, with the obligations being independent of the initiator being informed, then I suppose that in the absence of a decision, the bidder could speculatively continue, and start executing the job. They could then discover the result later. But I don't think it makes sense to do so. I think perhaps that this is a consequence of the lack of phased commit in the protocol. You don't have the idea of a consensus being arrived at between the two parties. I'm not convinced that there's any benefit in adopting the semantics you propose. And I'll be really interested to see if it turns out to be suitable for co-scheduling. > .... > 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. I don't have any useful suggestions here, other than to state that, if you're going to support the "role-reversal" case, the diagram is not generic as it stands. And I'd feel a lot happier about the primer answer if this actually existed. There's been stuff heading for the primer for two years now. I hope someone's been writing it down. > > karl > > -- > Karl Czajkowski > karlcz at univa.com Jon. From maclaren at cct.lsu.edu Tue Apr 5 14:35:42 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Tue, 5 Apr 2005 14:35:42 -0500 Subject: [graap-wg] updated draft - symmetry In-Reply-To: <20050405104245.GE22126@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> <1855d71061d7e3134d10fe6f1efb5a07@cct.lsu.edu> <20050405104245.GE22126@moraine.localdomain> Message-ID: <148ba27c4d7d9b22dd4d0191f8013f56@cct.lsu.edu> 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. From pruyne at hpl.hp.com Tue Apr 5 14:40:07 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Tue, 05 Apr 2005 14:40:07 -0500 Subject: [graap-wg] re-scheduled telecon Message-ID: <4252E997.8030201@hpl.hp.com> All, Due to my inability to coordinate things on Mon., we've re-scheduled the graap telecon this week for 10:00 AM, Central time on Wed. 4/6. The dial-in numbers will be the same. This may be a better time in general for people, so this could be a new standing time if all agree to it. Also note that the US has changed to daylight savings time, so that starting time is GMT-0600. In details: Start Time: 10:00 AM Central US 11:00 AM Eastern US 8:00 AM Pacific US 1700 Germany 1600 UK Midnight Japan Dial in numbers: 866-673-8466 or 702-477-6031 code 8578310. --- Jim From karlcz at univa.com Tue Apr 5 20:58:21 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 6 Apr 2005 08:58:21 +0700 Subject: [graap-wg] updated draft - symmetry In-Reply-To: <148ba27c4d7d9b22dd4d0191f8013f56@cct.lsu.edu> References: <20050331072305.GE19228@moraine.localdomain> <1855d71061d7e3134d10fe6f1efb5a07@cct.lsu.edu> <20050405104245.GE22126@moraine.localdomain> <148ba27c4d7d9b22dd4d0191f8013f56@cct.lsu.edu> Message-ID: <20050406015821.GA25224@moraine.localdomain> 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. 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. karl -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Wed Apr 6 10:26:37 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Wed, 6 Apr 2005 10:26:37 -0500 Subject: [graap-wg] updated draft - symmetry In-Reply-To: <20050406015821.GA25224@moraine.localdomain> References: <20050331072305.GE19228@moraine.localdomain> <1855d71061d7e3134d10fe6f1efb5a07@cct.lsu.edu> <20050405104245.GE22126@moraine.localdomain> <148ba27c4d7d9b22dd4d0191f8013f56@cct.lsu.edu> <20050406015821.GA25224@moraine.localdomain> Message-ID: <4a0fd8fcb904e4f7a9818b98b273e6e7@cct.lsu.edu> 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. From rofrano at us.ibm.com Wed Apr 6 10:07:06 2005 From: rofrano at us.ibm.com (John Rofrano) Date: Wed, 6 Apr 2005 11:07:06 -0400 Subject: [graap-wg] updated draft - composability In-Reply-To: Message-ID: > 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 Sent by: owner-graap-wg at ggf.org 04/05/2005 12:38 PM To Karl Czajkowski cc graap-wg at 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 at univa.com Jon. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050406/9f2b077c/attachment.html From pruyne at hpl.hp.com Wed Apr 6 11:09:27 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 06 Apr 2005 11:09:27 -0500 Subject: [graap-wg] minutes from Apr. 6 telecon. Message-ID: <425409B7.4040006@hpl.hp.com> Are attached. We will continue to meet at the time used today which is, briefly, Wed. 10:00 AM Central time US. Reminders to follow. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr0605-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050406/4e5baf84/attachment.txt From t-nakata at cw.jp.nec.com Wed Apr 6 20:12:42 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 07 Apr 2005 10:12:42 +0900 Subject: [graap-wg] minutes from Apr. 6 telecon. In-Reply-To: <425409B7.4040006@hpl.hp.com> References: <425409B7.4040006@hpl.hp.com> Message-ID: <4254890A.5050005@cw.jp.nec.com> Usual list attached. (Might make a diff of Commentslist and Toberesolved as resolved list.) Also, Apologies for the noise on the phone. IP traffic seems to be much higher at that time frame. I 'll probably resort to conventional phone from next week. (Should make some phone companies happy :-)) Jim Pruyne wrote: > Are attached. We will continue to meet at the time used today which > is, briefly, Wed. 10:00 AM Central time US. Reminders to follow. > > --- Jim > Best Regards Toshi -- We have moved to a new Office!! Toshiyuki Nakata ?????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050407/09071170/attachment.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050407/09071170/attachment-0001.htm From pruyne at hpl.hp.com Wed Apr 13 01:54:07 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 13 Apr 2005 01:54:07 -0500 Subject: [graap-wg] telecon reminder Message-ID: <425CC20F.9020708@hpl.hp.com> All, We will have a telecon. on Wed. morning/evening at our new time. Dial-in numbers will be the same. The time is: 10:00AM Central Time US (GMT-0600) which should be: 11:00AM Eastern Time US 1600 UK 1700 Germany midnight Japan 2200 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. --- Jim From pruyne at hpl.hp.com Wed Apr 13 11:21:46 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 13 Apr 2005 11:21:46 -0500 Subject: [graap-wg] minutes from telecon on 4/13/05 Message-ID: <425D471A.6010107@hpl.hp.com> They are attached. We'll continue the current meeting times. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr1305-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050413/86e6add7/attachment.txt From nakata at mtg.biglobe.ne.jp Tue Apr 19 07:05:19 2005 From: nakata at mtg.biglobe.ne.jp (nakata) Date: Tue, 19 Apr 2005 21:05:19 +0900 Subject: [graap-wg] minutes from telecon on 4/13/05 In-Reply-To: <425D471A.6010107@hpl.hp.com> References: <425D471A.6010107@hpl.hp.com> Message-ID: <4264F3FF.4060803@mtg.biglobe.ne.jp> UsualList Attached. Best Regards Toshi Jim Pruyne wrote: > They are attached. We'll continue the current meeting times. > > --- Jim > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050419/479eef69/attachment.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050419/479eef69/attachment-0001.htm From pruyne at hpl.hp.com Tue Apr 19 23:48:59 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Tue, 19 Apr 2005 23:48:59 -0500 Subject: [graap-wg] telecon reminder Message-ID: <4265DF3B.6060703@hpl.hp.com> All, As has become usual, we'll have our telecon tomorrow, Wed., 4/20 at the usual times and phone numbers: Start Time: 10:00 AM Central US 11:00 AM Eastern US 8:00 AM Pacific US 1700 Germany 1600 UK Midnight Japan Dial in numbers: 866-673-8466 or 702-477-6031 code 8578310. --- Jim From pruyne at hpl.hp.com Wed Apr 20 10:59:37 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 20 Apr 2005 10:59:37 -0500 Subject: [graap-wg] minutes from Apr. 20 telecon Message-ID: <42667C69.2040406@hpl.hp.com> They are attached. We plan to meet at the same time next week. Reminder to follow. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr2005-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050420/017f9563/attachment.txt From hludwig at us.ibm.com Wed Apr 20 10:05:15 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Wed, 20 Apr 2005 11:05:15 -0400 Subject: Fw: [graap-wg] minutes from telecon on 4/13/05 Message-ID: ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 236 9453 http://www.research.ibm.com/people/h/hludwig/ ----- Forwarded by Heiko Ludwig/Watson/IBM on 04/20/2005 11:04 AM ----- Heiko Ludwig/Watson/IBM 04/20/2005 10:13 AM To Jim Pruyne cc Asit Dan/Watson/IBM, John Rofrano/Thornwood/IBM Subject Re: [graap-wg] minutes from telecon on 4/13/05 Jim, I updated the draft as per our discussion last week. I didn't find a proper way to add a document to the GridForge that supercedes the current draft. Hence, I send it to you for you have the authorization as an admin. Since the call is near, we also might just want to send it to the mailing list. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 236 9453 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne Sent by: owner-graap-wg at ggf.org 04/13/2005 12:21 PM To GRAAP-WG cc Subject [graap-wg] minutes from telecon on 4/13/05 They are attached. We'll continue the current meeting times. --- Jim Minutes from Apr. 13 '05 Telecon Attendees --------- Jim Pruyne Heiko Ludwig Karl Czajkowski Wolfgang Zeigler Asit Dan Agenda ------ - What's up with the Author's list? Jim's not comfortable removing names without their consent, and he hasn't gotten consent from people when he's asked. - Summary of updates from Heiko's revision - Change to Penalty to contain an unbounded list of (Assesment Interval, value unit, value expr.) tuples. Proposed to just change so that we can have an unbounded number of Penalty clauses in the BusinessValueList **Action: Do this in the spec. Heiko will do this, and apply to Reward, etc. - Discussion of comment 29: Are the value terms really appropriate here, or does this need to be addressed someplace else? **Action: Response is that there is nothing else today, so this is an approach we suggest. This specification can considered optional in the sense that one need not include guarantee terms at all, but is useful in some domains we've looked at. In 4.2.5.1, we need to be clear on what parts are extensible to support this position. - Does this all lead to the need for extensible term types? E.g. an "option" as suggested by Heiko. It seems that there may be terms beyond the description (functional) and guarantee (non-functional) terms that we have now. Agreed that we should allow for extension of new term types. **Action: update section 4.2 to make the definition of new term types possible, and update the pseudo-schema in 4.2.1, and introduce a new-subsection before the compositor definition. *Comment: Use of xsd:anyother is a useful construct to specify that one can extend, but must use another namespace outside our own. *Comment: How do we make it clear in the pseudo-schema where extensibility is possible, and can we summarize somewhere all of the extensibility points. *Comment: Should we try to do some re-structuring to avoid the high-level of nesting that we have now (e.g. 5-levels of section numbering) **Action: Karl to do a re-write on 2.1 on motivating example on Job Submission, but it needs to stay up-to-date wrt later sections and examples in appendicies. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050420/bdef37c8/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: WS-AgreementSpecificationDraft-V-4-20-05.doc.doc Type: application/octet-stream Size: 793088 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050420/bdef37c8/attachment.obj From nakata at mtg.biglobe.ne.jp Fri Apr 22 11:12:01 2005 From: nakata at mtg.biglobe.ne.jp (nakata) Date: Sat, 23 Apr 2005 01:12:01 +0900 Subject: [graap-wg] Usual Comment list for 20th April In-Reply-To: <42667C69.2040406@hpl.hp.com> References: <42667C69.2040406@hpl.hp.com> Message-ID: <42692251.1000407@mtg.biglobe.ne.jp> Are attached. Thanks to Jim's advice added a column with the links to the actual comments. for To be resolved matters.. (Tested on IE6 and Netscape 7.1 only..) If there are any mistakes please tell me. Best Regards Toshi Jim Pruyne wrote: > They are attached. We plan to meet at the same time next week. > Reminder to follow. > > --- Jim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050423/ccf49c6d/attachment.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050423/ccf49c6d/attachment-0001.htm From karlcz at univa.com Mon Apr 25 01:10:06 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 25 Apr 2005 13:10:06 +0700 Subject: [graap-wg] Templates too restrictive? Message-ID: <20050425061006.GE18551@moraine.localdomain> I am confused by the template mechanism in the draft. The normative text seems inconsistent w/ the Job example and nothing is very clear to me. 1) Is there a way to express schema-like constraints on the presence or absence of Terms? The main text made me think that a domain-specific term must appear in the Terms section of the template and then be qualified if necessary by CreationConstraints. Must the offer Terms appear with the same document structure (including document-order) as the template Terms element? What about optional fields or fields with variable cardinality? The job template example in the appendix shows an empty Terms element in the template and then has CreationConstraints/Item elements which make XPath references as //ServiceDescriptionTerm/someJobThing! This makes no sense to me, first because the references do not match anything in the template and second because they are not even rooted in the template or Terms elements, so the structure is underconstrained if it is meant to imply the presence of such terms. Shouldn't we require a wrapping element around XPath expressions to indicate how they are interpreted against template or offer documents? 2) What is the matching rule for template content to determine if an offer or agreement is consistent with a template? Must all of the CreationConstraints/Item elements be able to reference a structure in the offer? Must a structure satisfy all content restrictions which reference it? Isn't the spec odd in stating that offers MUST match and providers MUST reject non-matching offers when the matching semantics are not really well-defined? Shouldn't this all be treated as hints anyway, with freedom for both parties to offer and/or accept non-matching agreements if they like? 3) Shouldn't CreationConstraints/Constraint have open content? It seems like this is a hold-over from when we were trying to handle extensibility through schema extension. The specification text says it is am empty element which must be extended. Shouldn't it be a non-derivable type w/ xsd:any##other child? 4) What are the rule for using templates? MUST an offer be based on a template? MUST a provider publish templates at all? SHOULD the provider use the optional Template/Name field? 5) Should the base specification include template syntax to describe compositions of terms? It seems like there should be a way to express compositions of terms without having to enumerate specific composition instances as separate templates. Unless I have misunderstood the generality of the existing syntax, do we need a new form of template or some other extensibility hook to allow more general templates? Should the overall template handling rules be liberalized to either have a wildcard template or an understanding that domain-specific template mechanisms may be in place which capture complex or precise templating scenarios which cannot be adequately projected into the basic template syntax? 6) Should we drop templates from the first version? If the above questions cannot be answered and addressed shortly, is it better to produce a standard w/o templates or to delay until we can solve these problems? What is the use case requirement for determining of the spec mechanism is good enough to publish? I am not confident that we really know how to, for example, express constraints against a single complex JSDL service description term with its optional parts. karl -- Karl Czajkowski karlcz at univa.com From nakata at mtg.biglobe.ne.jp Mon Apr 25 01:43:23 2005 From: nakata at mtg.biglobe.ne.jp (nakata) Date: Mon, 25 Apr 2005 15:43:23 +0900 Subject: [graap-wg] Templates too restrictive? In-Reply-To: <20050425061006.GE18551@moraine.localdomain> References: <20050425061006.GE18551@moraine.localdomain> Message-ID: <426C918B.2070601@mtg.biglobe.ne.jp> Hello:I also have had many questions from people considering implementing WS-Agreement on the templates. I had not realized that there were so many issues, but if it is as Karl says, I would opt for 6) even if it means inter-operability issues might become a bit vague.. Toshi Karl Czajkowski wrote: >I am confused by the template mechanism in the draft. The normative >text seems inconsistent w/ the Job example and nothing is very clear >to me. > >1) Is there a way to express schema-like constraints on the presence > or absence of Terms? > > The main text made me think that a domain-specific term must appear > in the Terms section of the template and then be qualified if > necessary by CreationConstraints. Must the offer Terms appear with > the same document structure (including document-order) as the > template Terms element? What about optional fields or fields with > variable cardinality? > > The job template example in the appendix shows an empty Terms > element in the template and then has CreationConstraints/Item > elements which make XPath references as > //ServiceDescriptionTerm/someJobThing! This makes no sense to me, > first because the references do not match anything in the template > and second because they are not even rooted in the template or > Terms elements, so the structure is underconstrained if it is meant > to imply the presence of such terms. Shouldn't we require a > wrapping element around XPath expressions to indicate how they are > interpreted against template or offer documents? > >2) What is the matching rule for template content to determine if an > offer or agreement is consistent with a template? > > Must all of the CreationConstraints/Item elements be able to > reference a structure in the offer? Must a structure satisfy all > content restrictions which reference it? > > Isn't the spec odd in stating that offers MUST match and providers > MUST reject non-matching offers when the matching semantics are not > really well-defined? Shouldn't this all be treated as hints > anyway, with freedom for both parties to offer and/or accept > non-matching agreements if they like? > >3) Shouldn't CreationConstraints/Constraint have open content? > > It seems like this is a hold-over from when we were trying to > handle extensibility through schema extension. The specification > text says it is am empty element which must be extended. Shouldn't > it be a non-derivable type w/ xsd:any##other child? > >4) What are the rule for using templates? > > MUST an offer be based on a template? MUST a provider publish > templates at all? SHOULD the provider use the optional > Template/Name field? > >5) Should the base specification include template syntax to describe > compositions of terms? > > It seems like there should be a way to express compositions of > terms without having to enumerate specific composition instances as > separate templates. Unless I have misunderstood the generality of > the existing syntax, do we need a new form of template or some > other extensibility hook to allow more general templates? > > Should the overall template handling rules be liberalized to either > have a wildcard template or an understanding that domain-specific > template mechanisms may be in place which capture complex or > precise templating scenarios which cannot be adequately projected > into the basic template syntax? > >6) Should we drop templates from the first version? > > If the above questions cannot be answered and addressed shortly, is > it better to produce a standard w/o templates or to delay until we > can solve these problems? What is the use case requirement for > determining of the spec mechanism is good enough to publish? I am > not confident that we really know how to, for example, express > constraints against a single complex JSDL service description term > with its optional parts. > > >karl > > > From pruyne at hpl.hp.com Wed Apr 27 01:25:22 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 27 Apr 2005 01:25:22 -0500 Subject: [graap-wg] 4/27 telecon reminder Message-ID: <426F3052.9000107@hpl.hp.com> All, We will have a telecon. on Wed. morning/evening at our usual time. Dial-in numbers will be the same. The time is: 10:00AM Central Time US (GMT-0600) which should be: 11:00AM Eastern Time US 1600 UK 1700 Germany midnight Japan 2200 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. --- Jim From pruyne at hpl.hp.com Wed Apr 27 12:27:35 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 27 Apr 2005 12:27:35 -0500 Subject: [graap-wg] minutes from 4/27 telecon Message-ID: <426FCB87.1020001@hpl.hp.com> They are attached. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Apr2705-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050427/dd468095/attachment.txt From hludwig at us.ibm.com Thu Apr 28 14:13:42 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Thu, 28 Apr 2005 15:13:42 -0400 Subject: [graap-wg] Templates too restrictive? In-Reply-To: <20050425061006.GE18551@moraine.localdomain> Message-ID: Comments inline. Heiko owner-graap-wg at ggf.org wrote on 04/25/2005 02:10:06 AM: > I am confused by the template mechanism in the draft. The normative > text seems inconsistent w/ the Job example and nothing is very clear > to me. > > 1) Is there a way to express schema-like constraints on the presence > or absence of Terms? > > The main text made me think that a domain-specific term must appear > in the Terms section of the template and then be qualified if > necessary by CreationConstraints. Must the offer Terms appear with > the same document structure (including document-order) as the > template Terms element? What about optional fields or fields with > variable cardinality? > > The job template example in the appendix shows an empty Terms > element in the template and then has CreationConstraints/Item > elements which make XPath references as > //ServiceDescriptionTerm/someJobThing! This makes no sense to me, > first because the references do not match anything in the template > and second because they are not even rooted in the template or > Terms elements, so the structure is underconstrained if it is meant > to imply the presence of such terms. Shouldn't we require a > wrapping element around XPath expressions to indicate how they are > interpreted against template or offer documents? I guess the example templates in the fall draft are all incomplete, hence difficult to assess. I don't understand what you mean with the "wrapping element". XPath has this selection expression that hopefully matches one or more parts of the name, context or terms section, which are supposed to be present in the template. Agreement clients can then fill in any structure compliant with constraints. > > 2) What is the matching rule for template content to determine if an > offer or agreement is consistent with a template? > > Must all of the CreationConstraints/Item elements be able to > reference a structure in the offer? Must a structure satisfy all > content restrictions which reference it? > > Isn't the spec odd in stating that offers MUST match and providers > MUST reject non-matching offers when the matching semantics are not > really well-defined? Shouldn't this all be treated as hints > anyway, with freedom for both parties to offer and/or accept > non-matching agreements if they like? Agreed. In a no tso loosely couple scenario, one might not want to publish templates because, e.g., just one integer value is variable and the client creates agreement offers just by string concatenation. I propose to delete the requirement on template compliance, probably the whole section. > 3) Shouldn't CreationConstraints/Constraint have open content? > > It seems like this is a hold-over from when we were trying to > handle extensibility through schema extension. The specification > text says it is am empty element which must be extended. Shouldn't > it be a non-derivable type w/ xsd:any##other child? ok > 4) What are the rule for using templates? > > MUST an offer be based on a template? MUST a provider publish > templates at all? SHOULD the provider use the optional > Template/Name field? As discussed above, no, from a spec point of view. In reality, one would probably mostly use it to come up with agreement offers that both parties can understand. > 5) Should the base specification include template syntax to describe > compositions of terms? > > It seems like there should be a way to express compositions of > terms without having to enumerate specific composition instances as > separate templates. Unless I have misunderstood the generality of > the existing syntax, do we need a new form of template or some > other extensibility hook to allow more general templates? > > Should the overall template handling rules be liberalized to either > have a wildcard template or an understanding that domain-specific > template mechanisms may be in place which capture complex or > precise templating scenarios which cannot be adequately projected > into the basic template syntax? I didn't quite understand you issue. Related to this: We might want to introduce a description of alternatives of terms that apply in the constraint section, probably also using the WS-Policy compositors. > 6) Should we drop templates from the first version? > > If the above questions cannot be answered and addressed shortly, is > it better to produce a standard w/o templates or to delay until we > can solve these problems? What is the use case requirement for > determining of the spec mechanism is good enough to publish? I am > not confident that we really know how to, for example, express > constraints against a single complex JSDL service description term > with its optional parts. Absolutely not. I think they are central to most but not the most trivial scenarios. And actually, we are not in such a bad shape and they work well, according to our experience. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050428/3fe58f13/attachment.html From karlcz at univa.com Thu Apr 28 21:02:44 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Fri, 29 Apr 2005 09:02:44 +0700 Subject: [graap-wg] Templates too restrictive? In-Reply-To: References: <20050425061006.GE18551@moraine.localdomain> Message-ID: <20050429020244.GA16201@moraine.localdomain> On Apr 28, Heiko Ludwig loaded a tape reading: > > I guess the example templates in the fall draft are all incomplete, > hence difficult to assess. I don't understand what you mean with the > "wrapping element". XPath has this selection expression that hopefully > matches one or more parts of the name, context or terms section, which > are supposed to be present in the template. Agreement clients can then > fill in any structure compliant with constraints. > Let me try to rephrase my question as two separate questions. First, regarding XPath, I may not be good enough with it to be understanding the examples. Are XPath expressions always "rooted" or can they match arbitrary sub-structures (analogous to anchored versus non-anchored regular expression matching)? I am guessing from your comment that they are unanchored. If they can be anchored, do we say something strong enough about what the root is for anchored matches, e.g. that it is rooted at the wsag:template element or at the client's corresponding wsag:offer element? My other question about structural constraints was echoed in multiple questions but not directly enough to be clear. I had always expected (and intented, in my early contributions to this spec) that templates were going to be the mechanism to "rescue" us from the open content model. However, I do not see how this is the case at all. I would like to be able to: A. Restrict the domain-specific service description term type(s) which MAY appear in an offer from the provider's point of view. B. Restrict the nesting/composition of service description terms, e.g. limit the form of logical compositions the provider will process. Maybe this is coupled with (A) in a syntax language or with your proposal below about using compositors in templates? C. Restrict the nesting/composition of open content extensions which MAY appear in any particular service description term open content "slot". D. Express dependencies/implications such as if X appears, then so MUST Y. E. Cover variable-cardinality scenarios for the above. At present, I do not understand which of these (or other) purposes is being addressed by the agreement syntax in the template nor by the constraints syntax. If a term shows up in the agreement syntax part, MUST that term show up in offers based on the template? MAY more than one instance of the term show up? MAY other terms show up which are not listed here? Can constraints using xsd:restriction express restrictions on the nested element structure, or just on simple type fields? If xsd:restriction is powerful enough, is that a good idea? MUST there be a structure in the offer that matches each constraint in the template? Or MAY completely unconstrained structures appear? This is what I meant before by what is the matching rule. A much more complete semantics must be provided, e.g. turn the template into a logical constraint system which is applied to an offer to see if it "satisfies" the template or not. > I didn't quite understand you issue. Related to this: We might want to > introduce a description of alternatives of terms that apply in the > constraint section, probably also using the WS-Policy compositors. > I would like to hear more about this to understand what you are proposing and how it fits in w/ the above questions. > Absolutely not. I think they are central to most but not the most > trivial scenarios. And actually, we are not in such a bad shape and > they work well, according to our experience. I agree they are important. I was only trying to be fair and admit that I do not quite understand the scope of what is "there" nor the magnitude of the can of worms I am opening. :-) I do think we need to make drastic repairs to the presentation even if the current technical solution is adequate. I find it worrisome if I cannot figure out what the spec is actually saying, since I thought I understood the template problem before! Another concern for me is that there needs to be tractable ways to normalize or query templates. For this stuff to really fly, we need to assume a discovery system will aggregate templates from many different providers and provide a meaningful and efficient way for a prospective client to search for templates that have the right structural properties! There is a tension and the offer/template model needs to "recurse" so to speak and not just end up with an "insert oracle here" layer in the architecture. karl -- Karl Czajkowski karlcz at univa.com