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.