[ogsa-dmi-wg] DMI Telcon Minutes - 20/06/07.

[Michel Drescher]

Hi Mario,

thanks for that. I checked the tracker settings and changed them as follows:
- All users on Gridforge can see all trackers
- All logged in users on Gridforge can submit and view all trackers.
- All OGSA-DMI group members can edit/change trackers for OGSA-DMI.

I think that this should provide necessary permissions.

Cheers,
Michel


Mario Antonioletti wrote:
> 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 at epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ |
> +-----------------------------------------------------------------------+
> --
>   ogsa-dmi-wg mailing list
>   ogsa-dmi-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20070621/fb39c372/attachment.pgp