ws-agreement status

1

WS-Agreement Status

10th May. 2006

2

GGF Intellectual Property Policy

All statements related to the activities of the GGF and addressed to the GGF are subject to all provisions of Appendix B of GFD-C.1, which grants to the GGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in GGF meetings, as well as written and electronic communications made at any time or place, which are addressed to any GGF working group or portion thereof,

Where the GFSG knows of rights, or claimed rights, the GGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant GGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the GGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the GGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification.

3

Update since GGF15/16 2nd Public Comment Period

2005-10-18 –2005-12-18 12 Posts: Thank you very

much. 1st post had FIFTY EIGHT

issues All in all approx. 92=>106

issues (39 straightforward (grammatical etc) ,53 non-straightforward=>67)

Reflected the 39 straightforward issues.

Of the 53=>67 non-straight forward issues: All of them have been discussed. Some still need to be reflected on the doc.

Status is reported to the mailing list in an excel sheet.

4

Resolving the issues: Main consensus: (Policy is too strong a word.)

Requests for New Features etc.=>Priority is on getting the current draft nailed down. We hope to address most of them in the next version of the draft.

Discrepancies, missing terms will be handled in the current spec. We have updated references, tns name spaces, import definitio

ns to follow the newest spec. (Only the specs are moving target themselves..)

5

One Main Issue Re-Introduction of the Expiration (Cancel) Operation.

Reason: Needed for Book Keeping cases etc. Impact: Sometimes Expiration also takes a long time to be resolved.

=>Introduction of intermediary Agreement States.

Rejected

ObservedAndTerminating

PendingAndTerminating

Pending Observed

Terminated

Complete

OfferReceived

Agreement states exposed to an Initiator

6

More Comments/Discussion

Comments Discussion/Resolution

1 The main shortcoming of WS-Agreement for our needs in the Ontogrid project (which includes facilitating negotiation in VOMs) is the lack of support for negotiation. This is a two-fold shortcoming: 1) Limited Message Types and 2) No Interaction Protocols

Negotiation is outside the scope of the current

document, this has been put into the gridforge tracker.

2 Some of the defined terms are vague, confusing and hard to understand. For example, it would be helpful to have a clearer and more detailed explanation of the service level objective term. It is said that it contains assertions over service attributes that are domain specific for satisfying a guarantee. It would be helpful to have some sort of structure or meta-data to explain its relation with the Service Description terms. Given that the assurances over the services are expressed here, service level objectives seem to encapsulate the essence of WS-agreement which is to provide guarantees about service provision. It would be helpful to have some structure for service level objective rather than just anytype.

We need to add a couple of lines making the relationship of the template to the final agreement clear.

7

More Comments/DiscussionComments Discussion/Resolution

3 In section 5.1.1, the structure of an offer is not explicitly stated. It is unclear whether it has the same fields as the agreement template. (More..)

We need to add a couple of lines making the relationship of the template to the final agreement clear.

4 .Section 6, in the ws-agreement specification, about compliance is very vague about how an offer is compliant to an agreement template. Compliance is defined as ``each term of service described in the terms section of the agreement offer complies with the term constraints expressed in the wsag:CreationConstraints section of the agreement templat

e.''

We believe that the reply to Comment above will also clarify this.

5 When is the whole contract fulfilled? Is it when all the guarantee terms are fulfilled?

The contract is fulfilled when the state has transitioned to one of the terminating states. A common method for this to happen is for the expiration time of the agreement to be reached. The new termination operation is another method. It should be clear that an agreement, and its guarantee terms, can be an on-going relationship governing delivery of a service, so it is necessary that we have the state transitions and expiration as described above

8


6 It seems that a guarantee term has as field the set of services it applies to, it would be interesting to derive the complimentary, i.e.

the guarantee terms applying to a service.

We do not see the need for the symmetrical discovery of guarantee terms by service as it can be derived.

7 It would be useful to have a state transition diagram that define the various actions between the agreement and service run time states, for completenes’s sake

We consider the agreement state and the service state to be independent. For example, agreement creation does not necessarily mean that the service is created. Thus, it does not seem possible to have a state transition diagram that joins the service state with the agreement state.

8 Here the specification focusses on guarantees by the provider to the customer on service provision. However as mentioned in the specification, the customer may need to provide some guarantees to the provider for the latter to be able to respect the agreement. Where does this occur in the WS-Agreement process?

Customer obligations can come from the template,

or can be added by the initiator in to the offer, but all of the initiator obligations are in the offer. As for the qualifying conditions, the customer obligations (e.g. request rate) or the non-controllable ones (e.g. time) specify when the guarantee is applicable.

9


9 Compliance is needed on the part of the provider when sending his agreement. There should be a section to explain what is the structure of an agreement and its relation with the fields in an offer.

We need further clarification (a use case?) on this comment as we would hope that this is already addressed in the spec.

10 What is the relation between the service description terms, guarantee terms and the offer items and constraints in an offer?

We need further clarification (a use case?) on this comment as we would hope that this is already addressed in the spec.

11 On page 26, section 4.2.6.2, third sentence. I don't understand what part of the referenced document [XQUERYX] is relevant in terms of "a generic assertion language". Please elaborate more to clarify this.

Should we reference XQueryX at all? The consensus is no. To remove all references to XQuery.

12 According to the 3rd paragraph of chapter 1, An agreement includes one or more service terms. But the schema above allows an agreement with no wsag:ServiceDescriptionTerm,

no wsag:ServiceReference, and no wsag:ServiceProperties.

In my opinion, such an agreement may be allowed in the case that it is clear (between the initiator and the responder) which service the agreement describes.

Add some text to clarify

that when there are no service terms, there can also be no guarantee

terms since the guarantee term must refer to a service term.

10


13 For the current draft, if you are really intending to address thecondition expression language in a meaningful way in the next version,how about removing the suggestions that XQuery might be an appropriate condition expression language.

To remove all references to XQuery.

14 With a fresh mind reading, I am disappointed with the collapse of service term role information into a top-level agreement role.

It seems unfortunate not to support agreements where some services may be provided by each party to the agreement.

Consensus is that would we don't feel like

handling the complication of both parties providing a service in the first spec.

15 I could not find any statement about what is normative or what to do if conflicts are found between text, psuedo-schema, and

appendix schema. (Suggestion of the text to be added)

Agree.We'll use proposed text in the intro. to the appendix as it does seem to explain our intent

16 Handling of Name and FooId attributes: there still seems to be a mixture of string, QName, and NCName attributes. Do we have any well-formed rules of thumb regarding what we should be using?

Our intent will be to use string for Name type fields, and NCName for Id type fields. We realize this may cause

some difficulty with current, though early, implementations.

11


17 Main body explanation of attributes: I think it would be beneficial to always have the redundant "optional" or "mandatory" work in the text describing each /XPath/Referenced/@attribute. Is this a use for RFC-style OPTIONAL and MANDATORY?

Yes…Agreed, we should.

18 4.1 Agreement Context

Context psuedo-schema is broken and using "+" in three places it should be using "?" to indicate "zero or 1".

Yes…

19 4.2.3.1 Service Description Term Structure

Description of Name attribute should say OPTIONAL and preceding psuedo-schema should use "?" to mark this attribute optional. Description of ServiceName attribute should say MANDATORY.

Question: should we ever imagine a scenario where ServiceName should correlate across multiple agreements? In that case, QName rather than NCName is necessary.

We've made both Name and ServiceName indicated

as MANDATORY. For Name, we did this because they service

description terms are referred to by name in other places. We don't

feel like tackling the issue of cross-agreement consistency

w.r.t. the service names.

12


20 4.2.4 and 4.2.5

Very redundant text says "this set of service properties" and "service description terms" to describe attributes.

We agree that it is redundant, but we like

having the clarifying text here rather than requiring the reader to refer back to the partent type.

21 5 Agreement Template and Creation Constraints

Should /wsag:template/@TemplateId be string or QName?

We'll use the Name and Id types we agreed upon in row 27.(No.16)

22 5.1 Creation Constraints

In Template psuedo-schema, "?" should follow closing tag rather than opening tag of CreationConstraint

Agreed, and done.

23 5.1.1 Offer Item

Is the Name attribute capitalized or not? NCName or string? The main body and appendix schema are inconsistent on these points.

Name attribute description should include MANDATORY and also clear MUST be unique statements.

Location attribute description says "value currently set" and I think this should be rephrased as "value set at the addressed template location".

Agreed, and done.

13


24 5.1.2 Free-form Constraints

Intro paragraph says "this specification does not define a constraint language" and then the text immediately defines XQueryXConstraint in the wsag namespace!

Delete All references to Xquery.

25 8.2 Forms of Acceptance

8.3 Forms of Rejection

When the text says the responder MUST invoke Accept or Reject operations, what should he do if an error is detected?

MUST retry? SHOULD retry? Undefined?

In rejection, MAY responder return a fault to createPendingAgreement AND also invoke Reject if an AgreementAcceptance EPR was provided?

We agreed that even if accept fails, the

agreement is still accepted, and the initiator must query to find out the status. It would be up to the responder to use other mechanisms like signing or reliable delivery if they do not want to risk accepting an agreement that comes from an invalid source.

26 9 Port Types and Operations

In initial use-case enumeration, rephrase (5) where it currently says "With either basic or asynchronous deferred..." to read

"With either polling or callback-based deferred..."

Same place, where it currently says "management in addition to decoupling", change to read

"management as in symmetric case (2) in addition to decoupling"

Agree

14


27 9.1.1.1 Input

9.2.1.1 Input

Remove and rephrase around some stray "EPR1" and "EPR2" labels which are no longer in psuedo-schema and which are confusing.

Use full element names, e.g. AgreementAcceptanceEPR instead.

Already been taken care of

28 9.4.5 Resource Property wsag:AgreementServiceReferenceList

This test is very strange, written in "negative logic". I am not sure I understand what it is really trying to assert, but suggest this wording based on my best effort to interpret:

"The property MAY be empty and some services MAY be omitted."

Agree

29 Appendix:

Types XSD Haven't we decided to delete the ContinuingFaultType definition already?

We'd like respond about whether there's

still a need for the ContinuingFaultType, if not, we'd like to delete.

15

Where Are We? Almost at the end of finalizing the proposal. TODO’s

Add explanatory text to address the comments eg. Stating the relationship between template and created agreement i

n a more straight-forward manner. Clarification on the guarantee term state cover simple use case of expressing a service level target.

Check the XSD/WSDL in the appendix and also try to align with the newest spec of WSRF etc.

ws-agreement status

Documents