All, Attached are minutes from the last two telecons, on the 14th and 23rd of Feb. These deal almost entirely with handling comments we've received. Please not all Actions captures (with ** in front of them), and where ownership is explicit or implicit, update the entries in the tracker related to the comment. That tracker is at: https://forge.gridforum.org/forum/forum.php?forum_id=461 We will resume our usual Mon. call times starting next week which would be 4:00 central time in the US. A reminder on that is hopefully forthcoming. --- Jim Minutes from Feb. 23 '05 Teleconference Attendees --------- Takuya Araki Heiko Ludwig Jon Rofrano Wolfgang Zeigler Toshiyuki Nakata Asit Dan Agenda ------ Public comment period is over. Issue 8 (continued from last time): Much discussion about roles and which roles need to be specified explicitly in the context. Result is that this is a two-party agreement only, so the agreement initiator and provider define those two roles. This validates the definition of those two roles in the context as currently defined. **Action: We will augment the guarantee terms with which party is obligated and the obligee for each guarantee by role (initiator or provider). Also implies a response to issue #32. Now that obligation is specific, there's no need for the AgreementInitiatorIsServiceConsumer flag in the context. Issue 9 (and issue 14): Asit: Things we use are a matter of "public record" in the sense that it is visible to everyone. Toshi: But can we not use the information in them without naming them explictly. **Action: 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 (section 1.1.1). Remove the MAY be composed entries. Add column where we are explict about version that will be used. (Revisit this at beginning of next week). Minutes from Feb. 14 '05 Teleconference Attendees --------- Toshiyuki Nakata Heiko Ludwig Jim Pruyne Takuya Araki Asit Dan Agenda ------ Issue 2: Decided not enough participants to fully address the asynchronous binding issues on this call. Issue 3: 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. Issue 4: on how do we know that terms are fulfilled? 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. Issue 5: On why is expiration time part of the context? Agreed that it is not safe to always assume that it is provided as part of a higher-level structure such as a WSRF service? So, if needed the expiration time should be part of the agreement document. So, why in the context instead of a service description term? Asit: at least it does need to be defined how one fills in this field. Heiko: Also, it doesn't apply to the service, it applies to the agreement, so it isn't really a "service description term." **Action: leave it in place, capture this discussion, add justifying statements to the document. Issue 6: ZeroOrMore needed? Should this be provided as an additional cardinality in the compositors? This is adopted from WS-Policy, should we stay in synch. with it? What scenarios exist that support the use of ZeroOrMore? We also don't support arbitrary cardinality choices (e.g. "2 out of 5"), so we already don't strive to handle all of these. **Action: Leave it as is unless someone can come up with a strong use-case supporting it. Issue 7: Too complex. No easy way to address this. We can take this as a guiding principle as we address other comments. Also, it can be a statement on the type of presentation, and a more readable doc. (primer) is needed. 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. Issue 8: AgreementInitiatorIsServiceConsumer why is this here? Heiko to give a specific proposal/use case where this is needed.