Negotiate agreement (or not) between agents
|Actors||Agents, on behalf of Principals|
|References||UC.R1.32 Conduct Negotiation
CIAD COI OV Governance Framework
UC.R2.30 Define Interaction
|Is Used By|
|Is Extended By|
|In Acceptance Scenarios||AS.R2.03A Modelers Integrate External Model with OOI|
|Technical Notes||The actors are 'Negotiators': agents that can take on a negotiation role, and which act on behalf of people or systems. The roles of the respective agents could be varied — Consumer / Resource, Principal / Org, or any two Orgs creating an agreement.
At each step, both parties are Negotiators; at each step we take the perspective of one of them and refer to the other one as the counterparty.
This use case blends the original 'single-shot' and 'alternating offers' negotiation use cases.
|Primary Service||Federated Facility Services (Virtual Organization) Part 1|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
The agents for two parties undertake to reach an agreement on terms by exchanging proposals and related responses (accept or reject, or a counterproposal). The contract is created through a series of communicative acts. A negotiation is initiated when one party proposes to another party. The parties may make zero or more counterproposals to each other. The negotiation ends when one of the parties rejects the last proposal or all the parties accept.
- All messages in all negotiations are logged for later inspection.
Negotiators exist; the initating Negotiator has access to address of the counterparty (to which proposals can be sent).
- A Negotiator sends a PROPOSAL message to the counterparty specifying the terms for a proposed engagement
- A Negotiator receiving a PROPOSAL message responds with one of three messages: an ACCEPT_PROPOSAL (specifying the terms in the immediately preceding incoming PROPOSAL from the same counterparty), a REJECT_PROPOSAL (specifying the terms in the immediately preceding incoming PROPOSAL from the same counterparty), or a PROPOSAL as in the previous step (this functions as a counterproposal).
- Upon receiving or sending an ACCEPT_PROPOSAL or REJECT_PROPOSAL, neither Negotiator sends further messages (so this negotiation is closed).
- A valid ACCEPT_PROPOSAL means that the Negotiators are committed to the terms specified in the ACCEPT_PROPOSAL.
- An ACCEPT_PROPOSAL is valid only if it occurs prior to the expiration of the PROPOSAL that it refers to, and has the identical terms as that PROPOSAL.
- <2> A Negotiator sends a new PROPOSAL message within an existing conversation to subsume previous proposals.
- All previous PROPOSAL messages sent by the Negotiator or the counterparty in the same negotiation conversation lose their significance to the subsequent engagement.*
- In other words, a PROPOSAL dissolves all previous PROPOSALs arising in the same negotiation.
- An ACCEPT_PROPOSAL message results in registration of the accepted PROPOSAL, and an event confirming the PROPOSAL acceptance.
- All accepted PROPOSALs should be registered in a searchable registry.
Proposal has been negotiated and resolved, either accepted (and registered) or not.
These comments provide additional context (usually quite technical) for editors of the use case.
This use case should be expanded to include concepts of identity management to satisfy DOORS requirements.