PGI session 3, 14h Thursday.

Morris:
move from security,

define some actions
Action list:
1. Morris provides the community one document with the different security items inside that people know where to look at
, closer look at the documents (Monday, 9 March)
2. Ask the community to look at. Each production Grid should have a look at the document (Monday, 16 March) – reading, 
making comments
	Preferred track changes 
	In the GridForge documents section
3. Morris / Johannes: prepare the Telephone conference (Friday 20 March) having infrastructure input well provided
4. Community will review the document on Friday 20 March in the teleconf

Andrea: One week could be too short.
Morris: in case of making progress we should consider one week

Review of the basic use cases: and map to the documents
Morris: set of attributes on behalf of an authorized user
Balazs: should not break it into pieces
Andrew: simplify this further, what is the core of this to submit a job to the information service, what execution 
resource you are going to use
Laurence: we have to address the bootstrapping issue, contact n info service. Go through the easy things first? GENESIS-
II approach
Core is BES/JSDL/GLUE
Address the assumptions later
Balazs: the first profiles assume that there exists an epr
Morris: is glue involved in the first profile as well?
Balazs: GLUE is involved when you ask the info service
How to find an end point will be treated later.
Eprs will be covered in the second document.
The user does the staging, but execution serviced itself can do the data staging.
Oxana: Execution service can be staging service
Andrew: JSDL staging?
Balazs: yes
Andrew: file staging: SRM, Gridftp. Too short documents in gridforge.
We are users of file staging extensions.
Steven: logical filename is supported by the endpoint
Andrew: URI prefix tells what the prefix is
Balazs: Data staging was not discussed at the teleconferences yet
Morris: go back to the basic use cases, JSDL and OGSA-BES
Sergio: Do you need also GLUE?
Computing share?
Map the concept of GLUE on the back of BES.
Donal: In the simplest cas the user uses a single share. The information is in there.
Sergio: VO share for many groups.
Donal: avoid giving users control over this.
Laurence: Within a vo you have multiple groups. He can be admin or user. He may swap to another share.
Balazs: it is not just enough to know the endpoint, you need more information
Andrew: you want more than the basic use case. Need to spüecify a primary share, secondary share…. For accounting
Balazs;: not only about the shares
Balazs: What you need is information about the shares
Andrew: examine the resource and then  submit
Handle some simple use cases first
Oxana: it is Grid, so we have multiple resources
Sergio: How do you know details about a resource?
Andrew: A resources section in JSDL (suggestion)
Sergio: initial idea to integrate GLUE
Donal: Just send the job, you have the epr.
Balazs: know an epr, nothing else. We need to go to the resource to get the information. We do not get it from the 
endpoint.
Andrew:useful: no use-case which is vague… an example: we want to run a job with the following cdharacteristics. What 
is a typical, canonical job we want to run. This could help to make it concrete.
Definition of this concrete use case:
Donal: Concrete production use case!
Andrew: one parallel application
Morris: where it is or what it is
It is a job, don’t care where it runs.
Donal: Force to use appropriate data transfer mechanisms
Andrew: wanted to get concrete.

Summarize the discussion:
Morris:
Someone should have more time to nail down this specific use case
Maybe we could take now the open standards
Might be too much implementation detail
Balazs: two things: current use case in the charte is too general
Oxana. Job is executed where the data is (CERN experiments)
We should try to generate a generic use case.  Many systems using no data...