[Sorry for the delay, my first attempt to send this bounced too] Hi Karl, Many thanks for your reply and comments. Please see our responses below. Michael. On 16 Feb 2008, at 06:35, Karl Czajkowski wrote:

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

Yes, we do assume that a contract is formed between the provider and the customer for some exchange, but what that contract is for and what is exchanged is, like contract law, outside the scope of the protocol. We are not claiming that the responder in the re-negotiation protocol should always be the service provider. This is because the service provider can send quote messages to the customer to initiate re- negotiation. As described in the paper, we can map the service provider onto the WS-Agreement "responder" role and we provided this example because of the audience the proposal was intended for, but these two roles are different.

However, I believe that the entire notion of "provider" and "consumer" in inherently domain-specific, and therefore inseparable from the service term language.

We believe the opposite is true: providers or customers can supply and consume anything, and these roles are inherently domain-independent. In short, the messages and the content of those messages (or "service term language") are separable and have to be in order for the protocol to be used across different domains, like the protocol inherent in contract law is.

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.

a) About "the existing context fields". Can you explain what you mean by this as we don't use this phrase in our paper. Do you mean the protocol roles? b) You're right - the protocol cannot and does not say anything about the roles of supplier and customer apart from that they are suppliers and customers of something. c) If you think domain-specific concepts are necessary to characterise these roles, can you give us some examples where you feel this would help?

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.

I'm sorry, I don't understand the argument here. Please can you clarify.

2. Has any thought been given to the concrete rendering of this protocol? I immediately have the following ideas upon reading the message definitions:

By "rendering" do you mean implementation? If so, then yes we have a proof-of-concept implementation. As we wrote in the proposal, we're currently producing a paper on this which will also be circulated to the group.

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?

This is jumping ahead to considering how this can be mapped onto a WS (particularly WSRF) implementation. Our first step is to define and agree on the abstract protocol, then provide a mapping to WS (and other stacks), though, as stated above, we will give an example implementation in a following paper. This is why we give an explanation of the protocol behaviour and not interface definitions, although we included some explanation of how it could be mapped to WS- Agreement because of the audience the proposal was intended for. As I'm sure you're aware, not detailing implementation is common in protocols - for example, see Lamport's description of the Paxos algorithm [1] that doesn't talk at all about actual implementation.

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;

Again, these are considerations for an implementation. However, in the abstract protocol there is nothing to stop the provider sending the RenegotiationOfferAck with the Accept or Reject message. We make the distinction because there may be cases when there will be a delay between the provider sending the acknowledgement and deciding whether it can accept or reject the offer. (Note that his is how Amazon works, they send an email acknowledgement initially but then accept your offer and form the contract when they tell you they're shipping your goods).

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?

Of course, but see the above answers above about not wanting to tie this to any implementation at the moment. </snip>

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?

a) About "the responding party (who chooses to accept)": the service provider (who always chooses to accept an offer) may be the initiator of the re-negotiation as we described above. b) Yes, this is because in contract law the offeree (the service provider) always gets the final say. </snip>

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?

You're right in that RenegotiationNotPossible is a type of advisory message. But, if sent in response to an offer it has the same effect as a Reject message. Re-reading the proposal we agree that this is not captured well and will update the document accordingly. [1] http://pdos.csail.mit.edu/6.824/papers/paxos-simple.pdf