Re: [ebxml-cppa-negot] Message Content Update based on last conf call

[bhaugen <linkage@interaccess.com>]

Heiko Ludwig> We are reiterating the last two last
phone calls here. 

Bob> I'm sorry about that.  I know it is annoying
to have a lurker drop some comments into the
process without knowing the history.  Feel
free to tell me to shut up.  This is interesting
to me as one of the developers of the negotiation
pattern, though, to follow through the problems
people are having with it, so I hope you will
consider my comments in that light rather
than as meddling.

Bob Haugen writes:

"Dale and all,
Are you sure you understood the simple
negotiation pattern?"

Dale> Possibly not, but we tried!

Bob> Well, then I would blame the
explanation.

"The negotiation stage is supposed to be
transactions with alternating sides, as
long as a counter-offer is pending (as
long as the negotiation is still alive)."

Dale> The alternation was not apparent from
the diagram. Pallavi did explain the idea
of nesting briefly. We are still trying to understand
how that would work in detail. In itself,
I do not see nesting as (1) promoting
each side as a proposer (using own NDD),
(2) constraining process so that we don't
get too many proposals "outstanding" or
(3) preventing a nested proposal from
unfruitfully repeating an earlier proposal.

Also is the nesting tracked by a stack
on each side?

Do we have to unwind and issue explicit
accept xor rejects for each pending proposal?

Are there any constraints on further nesting,
or can it proceed arbitrarily deep?

Bob> It's not nested.  We stayed within the
constraints of the request-response transaction
protocol.  It's alternating.  Each transaction
can have three (not two) response types:
1. accept
2. reject
3. reject with counter pending

Dale>
Possibly there is text explaining all this but
it has not been brought up yet. I think people
are trying to draw state machines at each side
and see how "smart" the software has to be in
tracking the state of discussion, for one thing.

Bob> Do think nested state machines.
One state machine (lower level) per transaction,
another per the states of the agreement:
in my diagram, pending, accepted, rejected,
counterPending.  Think of the object states
as Petri net places.

>There are also some "race" conditions that
>others can discuss
Bob>For example?

Dale>
Marty and Heiko can explain those. 

Bob> It would be useful beyond this discussion.
If there are race conditions in the negotiation
pattern, we want to correct the pattern.

Dale> Also, while we
have you on the phone, we were not clear
whether we had to use the "two phases" of
negotiation (the initial one and then a
binding one). We did not have our legal rep.
on the call to help us with that part...

The non-binding phases are not required.
It's a pattern, intended to be interpreted
by human judgment.

Dale>  If
we could stay in a Request/Response pattern without
stretching it too much, I would think that would
help us finish sooner. 

I think you can.  But maybe I am missing
something.

>Meeting is Wednesday if you want to help!

Ok, I'll try to join the conference call at
least for a while.

Dale> OK, I will be ready with some questions!

-Bob Haugen
----- Original Message -----
From: Dale Moberg <dmoberg@cyclonecommerce.com>
To: bhaugen <linkage@interaccess.com>; Jean Zheng <Jzheng@vitria.com>;
<ebxml-cppa-negot@lists.oasis-open.org>
Sent: Monday, March 04, 2002 9:06 PM
Subject: RE: [ebxml-cppa-negot] Message Content Update based on last
conf call


Hi Bob,

One "meta-requirement" on CPA negotiation
is that the semi-automated negotiation process converge
rapidly either by failing (and throwing
the process up to humans for resolution)
or succeeding (for the parameters marked
negotiable in a NDD, which iconstrains
what is up for debate). One phenomena
we wish to avoid in the semi-automated "dumb"
negotiation is one in which the sides
just iterate back and forth endlessly
in a "RSA-SHA1" "DSA-MD5" loop (you
can add some other dimensions of
oscillation, and backtracking, if you want to make
the failure to converge less obvious).

By starting a new transaction, we retain
no history and we do not really have a chance
to switch "sides" on who is constructing
the initial proposal and whose NDD governs
the search for acceptable parameter values.

The Simple Negotiation process builds in no assurance that
each side has a chance to let its NDD and
its draft CPAs come up for consideration.
There are also some "race" conditions that
others can discuss.

The upshot is that the Simple process seems
a bit too simple
to have the desired behavior.

One drawback to the way we are thinking
of things now is that one can respond to
a "request" with another "request," which is
probably outside the current request-response
pattern. We are still seeking BPSS advice on
this situation. Meeting is Wednesday if you
want to help!

Dale Moberg


-----Original Message-----
From: bhaugen [mailto:linkage@interaccess.com]
Sent: Monday, March 04, 2002 6:27 PM
To: Jean Zheng; ebxml-cppa-negot@lists.oasis-open.org
Subject: Re: [ebxml-cppa-negot] Message Content Update based on last
conf call


Re tentative process:  is there some reason that
you abandoned the original idea, which I thought
was to use the ebXML v 1.0 Negotiation Pattern.
That would require each offer in the negotiation
to be enclosed in its own transaction with either
a success, fail or counter-pending post condition.
In other words, each offer could be explicitly
and clearly accepted or rejected.

If you just go back and forth with counter-proposals,
I think it will be more difficult to determine what
was accepted or rejected.  (Which was one of the
ideas behind the Pattern.)

-Bob Haugen

----- Original Message -----
From: Jean Zheng <Jzheng@vitria.com>
To: <ebxml-cppa-negot@lists.oasis-open.org>
Sent: Monday, March 04, 2002 7:19 PM
Subject: [ebxml-cppa-negot] Message Content Update based on last conf
call


I've made some update to Message Content based on our discussion during
last conference call.
Main Changes are:
1. add in a Security section for "InitiatingCPANegotiation" message.
2. Add in enumerated list for CPA status and reason for rejection.
3. Move Tentative Process section to the end.

Any help in adding more details to any of these sections are very
welcome!  Especially in the Security section.

Thank you!
Jean