Re: [ebxml-cppa-negot] Future document

[Martin Sachs <msachs@cyclonecommerce.com>]

See my replies below (MWS:)

Regards,
Marty


At 07:48 AM 11/14/2003 -0700, Sacha Schlegel wrote:
>Hi Marty
>
>On Sun, 2003-11-09 at 12:16, Martin Sachs wrote:
> > I have just placed the futures document in the document folder on our Web
> > page.  the zip file includes both the Word and the PDF files. Please
> > comment with reference the line numbers in the PDF so that the line 
> numbers
> > are the same for all of us.
> >
>
>Ooops just read it (concerning line numbers) too late.
>
>Please find attached a notes file I wrote. It is rather general thoughts
>than specific line number comments.
>
>Regards,
>Sacha
>
>
> > Regards,
> > Marty
> >
> > *************************************
> > Martin Sachs
> > standards architect
> > Cyclone Commerce
> > msachs@cyclonecommerce.com
> >
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php.
>--
>------------------------------------------------
>Sacha                                   Schlegel
>------------------------------------------------
>4 Warwick Str, 6102 St. James, Perth,  Australia
>sacha@schlegel.li                www.schlegel.li
>public key:            www.schlegel.li/sacha.gpg
>------------------------------------------------
>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php.
Suggested Future Enhancements to CPPA Negotiation Specification
---------------------------------------------------------------

Comments from Sacha Schlegel
Comment: this comments come from a quick look at the suggestions.

1. negotiation protocol

1.1 negotiation directly with CPP's. Actually I did not think of this 
variant at all. Might be interesting as a negotiation algorithm at both 
ends could go sequentially (from higher level (party info) to lower level 
(DeliveryChannel, transport, docExchange, packaging down to simple part) 
through the elements of the CPP. Instead of 1.1.2 step 2 (one party creates 
CPA template) they could create the CPA (template) step by step (sort of 
element by element). Both sides would have to know pretty well how to form 
a CPA.

MWS:  I believe that you are correct.  I expect, however, that this would 
be a lot slower process than first forming a CPA Template and NDD because 
starting with a CPA Template and NDD quickly narrows the problem down to 
just those items that need negotiation.

1.2 Which BPSS Instance Document? Are you talking about the Negotiation 
BPSS Instance document or the BPSS which are in the parties CPP? I assume 
you are talking about the Negotiation Business Process otherwise  if a CPA 
can have more than one CollaborationRole per PartyInfo you might deal with 
more than one BPSS.

MWS:  Yes, it's the BPSS in the Parties' CPPs.  The Negotiation BPSS 
instance document can't be negotiated.  It defines the negotiation protocol 
itself.

1.3 I thought that once you agree on an element you cannot change your mind 
again might be a problem. Especially in case of interdependencies (use case 
necessary in the way of if both parties do not talk about a SecureTransport 
they cannot change the BusinessTransactionCharacteristics 
(isConfidentail,isAuthenticated,isTamperProof or isNonRepduationRequired) 
attribute which asks for a SecureTransport element). On the other hand this 
could be good as one party then is assured, that once value is set it is 
set. Otherwise you might end up in a loop, like in a game where both 
players repeat the same move again and again because they think thats the 
only way to go.

Might be difficult to provide a fair list which elements you allow to 
renegotiate.

MWS: You are exactly right.  That's why we now say "no going back".  I will 
add your comments to the futures document.

1.5 I came across this one as well. It can also happen, that one party 
sends an accept message even though there are still open negotiation items 
in the NDD. This is probably against the negotiation protocol (negotiation 
rules) and the receiving party will return with an error message. According 
to the BPSS an accept message can be sent no matter if there any open issues.

MWS: Correct.  The BPSS instance document does not define the whole 
protocol.  An implementer MUST read and obey the textual description as 
well as the BPSS instance document.

1.5 But I agree that there might be a message back and forth in the form of 
"we are done, what do you think?".

MWS:  I assume you mean an acknowledgment message that might be sent by the 
recipient of the final CPA (where there is no signing) or the double-signed 
CPA (where there is signing). I will put this suggestion in the futures 
document.

1.6 Ordering Dependencies among Negotiable Items. For some reasons I was 
believing that all Negotiation Items are negotiated in parallel. Have to 
recheck in the ANCPA.

3. Negotiation Algorithm - I start to have problems to see the border 
between the internal "negotiation" process and the collaborative 
negotiation business process. To which business process does the rules for 
the game, for example, once an item is accepted it is accepted belong to? 
The internal business process must know this rule, I think. If it belongs 
to the internal business process you/we might start to differentiate 
between these two business processes.

MWS:  As above, that's why we left the negotiation algorithm for the future.

7. Simplification of Negotiation - You might provide a default negotiation 
algorithm specification/report which does only negotiate "simple" things. 
If there are simple things at all :)

MWS:  I will put this comment in the spec both under negotiation algorithm 
and under simplification.


Other questions/thoughts
------------------------

o Did you every think of not having everything negotiated in parallel? 
Unfortunately I did not think through an example but negotiating everything 
in parallel seems to be more difficult than negotiating one by one. As 
mentioned above I might have misunderstanding here.

MWS:  I am not sure what  you mean by "parallel".  By "parallel", do you 
mean that everything negotiable is in the NDD at the start? If so,  the 
idea was to present everything that is negotiable at the. Probably, the 
"easy" items can be negotiated in one pass.  In any case, each party has 
the option of accepting as much or as little as desired in each iteration 
and continuing the string of offer-counter messages as long as needed, thus 
producing serialization.

o For some reasons I still think that when a negotiation starts both 
parties first have to agree on the CPA template and the NDD for that CPA 
template. Instead of having to reject and restart a new negotiation some 
Business Transactions Activities could be added to cover a "setting" stage 
first. Saying that, the acceptance of a CPA template and NDD might also end 
up in a offer - counter offer - counter offer scenario until the 
negotiation over the elements of the NDD starts.

MWS:  I think that your real concern is the NDD.  The NDD says what is 
negotiable in the CPA Template. The whole negotiation process consists of 
step by step refinement of the CPA Template until it becomes a complete 
CPA. To me the extra step of negotiating over the NDD would be excess 
complexity. If the recipient of the initial offer doesn't like the NDD, the 
recipient should reject the initial offer and get on the phone. I believe 
that in most cases where both Parties have published NDDs for their CPP, 
the NDD in the initial offer will be acceptable since the offering party 
MUST use both NDDs in constructing the NDD for the CPA Template. If so, 
then adding negotiation over the NDD is function that will be mostly not 
needed but adds complexity to the spec and cost to the implementations.  A 
Party that does not publish an NDD for its CPP is implying that everything 
is negotiable and ought to be willing to negotiate with any NDD that comes 
in an initial offer, though we can't require that.



*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com