| 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 |
| 1 | Changing Offers | Toshiyuki Nak | Resolved | Treat the normative part as correct. |
| 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) |
| 3 | Semantics of related agreements ill-defined[ Reply ] | Heiko Ludwig ( | Resolved (14thFeb) | Related
agreements agreed last weeks to be taken out, but some discussion was still
going on. Not enough further
argument to change this decision. **Could be a primer issue as used in a service description term. |
| 4 | How do we know that terms are fulfilled?[ Reply ] | Heiko Ludwig ( | Resolved (15thFeb) | This seems to be outside the scope as it requires lots of further infrastructure. **Action: Add such information in the spec that says that enforcement is outside the scope. |
| 5 | Why is the termination time part of context?[ Reply ] | Heiko Ludwig ( | Resolved | Because the expiration time refers to the whole of Agreement. **Action: leave it in place, capture this discussion, add justifying statements to the document. |
| 6 | ZeroOrMore needed[ Reply ] | Heiko Ludwig ( | Resolved | Unless someone gives a clear Usecase of how this term is used, stick to the current proposal. |
| 7 | Specification too complex[ Reply ] | Heiko Ludwig ( | Resolved | Spec. doesn't require that entire thing be used in every example, so complexity can be removed in specific cases. This can be more clearly stated. **Action: Can also reply that actual number of structures is not all that large. |
| 8 | AgreementIsProvider attribute[ Reply ] | Heiko Ludwig ( | Resolved(23rd Feb) | Wewill augment the guarantee terms with which party is obligated and the obligee for each guarantee by role (initiator or provider). Alsoimplies a response to issue #32. Now that obligation is specific,there's no need for the AgreementInitiatorIsServiceConsumer flag in the context. |
| 9 | Related Agreements and Brokers[ Reply ] | Heiko Ludwig ( | Resolved | Related
agreements to be removed, and we only address two party agreements. **Action: Respond in tracker that we don't address this question. |
| 10 | Referred Specs[ Reply ] | Komori Hitoshi | Resolved | We
need to be explict about the state of the specs. that we refer to,including
their version. Be clear where
these are public but not ratified by any standards body. Update table on page 6
(section1.1.1). Remove the MAY be
composed entries. Add column
where we areexplict about version that will be used. (Revisit this at beginning of next
week). 28th Feb. Not used the spec., but followed the model is another category as in the case of WS-Policy. **Action: use table provided by Toshi in e-mail of 2/28/05 to replace the current table on page 6. |
| 11 | Three "nits" | Jon MacLaren | Resolved | "-
Reference to JSDL: **Action: Do not add to avoid confusion with referring to
other in progress specs. - Colors on figures: **Action: Change to gray shades. Heiko to do this. - Update Jon's Affiliation: **Action: Will be done by Heiko. |
| 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. |
| 13 | Consistency of WSRF ResProp. based monitoring | Jon MacLaren | Resolved | The only thing that can change is the term states because there is no updates. So, there is no concern for consistency, and no need for consistent updates. **Action: Respond that we don't think this is a concern in the follow up. |
| 14 | WS-Agreement dependent on less mature specs | Jon MacLaren | Resolved | cf Entry 10 |
| 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. |
| 16 | Organisation of runtime monitoring material | Jon MacLaren | Resolved(7th Mar) | We
wil add these snippets Heiko will add these by copying from the full schema in the appendix. |
| 17 | No XML snippets for Resource Properties in S8 | Jon MacLaren | Resolved(7th Mar) | We
wil add these snippets Heiko will add these by copying from the full schema in the appendix. |
| 18 | Inconsistent use of expiration / termination | Jon MacLaren | Being Discussed | Superceded
by subsequent discussion on lifecycle which is to be addressed. |
| 19 | Figure 2 | Tiziana Ferr | Resolved(7th Mar) | **Action: Change "Service Description Terms" into "Service Terms" in figure 2. Make similar changes in 4.2 as far as terminology. Change service description terms to service terms and add sentence introducing the different sub-types of service terms. Completed by Jim on-line. |
| 20 | glossary and Figure 1 | Tiziana Ferr | Resolved(7th Mar) | Glossary to the front: **Action: We will move glossary to the beginning as suggested a couple times. Figure 1 labels: **Action: add the initiator label. Completed by Jim on-line. |
| 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 | |
| 23 | Language problem in Section 5.1.1 | Tiziana Ferr | Resolved(7th Mar) | **Action: Corrected by Jim on-line. |
| 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 | ||
| 29 | Guarantee Terms | Mike Fisher | Response
is that there is nothing else today, so this is an approach we suggest. This specification can considered
optional in the sense that one
need not include guarantee terms at all, but is useful in some domains we've looked at.. **Action: update section 4.2 to make the definition of new term types possible, and update the pseudo-schema in 4.2.1, and introduce a new-subsection before the compositor definition. |
|
| 30 | Include base objective set for web services | Asit Dan | ||
| 31 | ServiceProvider / ServiceCustomer explicit | Heiko Ludwig | Resolved(23rd Feb) | cf Entry 8 |
| 32 | Obliged party attribute for terms | Heiko Ludwig | Resolved(23rd Feb) | cf Entry 8 |
| 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? |
|
| 3 | acceptance port type | Karl | Resolved? | This
is explictly an initiator side port type. Do we need to call this out very clearly since we have not had initiator side port types previously. This is somewhat called out at the start of sec. 9, but adding a comment here in 9.3 would be good. |
| 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. |
|