[Sorry, this bounced the first time I tried to send to the list...] In general I like the approach described in this proposal very much. Since I won't be attending the meeting, I wanted to give a little feedback here... 1. I am not sure I would agree with the claim that the responder role should _always_ be assigned to the "service provider", because the authors' arguments about avoiding denial of service only make sense if you assume service resource scarcity relative to consumer resource availability (assuming that an agreement is always a "trade" or contract of exchange between these two resource types). However, I believe that the entire notion of "provider" and "consumer" in inherently domain-specific, and therefore inseparable from the service term language. So, I might advocate that the existing context fields to associate provider/consumer roles with initiator/responder be dropped, but only because I don't think the core messaging pattern can really say anything about these roles to begin with. I think domain-specific concepts are necessary to really characterize these roles. Thus, I don't think there can be any normative statements in the standard for base agreement nor re-negotiation regarding the use of responder roles with providers or consumers. But, I think it would be fine to have some explanatory text about the various risks of reversing the signalling roles from the "natural" and asymmetric order that would exist in many domains. 2. Has any thought been given to the concrete rendering of this protocol? I immediately have the following ideas upon reading the message definitions: a. RenegotiationQuoteRequest and RenegotiationQuote could be easily mapped to resource property queries with a custom "quote query dialect". This was an expected use of extensibility in WSRF in the past, but I do not know how people view this today. The alternative, of course, is a new operation. Is there any concern about preparation of quotes being a slow or laborious process, and requiring an asynchronous exchange pattern or a resource pattern to allow cancellation of quote requests? b. RenegotationOffer and RenegotiationAccept/RenegotiationReject map easily to the two alternate rendering styles in WS-Agreement: CreateRenegotiatedAgreement (in) and response (out) for synchronous exchanges, in this case merging RenegotiationOfferAck with the accept or reject response; CreatePendingRenegotiatedAgreement (in) and AcceptAgreement/RejectAgreement (also in messages in opposite direction) for asynchronous exchanges, in this case mapping RenegotiationOfferAck to the factory response with the new pending renegotiated agreement; c. RenegotiationNotPossible could be a fault response as described and could also be exposed as a resource property on some agreements? In these renegotiation "factory" patterns, one approach would be to have the renegotiable Agreement resource support these additional patterns, i.e. to act as a factory for its superceding agreement. Or, a shared factory could take the existing agreement EPR as an input parameter. 3. I am assuming from my initial reading that the statement that acceptance of a renegotiation offer invalidates all other outstanding offers is also a point where loose consistency is desired. In other words, it is the responding party (who chooses to accept) who also decides which offers are outstanding and which he hasn't seen yet, in the case that offers are "in flight" and acknowledgements have not been sent. Is this the intention of the authors? If not, then I think some sort of sequence numbering is necessary on offers to help resolve these cases for message loss or delay. 4. I am not sure I follow the purpose of the RenegotiationNotPossible message. Is this a new terminal sub-state for Agreements? Or, can an agreement have this non-renegotiable status at one time but then later be re-negotiable? If the latter, I am not sure the meaning is well captured in the current discussion. It sounds like two different messages: one has the same meaning as a reject message in response to an offer, but with an added hint that other offers will also be rejected, i.e. a transient "don't waste my time right now" message; the other form sounds like just the "don't waste my time right now" advisory without being coupled with a specific offer rejection. Can the authors clarify the intent here? In any case, I am looking forward to seeing more concrete rendering proposals for this protocol extension. karl -- Karl Czajkowski Software Architect Univa UD 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univaud.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software --------------------------------------------------------------------- Notice from Univa UD Postmaster: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This message has been content scanned by the Univa UD Tumbleweed MailGate. ---------------------------------------------------------------------