| Comment-ID | Title | Posted By | Status | Resolution/Discussion |
| 1 | Changing Offers | Toshiyuki Nakata | 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 (GGF12) | 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 (GGF12) | 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 (GGF12) | 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 (GGF12) | 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 (GGF12) | 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 (GGF12) | 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 (GGF12) | 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 | To Be Discussed | |
| 19 | Figure 2 | Tiziana Ferrari | 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 Ferrari | 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 Ferrari | To Be Discussed | |
| 22 | definition of compliance in Section 6 | Tiziana Ferrari | To Be Discussed | |
| 23 | Language problem in Section 5.1.1 | Tiziana Ferrari | Resolved(7th Mar) | **Action: Corrected by Jim on-line. |
| 24 | creation contraints and serv. lev. Objectives | Tiziana Ferrari | 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 | Resolved | Agreed that this is a good idea. **Action: make the change as suggested in the comment. Heiko to do so. |
| 26 | TerminalFault | Tiziana Ferrari | Being Discussed | **Action: Remove if no one seems to care. This points out that we have no faulting scheme defined. Do we need faults defined more precisely? How does this relate to general termination. **Check with Alain and Karl to see if it has any meaning or is left over from something else. |
| 27 | Agreement name optional | Mike Fisher | Being Discussed | What is the name of the agreement optional, this seems dangerous? We don't know how to name it in general. If we are in the document-domain where there are no EPRs, we don't know what naming scheme to use, so we've left it optional. We may wish to revisit this decision and think of a more general method. We also do not have any other specific field for filling in a unique id for the agreement, so this field is assumed to fill that role. **Action: revisit this discussion on a future meeting. |
| 28 | Consistent approach to Term Compositors | Mike Fisher | ||
| 29 | Guarantee Terms | Mike Fisher | ||
| 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 | ||
| 37 | ||||
| 38 | ||||
| 39 | ||||
| 40 | ||||