RE: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPPA

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Bob Haugen> 1. Why is that better than just allowing somebody
to restate the same offer again when it is their
turn?

"Better" is a relative term! I have no claim
that it is a better analysis of "negotiation"
from a cognitive standpoint, nor is comparison
along that dimension critical to me for automating
the CPA negotiation process. 

If a proposal has been submitted, 
and it is "acceptable," but
there are other candidates "preferable," then
an agent may wish to explore whether any of
the preferable set are acceptable by the other
participant. All this might be something we want
to do without ever recomputing the comparitive
values among all candidates, which might involve
expensive operations (exploring many combinations
and weighting them). Beginning again would
definitely have a computational cost.

It is also error prone because an algorithm
for resubmission might lead to
endless repetition of the same scenario. 
Outright rejection, at least for CPA, should mean
"Do not try this one again, for the same CPPs and NDDs". 
Trying again with a clean slate
would, unless state and history are retained, probably
reproduce the same proposal's counterproposal (unless
someone throws in some random weighting!). Groundhog day.

Anyway, any opportunity we have, protocol-wise, to
prevent this looping should be something we consider.
These are some reasons to consider avoiding
some "retry same proposal" option: 
1. recomputations expensive,
2. no prevention of ground hog day.

[In call, Bob noted that he did
not know that we are struggling
to specify a "mostly automated"
procedure.]

To me, these considerations are weighty. They
all pertain, not to analytic issues, but to
algorithm and computational simplicity. We
want this to be easy to implement. Just
generating CPA draft proposals is hard
enough. Adding on a lot of 
complex ranking logic, arbitrary history
tracking, and resubmission logic,
and people will not want to build it.

2. In the Simple Negotiation Pattern, if anybody
rejects an offer outright, with no counter-pending,
it's the end of the negotiation, and if anybody
wants to continue, they restart from the top.

[ OK, restart with a new different proposal
would be OK, of course. See above for
some concerns for the mostly automated
situation.]

3. If you stick to the existing ebXML transaction
model (which I think you can do), won't your
overall problem be simpler?  (Use any compliant
software, etc. etc.)

Dale> I think we are going to stick with the
existing model for documenting the collaboration
or message flow aspects. Brian H is working
on our BPSS instance, I believe.]

<Dale Moberg>
(and as a useful optimization)

2. packaging this counter-pending response with the new request
providing the proposal (plus NDD if needed)
   --to cut down on message traffic,
   --to keep related messages "together"
</Dale Moberg>

But it doesn't keep some related messages together.
The critical relationship is offer-acceptance.  If you
send the counterproposal with the response, you
lose that relationship, and will need to recapture it
with some other logic.  So what did you gain?
A few seconds in a very intermittently used process?


Dale> It may not be necessary to do this, but one of
our use cases for counterproposals is that a proposal
has come in that is acceptable to us, but we think
that there is another that is preferable.

For example

Party 1 Transport Preferences                 Party 2 Transport
Preferences
FTP                                           SMTP
SMTP                                          HTTP
HTTP                                          FTP

Party 1 proposes transport binding to FTP (his 1st, their 3rd)--
the first draft CPA solution his software found.

While this would "work", party 2 proposes SMTP ( his 1st, their 2nd)

If 2 wants to explore the counterproposal with 1,then it
is allowed that 1 either
accepts or rejects. 

If accept, then done (after signing stage). If reject, then
2 indicates that it accepts the still workable initial solution
made originally by 1.

Whether we allow counterproposals to counterproposals needs some
decent use cases... 

A simple "negotiation" procedure for us would 
not even allow counterproposals!
We would just insist on an accept or reject outcome. Each side could 
independently initiate, and no coordination needs to be done (other than
to reject after a CPA has been found and signed!) Maybe we will 
try this as the simplest NCPA model!



<Dale Moberg>
I do not think we need to be required to capture every feature of human
negotiation in a CPA "negotiation" process. CPA negotiation is not
nearly as nuanced as human agreement/contract negotiation and it does
not seem critical to me to adhere to the
 human patterns in these mostly automated
processes. In particular, the rejection 
semantics should be strong in an
automated process and not just a tactical
maneuver. I think it will be
more complicated to automate otherwise.
</Dale Moberg>

Bob> Actually, I think human negotiation patterns have
already been simplified.  I agree that automated
processes do not necessarily need to adhere to
the human patterns, but I have also seen people
go deep into the technical bag of tricks when
it's not necessary, because the humans have
already shown how to simplify the problem.

Dale> We are willing to use 
whatever we can to simplify, as long
as it the processes stay ones
that are mostly automated.
(Humans will need
to approve CPAs when, for example, 
new trust anchors have to be accepted
for the CPA to work...)