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
Draft		https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en

Comment-ID		Title	Posted By	Status	Resolution/Discussion	Reflected in Draft?	Page/Section/line	Owner	Done?
1		Changing Offers	Toshiyuki Nakata	Resolved	Treat the normative part as correct.	Example has to be changed	P56. Agreement Example	Toshi	Yes
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)	Yes		--	--
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.	No. Related agreement Still exists in Draft	P.13-14 Section 4.1	Heiko	Yes
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.	No. Comment needs to be added somewhere	P.40? Sec 9.5.1	Heiko	Yes, P.31 Section 4
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.	No. Justification Statement Needs to be added	P.14 Section 4.1	Toshi	Yes, P.14
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.	No.	P.14 Section 4.1 & P.22 Section 4.6.1	Heiko	Yes, P.14 and P.22 4.2.6.1
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.	No. (Cf. ID-3)		cf.3	cf.3
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.	No.	P.5 Sec. 1.1.1	Toshi	Yes, P.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.	Colors No. Affiliation yes	P9. Sec. 3	Heiko	Yes
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.	Still Open?
16	https://forge	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.	No	P.32 Section 7.2,7.3	Heiko	Yes Both P.32 & P.41
17	https://forge	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.	No	P.39 Section 9.4	Heiko	Yes
18	https://forge	Inconsistent use of expiration / termination	Jon MacLaren	Being Discussed	Superceded by subsequent discussion on lifecycle which is to be addressed.	Yes, However, in section 4.1 it says It is RECOMMENDED that TerminationTime be greater than or equal to the ExpirationTime in this usage scenario. Is this really correct? Also in Introduction etc says termination of Agreement rather than expiration of Agreement	P.14 Section 4.1	Cf.5	I did change greater than equal to to equal to, but perhaps we should really clarify why it need not be equal to termination time but is RECOMMENDED that it be equal..=>Propose deleting quite a bit of the material as they were confusing. Move into primer rather than keep in the normative part?
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.	Mostly reflected There is still a astatement in Section 4.2 saying We define two types of terms: service description terms and guarantee terms.	P.15 Section 4.2.1	Heiko	Yes
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.	No.	Appendix 5	Jim	Not yet
21	https://forge	comments about Section 7 (run time states)	Tiziana Ferrari	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.	Not complete yet I think..	P.31-- Section7	Asit	Yes
22	https://forge	definition of compliance in Section 6	Tiziana Ferrari	To Be Discussed		Not done yet, also, there are strong opinion on whether the compliacne is OK or not	P.31 Section 6
23	https://forge	Language problem in Section 5.1.1	Tiziana Ferrari	Resolved(7th Mar)	**Action: Corrected by Jim on-line.	Yes		--	--
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.	Has she been contacted?		Jim
25		Occurance of AssessmentInterval in Comp.Type	Heiko Ludwig	To Be Discussed		??		--
26		TerminalFault	Tiziana Ferrari			??		Toshi	Yes
27	https://forge	Agreement name optional	Mike Fisher	Resolved	**Action: Add some text saying that the name is not a unique identifier, and that it is there for the purpose of "readability" of the agreement document. Heiko to add this comment.	No	P.12 Section4	Heiko	Yes
28	https://forge	Consistent approach to Term Compositors	Mike Fisher		Not change had been the decision.	--		--	--
29	https://forge	Guarantee Terms	Mike Fisher	Resolved	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.	No	P.15-16	Heiko	Yes
30	https://forge	Include base objective set for web services	Asit Dan			??
31		ServiceProvider / ServiceCustomer explicit	Heiko Ludwig	Resolved(23rd Feb)	cf Entry 8	No		Heiko wrt. Guarantee terms	Yes
32		Obliged party attribute for terms	Heiko Ludwig	Resolved(23rd Feb)	cf Entry 8	No
33	https://forge	Explain service reference use better	Heiko Ludwig			No
34	https://forge	Refining scope of Guarantee Terms	Heiko Ludwig	Resolved	**Action: Add as suggested in the comment. Heiko to do this and add the text.
35	https://forge	Guarantee terms for best effort systems	Heiko Ludwig	Resolved	We're not sure right now how to specify that in a useful way, and the spec. already really covers the case, so we don't expect to make any changes on this right now.	--
36	https://forge	Business Value Table	Heiko Ludwig	Resolved	We'd rather wait until we have more experience rather than introduce this now since it is a conveince thing rather than a required thing.	--

Other issues being Discussed
37		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.	Resolved?
38		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?	Resolved?
39		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.			Toshj	Yes
40		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.			cf.26	Discussed with Karl, current tendency is to leave it as it is for the moment as 1)We should not be too restrictive in the spec 2)The WSDL model has implicitly "open content" on faults, e.g. faults can be generated that are not listed in the WSDL definition of an operation. However, the tooling typically only generates nice/appropriate mappings of fault to programming language exception types when the faults are listed in WSDL and following some primitive typing model. These are the only ones which might be nicely exploited, say, in a "try/catch" programming style to dispatch different error-handling mechanisms.
41		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.			Asit to send text to Toshi	Please send…
After GGF14
42		Complex Constraints If I want to write onormore of A, B, C in the Creation constraint, how can I do it ?	GGF14	Being Discussed in the ML	Heiko brought up the typeDefParticle asks for all, choice and sequence, plus group as the top-level element. nestedParticle allows us to define a element straight away - and its type. The types localElement or topLevelElement would just allow to define an element, which could be good enough
43		the placeholder of the WS-RP properties for the SDT's. What had been raised was, "In most cases, if we use the AGreementProvider = Service Provider model, then most of it should be OK by assuming that we can look into the Agreement Provider for all the resource properties of the Agreement SDT's, but if sometimes we use the Agreement Provider as service client, this model might fall apart.." I	GGF14	To be discussed
44		Chapter 7 Runtime states has 7.1 Agreement States 7.2 Service Runtime States 7.3 Gurantee States Which is fine.. on the other hand Section 9.5 Port type wsag:Agreement State only has 9.5.1 Resource Property wsag:ServiceTermStateList and 9.5.2 Resource Property wsag:GuaranteeTermStateList only. Perhaps another resource property named wsag:AgreementState is necessary?	Toshi	Being Discussed	Add 9.5.1 before the current 9.5.1?