Public comments are a very important part of the OGF document approval process. Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful. Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document. The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.
Thank you for making public comments on this document!
Comments for Document: WS-Agreement Negotiation Version 1.0
|Author(s):||O. Waeldrich, D. BattrĂ©, F. Brazier, K. Clark, M. Oey, A. Papaspyrou, P. Wieder, W. Ziegler|
|Public Comment End:||15 May, 2011|
Please ind beklos,
some editorial comments.
(I wish I could take time to do a detailed check)
WS-Agreement Negotiation provides an
additional layer when creating agreements with WS-Agreement is using an
extensible XML language for specifying the nature of the agreement offers,
and agreement templates to facilitate discovery of compatible agreement
parties and ease the process of creating valid agreement offers.
=> Cpuld you be more succinct wrt this statement which is rather bizzar (from
non native English speaker..)
This problem leads to a situation in which
service consumers do not only have functional requirements for a service, but
also demands regarding to the non-functional service properties, such as the
average response time of a service, the service availability, or the average
recovery time in case of failure.
also demands => also demand
This offer is then send=>
This offer is then sent
negotiation responder received the initial negotiation offer
is again send to the negotiation responder that decides that this particular
offer is unacceptable.
Figure 3: Different views on the negotiation process. An offer send by
one negotiation participant is a counter offer to a previously received
An offer send by=> An offer sent by
The property name should be wsag-neg:NegotiableTemplate.
The cardinality (minOccurs,maxOccurs) is not specified in the WSDL. It should be minOccurs=â€?0â€? and maxOccurs=â€?unboundedâ€? (0..n as specified in 7.5.4)
The spelling of NegotiableTemplate is wrong in the WSDL and XML schema file.
Overall, we're very satisfied with the current state of the document. In typical GRAAPian fashion, the layout, figures and content are very clear and well presented.
With specific regard to the state machine (which has been a source of confusion and disagreement), I think the examples and illustrations shown in 5.4 make the acceptable state transitions very clear. My compliments go to the author of this section (I assume Oliver?).
Just a small thing, but please replace "on the base of" with "on the basis of" throughout the document.
We are planning an implementation for second half of this year, so I'm sure we'll have more comments after that. =)
My main comment is that the Offer/CounterOffer state transition diagram should take into account that an offer can expire.
PS: a small thing on spelling: please replace "costumer" with "customer" :)
This standard proposal seems to be effective and useful, and the draft implementation of WS-Negotiation in WSAG4J framework is being used in our licensing solution for negotiating the software licenses. A nice seperation of WS-Neogtiation specification from WS-Agreement makes very easy to integrate WS-Negotiation in our exisitng WS-Agreement based implementation.
Sorry for the delay in getting back to you.
The document reds well, is concise and sound. I enjoyed reading it!
Here are some comments:
Page 1. Delete [provides an additional layer when creating agreements with
WS-Agreement] as it is duplicated
Page 4, Introduction section, typical example. Negotiation is seen as taking place pre "service execution" whereas re-negotiation is likely to take place during the service execution. Do we want to make that clearer?
It is important that the provision of symmetric and asymmetric protocol is there (page 6). If the negotiaton process is driven by a client (service requestor) and an agreement is created, then the re-negotiation process may be driven by either parties: the client or the service provider. In the situation where the service provider is initiating the re-negotiation it needs the means to do so (this is well explained in section 7).
Page 6, requirements. Is the number of re-negotiations limited or not? Can either party request a re-negotiation at any time? is this clearly specified in the negotiation context?
Page 11, section 3.1, last paragraph. The offer is then [sent] to the negotiation responder ...
End of page 11 - Start of Page 12. This offer is again [sent] to the negotiation responder ...
page 18. in /wsag-neg:NegotiationType/wsag-neg:Renegotiation, needs to clearly differentiate between symmetric and asymmetric layouts.
Page 33, Figure 10. There is an arrow Advertise(offer) from the negotiation initiator. What does the negotiation responder return? In the same figure, one would expect to see the following:
- CreateAgreement(offer, negotiationExtensionDocument)
Am I right to think that at the last round of the loop Negotiate(offers) is followed on the negotiation initiator side by
CounterOffers + CreateAgreement(offer, negotiationExtensionDocument)
and not directly by
Page 33, section 7.3, line 8. as soon [as] a new ...
Hope this helps.