DMI Telcon - 24 October 2007
============================

Attendees:

	   Steve Newhouse, Microsoft
	   Mario Antonioletti, EPCC
	   Allen Luniewski, IBM
	   Ravi Madduri, ANL

Agenda:

1.       IPR Notice
2.       Previous Minutes and Action Review
3.       OGF21 Review
4.       What Next?
5.       AOB

+---

Actions:

[Ravi] Resolve minor comments on the spec.
[Ravi] Come up with a proposal on how to represent data aggregates
       (e.g. multiple files) with Data EPRs to the mailing list.
[Ravi] Come up with a proposal for a multiple retries property to the 
       mailing list.
[Steve/Michel] Come up with a proposal for Data ERPs that can deal with
       the three scenarios proposed below.

No notes were taken at the OGF21 session.

Ravi does not have time to look at the document at the moment so
Steven will take the write token to extend the Data EPR section 
to deal with the scenarios below. 

Ravi will then resolve some of his own minor outstanding comments in 
the spec. In addition Ravi will propose how the spec can specify:

   Number of retries to do a transfer.
   How Data EPRs can be used to represent data aggregates, in particular
    multiple files (though it should not be file centric).

OGF21 - re-opened the discussion on the level of abstraction to be used
to represent data and how to resolve source and sinks.

Ravi is concerned that current representation of Data EPRs is too
abstract and requires at least an additional operation to resolve the
data EPRs to files. This would add unnecessary overhead - a more
explicit representation of the data to be transfered is desired. In
addition, there is nothing out there that currently implements the name
resolution already so we would have to specify this and require 
data providers to implement in order for DMI to be useful.

Allen is concerned that this might make files special in the DMI
architecture which would be highly undesirable.

Steven discussed the above with Michel in Seattle and the thought that
the present architecture could handle all three use cases without
having to refactor the DMI document, mainly:

1. The Data EPR could contains a URL which would represent the
   transfer protocol, for instance ftp, and the data, e.g. a file
   that is to be transferred.

2. The Data EPR could could have information specifying multiple
   supported protocols that the DMTF would have to negotiate with the
   data source/sink to find the best protocol for the data transfer.

3. Have a logical Data EPR that would have to be resolved to obtain
   information about the data that is to be transferred and the supported
   protocols.

Steven/Michel to substantiate this proposal for the group to consider.

Other OGF points 

Ravi talked to Erwin Laure at OGF - one of the things that would be
desirable is for DMI to provide a reference model for RFT, FTS, RDF,
srmcopy and SDF to look to similar to each other in terms of the
inputs and output and behaviour.

Michel & Steven had some more DMI discussion at the OGSA f2f - got
some comments there - will be in the OGSA f2f meeting minutes. Largely
the comments were positive - there were no objections.

We need to get a period of stability in the spec in order to be able
to produce some implementation and come together to resolve any issues
afore the spec goes to public comment.

Steven mentioned that some security stuff came up - The HPC Basic
profile is currently looking at activity credentials - passing
credentials to do things like data movement on behalf of a user -
there is some recognition that the DMI use case for credentials is
very similar to the HPC Profile. Can try to leverage off any
HPC Profile work on this work. Not worth blocking on but it might be
worth reconsidering after the DMI implementations phase.

Mario will not be able to make the call next week.