| 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(28thFeb0 | 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 | Being Discussed | 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(28thFeb) | "-
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 | To Be Discussed | |
| 17 | No XML snippets for Resource Properties in S8 | Jon MacLaren | To Be Discussed | |
| 18 | Inconsistent use of expiration / termination | Jon MacLaren | To Be Discussed | |
| 19 | Figure 2 | Tiziana Ferrari | To Be Discussed | |
| 20 | glossary and Figure 1 | Tiziana Ferrari | To Be Discussed | |
| 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 | To Be Discussed | |
| 24 | creation contraints and serv. lev. Objectives | Tiziana Ferrari | To Be Discussed | |
| 25 | Occurance of AssessmentInterval in Comp.Type | Heiko Ludwig | To Be Discussed | |
| 26 | TerminalFault | Tiziana Ferrari | ||
| 27 | Agreement name optional | Mike Fisher | ||
| 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 | ||||