The core idea of the negotiation is to have each party modify the previous answer received from the other party. The client sends a need description, and the provider sends back a quote (a description of a resource set), hopefully related to the need expressed. The provider's reply is a modification of the user's request based on the current situation (resource availability, pricing strategy, etc). The user is free then to reexpress his need (this situation can lead to a long-going loop), or choose the provider's offer as the basis for the SLA he'll be submitting. The provider is always sending back something he hopes to be able to fulfill (if no concurrent negotiation is faster).

The negotiation phase takes place after the user’s discovery phase, once the user has selected a provider who is advertised as having the needed resources, and before the actual job submission. The negotation’s focus is only on agreeing the conditions (QoS, price, time-frame,etc) of the SLA.

In the first call “getTemplate”, an optional parameter can be passed. This parameter is a "reference_template" parameter, which may be ignored, but is meant to provide more information to the Provider, in order to propose a template that is more specific to the particular user and application. This can be seen as the reference being checked and merged (substituted) to the statically defined currentSLATemplate. The use of such a "base" template, submitted by the user, may help to use this base as negotiation component for future development of negotiation schemes alike those used in the real world for shipping various services (where special rates and priorities are pre-negotiated on a per-class-of-users or per-kind-of use basis).

The provider has the final word for accepting the SLA: the provider always avoids reserving resources for nothing. The user is not sure the quote proposed by the provider will allow him to have the corresponding reservation (it is possible that an other client receives the resources that were expected to be allocated, or that the provider changes his mind). In other words, resources are not reserved until the provider signs the SLA the user is commiting to follow. Hence, resources get reserved only when the provider is sure to get the deal. In the proposed framework, the provider only commits resources against payment, and never has resources reserved without a signed SLA. The provider benefit is valued more than the user benefit...

The negotiation can go on for a long time, as there is no guarantee that the user will not only send quote requests, and never send a submitSLA. It may be difficult to reach an agreement as there are many parameters that come into play to define the QoS : type of resource, job start time, job duration, bandwidth, resource quantity, etc. The pattern does not enforce in any way the termination of the negotiation, which can fail to terminate. No constraints have been set on the negotiation behaviour, as they would make the framework complex and less general. Constraints on the lenght of the negotiation are to be dealt within the provider and end user practices according to the level of "intelligence" the respective negotiation procedures can provide.