participants: Morris, Mark, Steve Crouch, Etienne, Johannes, Balazs, Tim, Emannouil

Agenda:

(a)
Sessions at OGF in Chicago

discussing restrictions of participants
Tuesday as PGI-day at OGF29

PGI f2f meeting 23-24 June, same venue

ARC will find a person, Balasz not sure to go
nobody from Southhampton will go to OGF this time

action for Morris:
contact gLite people in terms of OGF29 planning

(b)
Requirement List


157:
NSF requirement

Etienne:
could be a spof or bottleneck

Mark:
not a spof

Balazs:
interesting but not sure if in scope of pgi
so no

Morris:
not a quick agreement, put a "no"

change to "no"

###

158:
Morris: NSF requirement, who has a problem with this?

Steve: more general, not real requirment

Morris:
would say it is a duplicate of 157

marked as duplicate

###

159:
GIN requirement

Balazs:
logging and bookkeeping
originally: requirement form Czech Grid people

Etienne:
very much SOAP oriented, would like another formulation

Morris:
vote for "yes"

changed to "yes"

###

160:
Mark:
basic computer science principle

Morris:
someone saying "no"?
nobody
changed to "yes"

###

163:
changed to "no"

###

164:
Morris:
someone saying "no"?
vote for "no"

changed to "no"

###

165:

changed to "yes"

###

166:
Morris:
information functionality inside the execution service?

Etienne:
for me different

Morris:
somebody still problem in unerstanding?

someone saying "no"

changed to "yes"

###

170:
Morris:
why reproposed?

Etienne:
payload: anything that the job submitter wants to exectue on the computer resource, app, script or pilot job
here the important thing is to define an abstract model without giving precise names to the states

Morris:
unclear for somebody?

Etienne:
"no" for me

changed to "no"

###

13:
Etienne:
could be at the message layer
consider authentication at message level?
what is the set of the certification authorities?

Morris:
the what is not the question here. how we do it will be discussed later.
now just resolving "unlcears"
diving downin security details

will discuss security
suggestion: mark the four security requirements as "no"

changed 13,14,15,16 as "no"

###

Etienne:
now payload is defined

123,124 could be resolved easily


123:
Etienne:
payload widely used in other contexts to describe what is the interesting part with real value

changed to "yes"

###

124:

changed to "yes"

###

Morris:
how to proceed?

Etienne:
begin again with beginning of the list
and look at all still unclear and no s and try to resolve them

try to clarify the whole situation by clearifying the scope of the execution service

###

insert requirement 172:
IS14

changed to "yes"

###

insert requirement 173:

changed to "yes"

###

(c)
AOB