* Data session -------------- ** DAIS - Alignment with OGSA doc Globus+IBM and DAIS worked things out prior to GGF. There was no obvious difference between what's in the OGSA document and the DAIS presentation. Comment: DAIS started from RDB but has grown to cover various data sources, e.g., XML and files, hence the overlap with GFS-WG --- see further down. Agreed: Keep watching. ** OREP - Building on top of what DAIS was; a bit out of sync at the moment. Might take a bit to come round. Because of their relation with DAIS we expect that they'll move over to current DAIS abstraction. (No action on our part.) Agreed: Keep watching. ** PA - Not clear yet if OGSA data abstractions are what they need. (Waiting for more refinement.) - They don't claim to be OGSA at the moment. - They are well advanced; they have stuff working. It will take them a while to 'come round'. - Agreed: Let them finish and then look into possibility for an ogsi/ogsa re-factoring. In any case it doesn't affect us too deeply --- mainly implementation from our point of view. ** GFS - Not clear that they want to build on top of DAIS. (SOA too complex for them at the moment?) - They seem to have narrower focus than desired (by us). Not well integrated with what's happening. (They want to support POSIX I/O APIs and (?) global name space services.) - Their 2nd BOF voted to make it a RG (23 for, 8 against) but that doesn't seem right. There are already products out in this space so it is not a new topic. - Agreed: Look at them again when/if they become a WG. * PE session ------------ ** GRAAP - Building on top of OGSI. Alignment with OGSA doc. - Agreed: We have to watch this space. In particular we need to really understand what agreement is, as it is creeping through the entire architecture. We should begin by highlighting all concepts of agreement that *we* are interested in and making sure abstractions are strong enough to be used throughout. - Comments: - It looks like there are still many issues not addressed. Work is in initial stages; needs refinement. - DAIS using agreement. Not sure if they are also defining agreement terms for data.(?) ** JSDL - Presentation not just on job submission description. Willing to explore OGSA role but also looking at other grid environments. - Presentation gave the impression that they are trying to tackle more than what their charter says. They are not. It is just job submission description. - GRAAP is strongly involved in the WG. DRMAA is also interested in it. - JSDL would also like to be used in non-ogsa/agreement settings. - Agreed: Keep watching. ** DRMAA - Interested in exploring role in OGSA. - There is no overlap between DRMAA & JSDL. Think of DRMAA as having defined a job template that can use jsdl inside. - So far the focus has been on legacy stuff. Finishing with C, java binding and may focus next on gwsdl (ogsi) binding. - Agreed: They are not affecting the architecture but the implementation. - Agreed: Useful to continue a dialogue. - Action: Andrew to look into bringing them into PE/Provisioning subgroup. ** GESA - Want to be part of OGSA. Exploring relationship with GRAAP & JSDL. - Dave mentioned Jon MacLaren (NeSC) workshop presentation. A summary of the issues covered there (and in other presentations) might make a good addition to Scheduler/PE section. - Workshop: http://www.nesc.ac.uk/action/esi/contribution.cfm?Title=309 - Bill: Is GESA in OGSA or on top, e.g., using OGSA? - Ravi: 2 perspectives - Agency that sells things in marketplace - Mechanism built in architecture - Agreed: Keep watching. - Action: Decide how they fit with us --- inside as part of architecture or on top. - Action: DaveB & Dave to make document (summary mentioned above) for inclusion to OGSA doc. - GESA uses WS-Agreement; WS-Agreement is part of architecture & GESA pushes down on their requirements; so they are engaged with us. - Mismatches: - WS-Agreement model - client initiates and server responds. But in GESA the other way round is also possible. Resources can bid for work. - Currently GESA is ogsi-compliant; looking for OGSA 'compliance'. - Action: Symmetry issue to be put to GRAAP-WG. Owner is probably GESA-WG but Dave to monitor. * Core session -------------- ** OGSA-SEC - Alignment with OGSA doc - Are there any holes between grid security and ws-security? - Probably, but not clear yet. - Is proxy based delegation included in the long term? Agreed: Since Frank had to drop out early skip OGSA-Sec and AuthZ discussion for next time. Agreed: Tell people in advance (on the list) that we'll discuss these topics and get them to join discussion. Agreed: Keep watching ** AuthZ - OGSI based. Agreed: Keep watching - Comments: - Is fine grain authorization (sde or port level or operation) in OGSI? - Not yet; But might have some capability (annotations) in WSDL-1.2 to extend operations. - SDE: could include info in SDE about visibility, access, etc. ** RUS - Want to be part of OGSA. Relation with UR, GESA. - Bill: Parallel (tactical) ogsi-compliance and (strategy) ogsa-compliance approach. - RUS is user of UR. View UR as more generic than job usage. - RUS is intended to be part of OGSA. ** UR - Content definition. No obvious conflict. - UR seems to be focused on batch jobs; what about network usage etc. - Nice xml schema for resource consumption of batch jobs - Group considers itself finished. - Does it belong in our document? - Need standard way to represent resource metrics - Put it in as informative reference to normative document. See [(*) Other discussion] further down. - Proposal: It might be an interesting to formulate it in our document as a resource usage event. - Agreed: We need something in this area and no group is doing what we want. * Platform session ------------------ ** CMM - Most work moved to OASIS-WSDM. Do gap analysis to find new niche. - CMM was spawned by OGSA. ** P2P - Working on requirements. Feedback to OGSA. - Agreed: OGSA should be able to support P2P. - So getting requirements is important. - Fundamentally OGSI can(should be) able to support this model; services are peers. - Agreed: Have to be careful that OGSA(?) service definition does not assume client/server model. - Comments: - P2P is wider than what's in this(OGSA-P2P) group. - Agreed: We have to re-visit this topic. Defer more general issues (e.g., asymmetry) to another teleconf or to the F2F. ** AA - ??