Re: [ebxml-cppa-negot] ANCPA Version 0.10 review

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Sacha Schlegel wrote:

>Hi CPA Negotiation team
>
>Here my attached comments about Version 0.10 of the ANCPA Specification.
>Kind regards.
>
>Sacha Schlegel
>Automated Negotiation of Collaboration Protocol Agreement Specification, Version 0.10 Date: November 2nd, 2003
>--------------------------------------------------------------------------------------------------------------
>
>....x Maintaining a large number of partner relationships. This negotiation scenario might have different/new negotiation requirements ... to be thought.
>
mm1: This has also been a topic of discussion in ebBP [1].  The idea of 
multi-party or many party relationships may also introduce dependencies 
and additional requirements.

[1] Missing you there, Sacha.

>.......x Line 218: it seems that rejecting an offer might become a tactical maneuever, especially the rejection of the initial offer with a new ndd... in case the receiving party just does not want to use the newly created CPA template and NDD... Maybe this cannot be circumvented.
>
mm1: Does this mean that the rejection has a reason and only specific 
reasons are allowed by the initiating party?

>....I liked to call it the "CPA formation" which includes the CPA composition and the CPA negotiation.
>
mm1: Wasn't this a simplification area where composition and the 
algorithm were actually outside of the core negotiation document?

>.....x Line 429: Prior to this point, there is a very important point in my opinion. The Initial Offer receiving party has to do a big job here: validating the cpa template and the ndd! For this process it sort of also has to create a CPA template and compare the two CPA templates if it can agree to what will be negotiated. The same for the NDD, it has to make sure it does not get cut short somewhere, that all its negotiation items are fairly represented in the ndd which goes with the new CPA template. 
>
mm1: Is there some way that potentially WSPL (policy language) could be 
used to ease the background comparison required here?

>......x Line 501: This might become a possbile business scenario where a negotiation agent does negotiate on behalf of its clients (cpp providers).
>
mm1: This is also a dual discussion between BPSS and CPA because the 
issue of proxy and delegation impacts both, in negotiation and in general.

>.....x Line 700: What is the same BPSS instance Document? same name, same version and same uuid? or a mix of it? which combinations of those attributes are not the same bpss instance document? Neither clear in the CPPA spec. A boolean table would define when two ProcessSpecification elements are ment to be the same BPSS Instance Document.
>
mm1: The BPSS instance refers to the XML representation or XML instance 
document that conforms to the ebXML BPSS (schema).

>....x Line 759: Generally each BusinessTransactionCharacteristics element has to be negotiated individually. Is this an idea to have a sort of CPP global BusinessTransactionCharacteristics information?
>
mm1: Perhaps you can expand on this question, as it relates to ebBP, as 
I can't answer at this point.

>....x Line 923: "This MUST be validated" probably in the CPA composition and during the CPA negotiation has to be checked that the roles are OK. This has the interesting question how much validation is part of the CPA negotiation. 
>
mm1: We had the discussion before in work on ebBP 1.1 how much 
validation occurs in BPSS and then in CPA.  Perhaps we can continue to 
discuss.

>x Line 988: Maybe make say that a negotiation item only specifies an element/attribute but not its children ... Here is a general problem of element/attribute dependencies. Allowing to negotiate the BusinessTransactionCharacteristics element, or a specific attribute of the element might have the consequences that other elements/attributes have to be negotiated but are not listed in the NDD.
>
mm1: There are dependencies that are inherent in the binary 
collaboration - inner and outer (if applicable) and in the BTAs.  This 
may lend itself as a simplification to allow ebBP and CPA negotiation 
teams to figure out this one [2].

[2] I would need to ask ebBP team.

>Comment to above -- clarified in Line 1017+
>
>x Line 995: Again the dependencies of element/attributes might cause problems in the NDD. Example what does mean to negotiate over the DeliveryChannel element, does that include to be able to negotiate over its children (and hence Transport element and DocExchange etc). 
>
mm1: Overall, this may be at least a v1 simplification area where an 
element is negotiated not its children.

>x Line 1027: Maybe move this section one section ahead.
>
>x Line 1054: ... it seems like the NDD for the CPA template is realy only used for combining two NDD's. ** In my current CPA composition implementation the composition algorithm writes out that sort of gap list, in particular a conflict list. It seems that those conflicts do not have a place in the NDD.. The sentence beginning in Line 1056 shows that ... if there are irreconcilable conflicts ... the CPA negotiation does not deal with them ... ** From a previous understanding I was rather thinking that the CPA negotiation will trie to overcome irreconcilable conflicts ... thinking of that it would probably become very complicated to have algorithms which can deal with all those possible irreconcilable conflicts ...
>
>At the same time ... if party A runs the CPA composition which results in a CPA template, party A uses its NDD for its CPP. Party A could even use a NDD which is not public, so party B has no way to tell what party A exactly did. What I mean is, party A could simply say say, all conflicts found in the CPA composition are my NDD. Is that cheating? Party A could run the CPA composition, saying with its NDD and Party B's NDD. The CPA composition could find some irreconcible conflicts. To go ahead party A could simply add those conflicts to the NDD for the CPA template, saying that it wants to negotiate over those elements... but reading Line 1054, this is not possbile as the NDD for the CPA template only includes, what also Party B includes in its NDD ... and the CPA negotiation could not get started.
>
>Maybe some real world experiences will help how things will be used, for example will it be a practice to set the negotiation item: "//" in the NDD, saying that everything is negotiatable?
>  
>
mm1: This surrounds one of my comments, that WSPL may be an automated 
alternative to do simple pattern matching to assist here or as desired. 

>.....Serious, irreconciilable problems seem to be dealt only in human to human ways, so far. ** I think, this is actually a serious simplification then.
>
mm1: Same comment as above. In addition, if we look at the work in the 
Netherlands with OpenXchange we may find capabilities to do algorthmic 
matching of the business processes, which may simplify and perhaps 
resolve your concerns Sacha on the dependency issues.

>.....General question when dealing with uri's: Does this mean that the parties must have a webserver where the document (NCPA in this case) can be accessed by the other party? This would most likely be outside the Messaging System Interface (MSI), and maybe even the Business Service Interface (BSI). Is this generally no problem to provide a HTTP access point to the outside world? Does the negotiation software have the priviliges to change the content of that URI? Does it even have the security permissions to provide a http access point?
>
mm1: This seems like metadata information associated with the 
negotiation process, or correct me if not. 

>
>*** Section 13
>x The negotiation algorithm is probably the hardest part. Any idea how these algorithms will evlove? Any idea who will implement these algorithms? Any ideas on what background knowledge these algorithms will be based upon? Any one started with a study of what the requirements for a negotiation algorithm are? Any thoughts of having another specification/document/report on ebXML Automated Negotiation of CPA Negotiation Algorithm Docuemnt or is this fully open to implementers.
>
mm1: We could provide some abstract representation or parameters that 
the algorithm functions should meet. That could leave the actual 
implementor to decide.
It appears there are several key simplification opportunity areas: 
security, algorithm, simple pattern matching to enable NDD and CPA 
template as well as to automatically resolve some items quickly, and the 
potential investigation of use of process matching from OpenXchange to 
do the same for transaction characteristics.

Sacha, everyone very much appreciates your efforts.
Monica