| Updated Date | ||||
| Document Tracker | https://forge.gridforum.org/docman2/ViewCategory.php?group_id=71&category_id=659 | |||
| Comment Tracker | https://forge.gridforum.org/forum/forum.php?forum_id=461 | |||
| Karl's Draft | https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en/12 | |||
| Comment-ID | Title | Posted By | Status | Resolution/Discussion |
| 2 | Minor comments & asynchronous operations[ Reply ] | Takuya Araki | On discussion | Discuss
on the mailing-list. (especially wrt . Having it in the protocol or having it in the bindings) |
| 12 | WS-Agreement spec - proposed refactoring | Jon MacLaren | Resolved? | Proposed
that the agreement document structure be separated from any of the supporting
services/port-types. **Action: For at least one first time reader, it seems at the proper granularity. Concern that it will result in "chasing document" if we split it any further though from a purely technical perspective this would be possible and perhaps sound. |
| 15 | Use of WS-ResourceProperties | Jon MacLaren | Being Discussed | Our
approach will be to support port-types consistent with the convention used in
WS-ResourceProperty. **Action: Will be re-addressed on the next call. Also find out what the state of WS-RP is. |
| 18 | Inconsistent use of expiration / termination | Jon MacLaren | Being Discussed | Superceded
by subsequent discussion on lifecycle which is to be addressed. |
| 21 | comments about Section 7 (run time states) | Tiziana Ferr | Being Discussed | Is
our state model extensible is an important question. For example, "Not Ready" is
not always a needed state. What
we'd like to do is update the overall state diagram. We need to introduce an initial
state. Processing is removed as a
top-level state, and can be considered a sub-state of Ready. Transition from either "Not Ready" or "Ready" to "Completed" is possible. **Action: update the state diagram and description text. Try to find a better word than "Completed." **Asit to own the updates. |
| 22 | definition of compliance in Section 6 | Tiziana Ferr | To Be Discussed | |
| 24 | creation contraints and serv. lev. Objectives | Tiziana Ferr | Partially Resolved | Discussion:
yes, this is what we have done.
**Action: Send request for clarifying e-mail to Tiziana to make sure
that we're understanding the
request correctly, ideally pointing to an example in the doc. Heiko will contact her. |
| 25 | Occurance of AssessmentInterval in Comp.Type | Heiko Ludwig | To Be Discussed | |
| 26 | TerminalFault | Tiziana Ferr | ||
| 27 | Agreement name optional | Mike Fisher | ||
| 28 | Consistent approach to Term Compositors | Mike Fisher | ||
| 30 | Include base objective set for web services | Asit Dan | ||
| 33 | Explain service reference use better | Heiko Ludwig | ||
| 34 | Refining scope of Guarantee Terms | Heiko Ludwig | ||
| 35 | Guarantee terms for best effort systems | Heiko Ludwig | ||
| 36 | Business Value Table | Heiko Ludwig | ||
| Other issues being Discussed | ||||
| 1 | Signature of Agreement | Karl and Jon | Being Discussed in the ML | This requires some extensibility on the input and output to the create agreement operations. Perhaps already covered in the current versions. **Action: Karl to review the current spec. in this area. |
| 2 | how
to specify the criticality of an extension |
Karl | That
is, would an extension have to be processed, or may it be safely ignored if a provider doesn't understand them. Is there a community best-practice alredy in place or needed for this? |
|
| 4 | Creation faults | Karl | On
creation operation, should we provide some general structure for faults (e.g. pointers to failed terms). We have at least two types of fault: could not understand the input, input understood, but not able to satisfy where this one could include pointers in to the input document plus some extensibility on the cause.This would be a bit of a hint, and does not imply anything concrete, or head down the slope of negotiation. **Action: this added to the comment list by Jim, would like to see a proposal here. |
|
| 5 | Termination | Toshi | Is
WS-RF termination good enough, and the terminate operation could fail or be delayed because the agreement is not "completed" yet. Further termination could be done as extension. We could define an extension on the resource lifetime termination operation saying that we cannot terminate now because the agreement is on-going. Do we advocate in the spec. that the agreement resource SHOULD live as long as the obligations associated with the agreement? Consensus on the list is that this makes sense. |
|