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 -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room E 005, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl@nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl