- Etienne (E)
- Moreno (Mo)
- Morris (MRi) - Minutes on behalf of Johannes (in flight)
- Steven (SN)
- Oxana (O)
- Aleksander (AL)



##### Most recent document
- Mo: can be found on Gridforge - Input Document, Execution Service, Version 2 (by Oxana)
- Mo: Agenda addition from Etienne: HPC File Staging Profile
- MRi: Please add review old minutes as the first item

##### Review old minutes

- MRi: Goes through the MINUTES identifying follow - up ACTIONS:
- MRi: OGF Sessions: 1 data - 

# Andrew GrimShaw - TODO: Write some notes about data push discussions



##### Better title for the document
- Mo: new title should be provided

# TODO: Mo - Think about a new title


##### State Model Discussion
- Mo: Review strawman version 0.2 - 5.1 State model
- Mo: Two additional states: staging-in and staging-out, derive the need for (manual) data-staging (see above in the 
document)
- Mo: Single running state is not enough, idea here is to specialize to provide additional information, whether the 
service is staging data
- Mo: better describe the status of a job delegated to another service
- Mo: delegation is not only the local RMS but also another component
- Mri: Suggests that we take the job forwarding instead of delegation (term from security)
- Mo: WMS -> to CREAM -> to Local RMS is in gLite a forwarding chain
- Mo: Sub-states according to chain necessary to really identify the status, increase the granularity
- Mo: ChangeActivityStatus - we have to explicitly define which status changes are feasible and which are not
- E: It can be interesting to refine the running state - but when implementing changeActivity then it is rather 
complicated to define each case (which one are illegal)
- MRi: Maybe it makes more sense to define ONLY WHAT IS Allowed instead of what is not allowed (maybe easier - and 
probably less)
- S: State diagram more complex then you have to be very clear which one initiated from the service - or which can be 
initiated from an end-user agent/client
- MRi: Everything is illegal - only a FEW are allowed
- S: classify which state changes can be initiated by user-initiated state transitions
- Mo: One external interaction from the user would be the (manual) data-staging use case affects the model
- E: Forwarded is needed, Assigned might be ok - both might be beneficial
- MRi: Assigned and Forwarded might be the same, because assigned to RMS is noth enough -> Substated idea!
- O: not everybody has to implement everything
- Mo: Can we agree on Forwarding instead of Assigned
- S: File Staging profile - state model becomes a discovery model - which implies the use of a more refined state model
- S: Make the state model discoverable...
- S: GetFactoryAttribute Operation -> Document that you can search for BESExtensions with URIs to support the 
filestaging, which implies the model states going with it
- S: URI points to specification that is implemented
- Mo: other extend our state model
- MRi: Not too modular otherwise we run in interop problems again, with n profiles that one supports or not...
- S: Getting agreements on the state model is one of the most complex processes - start ASAP


# TODO: O - exchange delegation with forwarding in the strawman, and assigned with forwarding
# TODO: M - a more refined state model showing transitions that are legal - ASAP!
# TODO: All - Should everybody adopt every state (maybe 1st level)?! Mandatory?


##### Job Description
- Mo: Going through the 5.2...
- Mo: Many JSDL elements simply ignored (by CREAM)
- Mo: Users should indicate some as optional - and others mandatory (not ignorable!) -cp. mustUnderstand
- Mo: no Ranges - are too simple anyway - so not used anyway currently - plan to get rid of it
- Mo: Avoid overlaps with GLUE2, which should be used with our service


# TODO: All - Discuss the document of Etienne on mailing list


##### Next TelCon
- next week on Wednesday -> 6.5.2009 - 16:00...