ࡱ> TVS5@ C.bjbj22"HXXC&JJJJJJJ^4,^6~RRRRRRRR6 6 6 6 6 6 6$8RX:-6JRR-6JJRRB6JRJR660JJo2RF ,.6#16X606916:kj:,o2^^JJJJo2:JG5R0"RRR-6-6^^DD^^Notes GRAAP-WG 03/12/04 (Berlin)Meeting minutes by Kate, Philipp, Wolfgang, VolkerGRAAP-WG Session #1 Presentation of the GGF IPR statements, circulation of sign-up listPresentation of suggested Agenda Volker presents the status of the group and work done, (slides available on the GRAAP web pages)Question (Jon): has the WG an agreement on wsrf? Answer: no agreement yet, discussion could happen during the 3rd WG session today.Service Provider is considered not being significant enough to express which side took the initiative. It is decided to use Initiator and Responder instead. Kate presents a use case: "National Fusion Collaboratory", (slides available on the GRAAP web pages) Karl presents the "WS Agreement Overview"", (slides available on the GRAAP web pages) Question: Are there monitoring capabilities? Answer: general answer yes, but still discussion necessary. Question: Is the agreement still represented as service? Answer: yes, could be ogsa or wsrf or ..., some "stateful" thing, anyway.No objections to the high level view that Karl presented. Heiko presents the "WS Agreement Document Structure", (slides available on the GRAAP web pages)Several question related to invariant:Question: Is the termination time invariant? Answer: This would lead to a chain of invalid Agreements which would be precondition of the last one that was changed.Conclusion: Remove termination time from the list of invariants.Question: Are parties invariant (look at economic models)? Answer: parties to agreement are not necessarily service users. Question: May agreement contracts be delegated? Answer: The spec does not prevent this. Delegation could be integrated into the domain specific part of the agreement. Discussion continued in session #2GRAAP-WG Session #2Presentation of the GGF IPR statements, circulation of sign-up listAlain presented Port Types & Operations, (slides available on the GRAAP web pages)Question: Why so many factories? Answer: You choose one of the factory models.Question: Why so many design variances? How can we be sure that the consumer and responder choose the right one during run time? Answer: Will get a fault when contacting the wrong factory. Symmetric Negotiation is handled in the next spec, but not at this meeting.Agreement Factory:What about negotiable constraints terms? Which options where choosen? Output of EPR should be added by a kind of shortcut for not to have to explicitly query the Agreement, particularlyWhy EPR anyway? Wouldnt be a by-value approach in which you returned a signed agreement be more appropriate? Could make life easier? Would it be redundant information? Conclusion: Add an optional flag to decide wether to get a copy of the complete agreement returned (potentially signed) or the EPR only.Negotiation Factory: Clarification: Square Brackets mean optionalAgain discussion about reference or value -> optional agreement Operations: Input is an agreement with constraintsThe issue counter offer relation to state diagram (transition of states): state observed & counter offer -> re-negotiation was successful.Context should be static, negotiable terms should not be in the context.Returning the state gives information on the progress.Questions related to WS-RF questions are deferred to GRAAP sessions #3..State Diagram: Question: Wouldnt it be more appropriate to have two state diagrams for initiator and responder? Answer: Problem is that one would fall back into the single one.Dashed lines initiator sends, full lines responder.Right-to-left are fault paths.Upper gray line needs to be dashed Gray line is the response to the final commit Advisory state needs dashed line as well. State diagram will be revised in next version.Multiparty-agreements would currently covered based on a hierarchical model, true multi-party agreements (relational model) are not proposed in the spec (i.e. it focuses on two-party agreements that can be structured hierachically). Will need a use case for multi-party agreements from the community, then this could be discussed and possibly enter into the spec.Agreement LayerRelationship between between agreements need to be modelledbetter. GRAAP-WG Session #3Presentation of the GGF IPR statements, circulation of sign-up listAlain concludes his presentation from previous session. Discussion with the audience on what context is: the current definition is that it represents all the invariants in the agreement (parties, etc.)Heiko starts his talk on issues (slides available on the GRAAP web pages).Are offers and agreements different in structure? We agree on offer = everything except context. Revision of the issue of whether agreements are transferable. The general question is can an agreement be delegated/transferred to somebody else? Proposal: irrespective of renegotiation the initiator field stays in the agreement as originally set, but the agreement may define a class of people who can renegotiate an agreement. This definition is reflected by domain-specifc terms. Similarly, terms may define rules for claiming an agreement (for example, it may be necessary to present a token defined by terms in order to claim). We reach consensus that delegation or transferability has to be reflected by terms. What is in Context? A fixed set of parties. Should it also answer some questions like who will provide the service etc.? Proposal to take EPR out of context (it certainly is not an invariant); it should appear in service description terms. The question is: what is left? Maybe we can get rid either of context or of the restriction that it be invariant? Heiko presents the variable definition section. Issue: should this section go into the service section or in a separate section. Resolution: we put it in guarantee section. How do we monitor service state? Heiko proposes: service is not ready, ready but it has not started, it is processing (busy), service is completed. Discussion of this model: is it really general? Issues: granularity, ongoing service, service is aborted by the requestor (is it then completed? normal and abnormal completion). Unresolved (?). Issue of context under which the agreement has been negotiated revisited. It would be good to have a set of conditions under which agreement could stay valid. Again, it seems that these should just be terms.Heiko presents the description of guarantee terms and state model for guarantee: not determined, violated etc. The question is do we want to expose guarantee states. Kate is against: to meaningfully expose guarantee states would imply a monitoring model which we agree is not going to be a part of WS-Agreement. Exposing guarantee state without assurances of whether suitable monitoring is in place or not in a given implementation is meaningless (we dont know if there will be reasonable grounds for returning any particular state or what that state really refers to). Therefore even though there will be standard ways of getting informed about the state of guarantee, the meaning of this information will be still implementation-dependent, so we might just as well make it an implementation-dependent feature. Putting it in the spec will clutter up the spec which is dangerous (to many unnecessary things = spec unnecessarily too hard to implement). Karl says he would still like to have a standard way of accessing this information (which he will evaluate in the context of specific implementations). Kate, outnumbered, reluctantly caves. We agree that we are going to expose guarantee states. Constraint languages. We dont want to define a constraint language but may want to recommend an existing one. Discussion on merits and demerits of various systems, xquery deemed immature xpath also proposed (xpath?).Heiko presents on renegotiation. Kate brings up an issue: when does one agreement (old) end and the new (renegotiated) begin? (also: do we have two sets of terms during renegotiation, the old one and the renegotiated one, what state is the agreement(s) in, etc.). Alain: there are two states: negotiation state and agreement state the agreement state is observed and stays observed, the negotiation state changes. This answers state question. Alan: but we do need to carefully specify synchronization issues, i.e., when the renegotiated parameters will be effective. Alan signs up to start a thread about it on the mailing list. The proposal is to require that renegotiation specifies conditions for term substitution (this may be a matter of terms but there definitely should be ways of specifying such terms to make renegotiation meaningful).Jon brings up an issue: WSRF. Do we use WSRF in WS-Agreement spec or not, do we decide to be dependent on WSRF? Will the spec be dependent on WSRF? Because if it will, that may effect the work of GRAAP, not just WS-Agreement but also other documents (reservations etc.) By that time there are no chairs in the room (although lots of surfaces to sit on ;-) and we agree to postpone this discussion. Jon signs up to start a thread about it on the mailing list.Another issue: specification slicing and dicing. Instead of having one large document containing everything anybody has ever thought of, we should have an organized set of documents laying out the model (an overview of agreement) [Kates comment: not to confuse with the primer which should be more of a tutorial] and then separate documents for the respective parts: negotiation, terms structure, etc. Karl: negotiation part could be abstracted. What is the timeline to GGF recommendation? Heiko signs up for starting a thread on the mailing list.We conclude with some grumbling on how bad the web site is and no volunteers to fix it.!KLTUik  2 3 4 < > ? D R e k  G P Q Z [ ] m u v x y ͺͮŦŦśՓՓh#$mH sH h-7mH sH h(hz@mH sH hz@mH sH hhH*mH sH h(hmH sH h{mH sH hmH sH h(h(mH sH hz@h(5mH sH h(mH sH h9QAh-7h(6!TUik3 4 [ ]   D F u1gd{gd(C.   / I O y   C D F G K Y [ ] ^ g h i q r { /·ʔh(hhmH sH hhmH sH h(h{mH sH h{mH sH hmH sH h(h>mH sH h>mH sH h(mH sH hdmH sH h#$mH sH h(h-7mH sH h(h(mH sH h-7mH sH 6/03AKacl}<>Z[l   xxxxmh(h(mH sH h(hmH sH hmH sH h(hmH sH hrhrmH sH hDmH sH hrmH sH h(h(hmH sH hmH sH hz@h(5mH sH h>5mH sH h(mH sH h>mH sH h(h(mH sH hhmH sH (13Z[  I #Pgd2gdgdrgdgd(     @AQ-7!#MP>⿴Ⱜhz@h(5mH sH h(h(h(h1mH sH h1mH sH h(h2mH sH h2mH sH hmH sH h(h(mH sH h(hmH sH h(mH sH >R-#w=>N'(gdgd(gd1gd(gd2&'(8Ji(28N`fjt~ -L679-/K_cfz? @ A I  !!ǿϻϻϻϻϻϻϻϻϻϻϻϻϻhLlih^:h"hNhh1mH sH h1hUhp{h7"h(hmH sH hmH sH hz@hz@5mH sH h(5mH sH Cij89@ A !!%%&&))++--;.gd^:h^hgd^:gdNgdp{gdU!5!D!I!]!!!"""%%%%&&&&''=(|((((&)j)o)p)* ***3*a*b*f*****++++++,P-|----:.;.=.@.A.B.C.hUh^:hth9hnNhYihOr3hyihjwhFhhpWhZhLlihN;;.<.=.>.?.@.A.B.C.gd^: 1h/ =!"#$%D@D rStandardCJ_HaJmH sH tH JAJ Absatz-StandardschriftartXiX Normale Tabelle4 l4a 0k0 Keine ListeC&H!TUik34[]  DFu13Z[  I # P R -#w=>N'(ij89@A!!##%%;&<&=&>&?&@&A&B&E&0000000000000000000000000000000000000000p00000p000000000p0000000000 000000 0000p0p0p0p00 00 000(00 0p0p0p0p0p0p0@00000p0p0p0p0p0p0p0p0p00p00p0p0p0p0Ti34[]DF13Z[  I # P R -wNijE&@0@0O900``0O900O900O900O900O900O900O90 0O90 0Oy00O900`hO900O900^>00^>00O900`ܥO900O900^>00M900M90 0@0Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00Oy00@0@0@0@0@0@0@0@0O900@0^>00^>00 0+T^>00^>000r^>00^>00  / !C. "1;.C.!#C.ZAZA"ZA E&E&9*urn:schemas-microsoft-com:office:smarttagsState9*urn:schemas-microsoft-com:office:smarttagsplace8*urn:schemas-microsoft-com:office:smarttagsdate 1220043DayMonthYearKL!#MP=E&!SF3c[   H I " # O P Q R ,-"#vw<>MNj?= !!""E&!S[  # P >NE&CKE&Herr Z.yҨB&0k (+ cl2! [J^@PN)1^Up>^ _Z_ ^`OJQJo("  ^`OJQJo("  pp^p`OJQJo("  @ @ ^@ `OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  PP^P`OJQJo(" ^`OJPJQJ^Jo(-^`OJQJ^Jo(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoPP^P`OJQJo(hH pp^p`OJQJo(" ^`OJQJ^Jo(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoPP^P`OJQJo(hH^`o() ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. ^`OJQJo("  ^`OJQJo("  pp^p`OJQJo("  @ @ ^@ `OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  PP^P`OJQJo("  ^`OJQJo("  ^`OJQJo("  pp^p`OJQJo("  @ @ ^@ `OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  PP^P`OJQJo("  ^`OJQJo("  ^`OJQJo("  pp^p`OJQJo("  @ @ ^@ `OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  PP^P`OJQJo("  ^`OJQJo("  ^`OJQJo("  pp^p`OJQJo("  @ @ ^@ `OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  ^`OJQJo("  PP^P`OJQJo(" +&0y1^Ul2>^J^@ (+z@9QADZs`YiLli4 nrjwp{FN"(tU Lyi^:m{d91nNhK9@LLxEELLC&P@UnknownGz Times New Roman5Symbol3& z ArialK& 'Frutiger 55 Roman?5 z Courier New;Wingdings"1hfT&@@y#r4d%%3Q H)?4 n Notes GRAAP-WG 03/12/04 (Berlin)Wolfgang ZieglerHerr Z.,        Oh+'0 , HT`hpx!Notes GRAAP-WG 03/12/04 (Berlin)icroteWolfgang Ziegler/12olfolf Normal.doteHerr Z.6rrMicrosoft Word 10.0@'@e6՜.+,0 hp|   @%A !Notes GRAAP-WG 03/12/04 (Berlin) Titel  !"#$&'()*+,-./0123456789:;<=>?@ABDEFGHIJLMNOPQRURoot Entry F?6W1Table%;WordDocument"HSummaryInformation(CDocumentSummaryInformation8KCompObjj  FMicrosoft Word-Dokument MSWordDocWord.Document.89q