DMI telcon 16 May 07 ==================== Chair: Michel Drescher Notes: Mario Antonioletti Attendees: Michel Drescher, Fujitsu Steven Newhouse, In-Between-Jobs Mario Antonioletti, EPCC New Actions =========== [Michel] Figure where the data labelling goes in the ReferenceParameters or the Metadata and what the data and protocols are in a DataEPR. Agenda: 1) Early discussion (5 min) Note taker assignment Roll call Telecon minutes approvals Agenda bashing 2) Functional Specification (50 min) Current draft: http://forge.ogf.org/short/OGSA-DMI-WG/spec 3) Wrap up (5 min) AOB +--- Minutes from the 02/05/2007 telcon were accepted without change. Minutes from the session 1 at OGF20 approved. Minutes from the session 2 at OGF20 approved. Went over the changes that Steven Newhouse made to the spec. Kept the same model but streamlined the operations and properties. Issue on diagram 1 is that it is not editable for Steven's version of word. May also not work well on a black and white version of the figure - need to revisit. Question as to whether DMI is more of a control service rather than a transfer service, i.e. it does not transfer the actual bytes itself. It is agreed that DMI controls the transfer of the bytes but it does not do the actual transfer. This needs to be cleared up in the non-normative introduction. SN did not look at the security but it needs to be re-visited. There are some parts of this where there might be issues. Part of this depends as to how much of the security model needs to be put into the DMI document and how much could be put in a profile. Michel creates a tracker for this. In the operations created three acronyms: DTF for the Data Transfer Factory, DTI for the Data Transfer Instance and the DataEPR for the Data End Point References. DTF has two operations - an RPC like that requests a data transfer transfer and an operation creates a DTI (message style). These two modes of operation may not cohabit well. Question as to whether it might be cleaner to just use the message style (asynchronous) and remove the RPC style (synchronous) - the transfer of large data files (which could take a long time) might not be amenable to a data transfer type interface. It is agreed to remove the synchronous/RPC data transfer operation (requestDataTransfer). Need to clean up the text to take this into account. There are a number of properties that existed in the DTF that have been removed based on the OGF20 discussion. There may be more rationalisation to be done. Have an undo strategy - in the state model the changes that have been made may have an impact on this. Could have a default property at the DTF or it could be one of the options that are passed in the arguments. Problem with a default is that there probably is not global undo policy that will be appropriate to all transfer protocols. A DMI factory which is protocol agnostic could advertise what strategies it supports. If there are protocol dependencies then you might only support the least common denominator - but you may want to know all the supported undo strategies.... Could remove the undo strategy as a global property and instead have it as a parameter in the request the values of which can be selected on a case by case basis - you will know the protocols at the source and sink. If the client then request an unsatisfiable request the factory can fault. The factory still needs to advertise what undo options are possible but it should be a sub element under each of the supported protocols. Need to know the supported protocols and the relevant undo strategies for each of these protocols. The supported protocol element is refactored to take this into account. Supported protocols will be named using URIs. New protocols will have to be standardised in a new version of the spec or some intermediate spec or profile. Need to think about the security model and the re-evaluate the [identity] and [role] informational properties. Need to revisit. Section 4.2.2 can go out as there is no RPC operation anymore. The DataEPR was discussed and how it is represented in 4.2.3.2.1. Question about where the data is identified and whether WS-Naming should be used - a WS-Name is a profile on an EPR. Some issues have arisen within BES about the use of WS-Names. The data naming could go in the ReferenceParameters as opposed to the Metadata element. For MetadataSection does not get rendered into the SOAP header. Michel actioned to look at the possibilities. Discussion as to whether in the tns:Data element the attribute denoting the data should be named uri as opposed to url. Also may be good decouple the protocol and the labelling of the data that is to be transferred. Question as to how the DataEPR is generated. Need to determine what is specified regarding and not try to "define" too much to constrain implementations. An artifact is placed in order to note this generic issue. Some of the timing information parameters made sense - some of them do not. StartNoLaterThan and EndNotBefore seem to have no sensible use cases. Possible scope creep here with scheduling. Also StartNotBefore should be addressed by a higher level workflow. Agreed to remove StartNoLaterThan and EndNotBefore. StartNotBefore has a viable use case left for now. The undo strategy needs to be made consistent with the previous discussion. Through time constraints go to the state model. Remove the RPC style option. The Negotiating it goes to Scheduled or Unsatisfiable and once Scheduled it can be activated to be in a Transferring state - it can then be fail be suspend or succeed which reflected the discussion at OGF20. Concerned about having substates to Failed - Clean, Unclean and Unknown which is part of the status and not the state. These could be queried from the Failed state or have three potential substates after. Michel will modify the state diagram. Michel will post the modified version on GridForge and then try to produce another iteration of the state model.