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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Bob Haugen writes:

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

Dale> Possibly not, but we tried!

"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?

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.



Earlier Dale>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.

Bob>That is one of the reasons why the simple
negotiation pattern has every counter-offer
as a new request with an obligatory response.

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

Marty and Heiko can explain those. Perhaps there
are some written guard conditions in the text,
but no one has mentioned them. 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...

Bob>I'm not saying the simple negotiation pattern
is perfect, but there were a bunch of smart
people at the table, and we had reasons
for every decision.

Dale> Not in question. Our intended goal is to
have a BPSS model for CPA negotiation, and
that is why we started with reviewing previous
contributions. As you can see, the simple model
both had some things we were uncertain that 
we needed, and other things possibly missing, or
at least needing more emphasis. If
we could stay in a Request/Response pattern without
stretching it too much, I would think that would
help us finish sooner. 

>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