OGSA-DMI Telcon - 20/06/07 ========================== Attendees: Mario Antonioletti, EPCC Steven Newhouse, Microsoft Michel Drescher, Fujitsu Notes: Mario Antonioletti Chair: Michel Drescher 1) Early discussion (15 min) - Note taker assignment - Roll call - Telecon minutes approvals - 6 June: http://forge.gridforum.org/sf/go/doc14598?nav=1 - Action item review - Agenda bashing 2) Example Use Case (Steven, Mario, 20 min) http://www.ogf.org/pipermail/ogsa-dmi-wg/2007-June/000191.html 3) Functional Specification (all, 25 min) Current draft: http://forge.ogf.org/short/OGSA-DMI-WG/spec 4) Wrap up AOB Actions Arising: [Michel] Change the permissions on artifacts page for DMI so that non-admin folks can actually enter artifacts. [Michel] Come up with a use that motivates the inclusion of the DMI metadata inside an EPR. +--- 1) Early Discussion Note taker should put up any actions arising from a call as trackers. Telcon minutes from the 6th June were approved. Proposed semantics for actions statuses proposed by Michel http://tinyurl.com/2o5t3b accepted. Review of Actions (posed as artifacts). Outcomes are as on Grid Forge. Question as to whether we should encapsulate DMI metadata in an EPR by Steven as opposed to decoupling this from the EPR (more on this below). Discussion of the full undo strategy artifact. Originally this arose of documenting what was required of a MUST requirement. Leaving artifact as open to review at a future point. Identity issue - Allen has emailed the security chairs to check if there is any prior work on this. Group feels slightly uncomfortable about proposing our own framework. Steven Newhouse thinks we should remove identity from the spec. An item for future discussion. A number of actions need to be assigned. Discussion about having a face-to-face meeting. Steven could try to host a meeting on the Friday before OGF21. It could also be made part of the next OGSA face-to-face - try to build consensus between us and the other OGSA members. Item will be discussed next week. 2) Discussion of the Use case document See http://tinyurl.com/2w75df (pdf version). Document tries to generate use cases to drive discussion on usage of the Data EPR. First scenario attempts to move a file from one file store to another. Have an unspecified service that maps a logical name to a data EPR on to zero or more real file names. This incorporates a security token. The DTF sorts out the security to access the source and sink. When the user connects to the file store to get access to a file a service there can generate the information about transport protocols supported and what security mechanisms should be used to access the data. This is then used by the DMI service instances. There is a question however as to how much knowledge we can expect from third party services to know about DMI. A second use case allows you to map to a data EPR without obtaining any information from third parties. Michel feels uncomfortable about this use case as he wanted to veer away from people being able to decorate the Data EPRs themselves. Steven questions whether this information should be in the EPRs in the first place. The EPR is a WS description of these files. These identify the data and the protocol. This assumes that a WS is going to access the data. Need to define where we change from a WSs orientated language to a concrete data transfer. GridFileSystems should be able to provide this kind of information if required. Question is why should DMI get this information through an EPR as opposed to information outside the ERP. Need a use case to motivate this - Michel actioned to do this. [Michel] Come up with a use that motivates the inclusion of the DMI metadata inside an EPR. WS-Naming could be used by us - WS-Data Naming could go down the same data route: logical data -> actual data mapping with access protocols could be embedded as the EPR or it could be a complex data structure that could be passed outside the EPR. Question is why this information has to go inside the EPR. For scenario 2 assume that there is a DMI client tool, dmi-cp, that does not require information from a third party. A very simple use case. Motivation: this would present an abstraction to talk to SRM or RFT type services through the same client. Time run out. Interested parties Sshould review the changes that Michel made to the document and comment. Should try to have a version of the document ready for August (if we have a face-to-face then). This is important so that DMI can be used by other groups, e.g. HPCP are beginning to do some work on transport and file staging - we need to have something ready so that they do not come up with their own framework. Aim for a near-ready document for August. +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+