Hi all, I concur with Etienne, and would like to thank him for doing this careful analysis! If we are going to use the "vote count" as a serious justification for further decisions, it has to be made in a consistent manner. If however this count does not matter, since the high-level picture is already "blessed", then of course re-counting is a futile exercise. Cheers, Oxana P.S. the heroic effort of PGI requirements counting during the coffee break is actually illustrated in the attachment ;-) On 05.11.2010 20:19, Etienne URBAH wrote:

Morris and Johannes,

Thank you for the notes of the PGI sessions held at OGF30 in Brussels on 26 October 2010.

Reviewing them and the associated requirement spreadsheet at http://forge.gridforum.org/sf/go/doc16080?nav=1 I have found several issues :

A) Green color of spreadsheet cells for vote count (column T) ------------------------------------------------------------- At the end of the notes for session 3, it is mentioned that I 'globally approve all of the greens'. I confirm that I expressed this position. But inside the spreadsheet, the vote count cells (column T) which were green have turned yellow ! Then, my above position has no meaning anymore.

B) Requirement supported by EDGI -------------------------------- Inside the requirement spreadsheet, you took into account only the 26 'Mandatory requirements' from my mail below.

In fact, you should have taken into account the 'Complete list of requirements' specified at the end of the same mail.

Therefore, I have updated the requirement spreadsheet with this complete list (70 requirements).

C) Votes for requirements WITHOUT 'yes' status ---------------------------------------------- Inside the process of voting for requirements, we were supposed to vote ONLY for requirements having 'yes' status.

Inside the requirement spreadsheet, it seemed to me that some votes were for requirements WITHOUT 'yes' status.

In order to be sure, I have reactivated the display of the column displaying 'Agreement OGF29' (column F), and I have colored in yellow all cells NOT containing 'yes'.

This clearly shows that MANY votes were for requirements WITHOUT 'yes' status.

In particular, requirement 10 'SSL certificates of servers MUST be signed by a CA belonging to IGTF ' gathered 3 votes.

This indicates that some requirements NOT having 'yes' status still have a great importance for several PGI members.

Therefore, I propose to perform a new round of voting, allowing votes for all requirements WITHOUT consideration of their previous status.

If this proposal is accepted, I would also vote for following requirements : 10, 12, 13, 14, 15, 18, 27, 38, 39, 41, 49, 51, 53, 75, 127, 161, 162, 164, 167

Conclusion ---------- Counting of votes has perhaps been performed too hastily.

The attached 'PGI-Requirements-2010-10-26-Review-Etienne.xls' file contains the 'Complete list of requirements' of EDGI, and displays the 'Agreement OGF29' column (but I have NOT added any EDGI vote for any requirement NOT having 'yes' status).

I suggest that each PGI member carefully checks the content of this spreadsheet.

Anyway, I still agree with the priorities stated at OGF30 : 1) XML rendering for GLUE 2.0 2) Usage of GLUE 2.0 entities and attributes inside JSDL 3) Usage of GLUE 2.0 entities and attributes inside JSDL for SPMD and MPI 4) Usage of GLUE 2.0 entities and attributes inside JSDL to describe Applications 5) Usage of GLUE 2.0 entities and attributes inside BES

Best regards.

----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------

-------- Original Message -------- Subject: Re: OGF PGI - Requirements triggered by the EDGI Use Cases Date: Tue, 19 Oct 2010 14:33:25 +0200 From: Etienne URBAH <urbah@lal.in2p3.fr> To: Morris RIEDEL <m.riedel@fz-juelich.de>, Johannes WATZL <watzl@nm.ifi.lmu.de>, pgi-wg@ogf.org CC: lodygens@lal.in2p3.fr, edgi-na2@mail.edgi-project.eu

Morris, Johannes and all,

Please find below the OGF PGI requirements triggered by the EDGI Use Cases :

+-----------------------------+ | A) Mandatory requirements | +-----------------------------+ Following is the list of requirements with 'yes' status which are seen as mandatory for EDGI. Interoperation would be very difficult without them.

Information functionality ------------------------- 1 : All grid entities (if possible) MUST be described using the GLUE model. If not possible, extensions for the GLUE model are necessary. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS1

5 : The Execution Service MUST NOT expose detailed information about the GLUE entities which the Execution Service does not manage (all that are not expressed by the computing part of GLUE). For example, Storage Element GLUE entity NOT exposed by Execution Service, NO details about Storage entity. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS4

165 : For already finished Activities, the Information functionality SHOULD accept requests querying the Activity Status, but MAY return an error http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS9

172 : In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Information functionality SHOULD be separated from the Execution Service http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS14

Security (Authentication, Authorization, Delegation) ---------------------------------------------------- 9 : If server authentication to clients, then it must be done with X.509 certificates on TLS (as mandatory option, allowing also other mechanisms additionally) http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA1

11 : Each Service MUST publish the Authentication and Authorization methods accepted by its Endpoints in conformance with GLUE recommendations http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA2

32 : There must be a mechanism which allows users to manage Activities submitted by other users (access control lists/methods/policies). In order to authorize (or not) an request on an Activity, each instance of the Execution Service MUST enforce a consistent authorization method. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA9

Application Repository ---------------------- 34 : An easy way of launching applications or pre-configured /pre-installed software w/o specifying location details. Installed/pre-configured ones should be exposed as well as part of the resource description. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAR1

Accounting ---------- 36 : The Execution Service SHOULD provide Accounting records for each managed Activity. e.g. OGF Usage Records, for tracking resource usage. Most likely improving UR in terms of network and storage resource tracking and improvements of compute parts of multi-core-business. Grid-level attributes (for example: start-time on Grid vs. in batch-system). http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAc2

173 : In order to prevent overloading the Execution Service (which has performance requirements for Activity Management), the Accounting functionality MUST be separated from the Execution Service http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAc1

Logging and Bookkeeping ----------------------- 37 : WITH ITS ORIGINAL TITLE : In order to permit efficient Log analysis and Security audit, some Logging and Bookkeeping functionality MUST secure persistence at the grid level of Activity logs from various logging systems and MUST permit Client access to these Activity logs, even after Activities have finished. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqLB1

Activity Management ------------------- 45 : On creation of an Activity, the Execution Service MUST return to the Client an Activity ID permitting the Client to perform subsequent actions (Query, Cancel, ...) on this precise Activity http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM4

62 : The Execution Service MUST log enough grid information inside logging systems (which MAY vary during the lifetime of the Activity), in order to permit efficient Log analysis and Security audit http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6

67 : If a Client queries for an already finished Activity, the Execution Service MAY response with an error http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6.8

74 : The execution service MUST NOT expose activity information when queried for resource information http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6.1...

94 : Requirement to have a purge (maybe called wipe) operation. Removing all presence (except logs & usage records) of the activity (when it is not longer active or once finished). This functionality is only allowed on any final state according to the PGI state model. The functionality is not supposed to kill Activities, that is why its only allowed on final states. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM20

Job Description --------------- 100 : The Job Description document MUST reference all grid entities in conformance to the GLUE specification http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD3

101 : The Job Description document specification MUST permit the Client to request automatic data stage-in and stage-out http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD4

107 : Job Description should be only used for Job Description not for any kind of feedback. Job status information should not be communicated with a 'changed JSDL' http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD11

State Model ----------- 119 : The Execution service MUST support a common state model http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqSM1

131 : The Execution service MUST perform the transition between Activity states requested by the Client ONLY if it makes sense. Otherwise, the Execution service MUST return an error to the Client. http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqSM10....

Data Management --------------- NO requirement with 'yes' status is essential.

Non functional -------------- 146 : Software components (Services and Clients) MUST ease traceability of the original author of a request http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF3

147 : Software components (Services and Clients) MUST generate adequate logs http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF4

148 : Software components (Services and Clients) MUST generate and propagate meaningful error messages, including context description http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF5

149 : Specifications SHOULD prevent the occurrence of SPOFs and bottlenecks http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF7

154 : Basic SW Engineering basic principles - implementation encapsulation, separation of policies, construction by composition, don't re-invent new mechanisms when some existing http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF12

160 : Execution Service MUST NOT try to provide ALL grid functionalities, but MUST have a well defined scope, and MUST work together with other grid services : Security, Accounting, Data (Storage, Movement, Catalog, ...), perhaps Information, Logging and Bookkeeping http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF13

+------------------------------------+ | B) Complete list of requirements | +------------------------------------+ Following is the complete list of requirements with 'yes' status which are seen as useful for EDGI.

Information functionality : 1, 3, 4, 5, 6, 8, 165, 166, 172

Security (Authentication, Authorization, Delegation) : 9, 11, 17, 19, 20, 21, 22, 32

Application Repository : 34

Accounting : 36, 173

Logging and Bookkeeping : 37 WITH ITS ORIGINAL TITLE

Activity Management : 43, 44, 45, 46, 55, 58, 59, 62, 63, 64, 65, 66, 67, 68, 74, 81, 82, 86, 90, 94

Job Description : 100, 101, 104, 107, 112, 114, 116, 118

State Model : 119, 120, 121, 122, 123, 124, 125, 128, 131, 134

Data Management : 143

Non functional : 145, 146, 147, 148, 149, 150, 154, 156, 159, 160

Best regards.

----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -----------------------------------------------------

_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

Etienne, all, I put your points on the agenda for Thursday. Nevertheless, the main items to work on stay the same. Thanks, Morris

-- -----Ursprüngliche Nachricht----- -- Von: Etienne URBAH [mailto:urbah@lal.in2p3.fr] -- Gesendet: Freitag, 5. November 2010 20:19 -- An: Riedel, Morris; Johannes WATZL -- Cc: pgi-wg@ogf.org; lodygens@lal.in2p3.fr; edgi-na2@mail.edgi-project.eu -- Betreff: OGF PGI - Review of notes of OGF30 sessions on 26 October 2010 - Counting votes for requirements -- Wichtigkeit: Hoch -- -- Morris and Johannes, -- -- Thank you for the notes of the PGI sessions held at OGF30 in Brussels on -- 26 October 2010. -- -- Reviewing them and the associated requirement spreadsheet at -- http://forge.gridforum.org/sf/go/doc16080?nav=1 I have found several -- issues : -- -- -- A) Green color of spreadsheet cells for vote count (column T) -- ------------------------------------------------------------- -- At the end of the notes for session 3, it is mentioned that I 'globally -- approve all of the greens'. -- I confirm that I expressed this position. -- But inside the spreadsheet, the vote count cells (column T) which were -- green have turned yellow ! -- Then, my above position has no meaning anymore. -- -- -- B) Requirement supported by EDGI -- -------------------------------- -- Inside the requirement spreadsheet, you took into account only the 26 -- 'Mandatory requirements' from my mail below. -- -- In fact, you should have taken into account the 'Complete list of -- requirements' specified at the end of the same mail. -- -- Therefore, I have updated the requirement spreadsheet with this complete -- list (70 requirements). -- -- -- C) Votes for requirements WITHOUT 'yes' status -- ---------------------------------------------- -- Inside the process of voting for requirements, we were supposed to vote -- ONLY for requirements having 'yes' status. -- -- Inside the requirement spreadsheet, it seemed to me that some votes were -- for requirements WITHOUT 'yes' status. -- -- In order to be sure, I have reactivated the display of the column -- displaying 'Agreement OGF29' (column F), and I have colored in yellow -- all cells NOT containing 'yes'. -- -- This clearly shows that MANY votes were for requirements WITHOUT 'yes' -- status. -- -- In particular, requirement 10 'SSL certificates of servers MUST be -- signed by a CA belonging to IGTF ' gathered 3 votes. -- -- This indicates that some requirements NOT having 'yes' status still have -- a great importance for several PGI members. -- -- Therefore, I propose to perform a new round of voting, allowing votes -- for all requirements WITHOUT consideration of their previous status. -- -- If this proposal is accepted, I would also vote for following requirements : -- 10, 12, 13, 14, 15, 18, 27, 38, 39, 41, 49, 51, 53, 75, 127, 161, 162, -- 164, 167 -- -- -- Conclusion -- ---------- -- Counting of votes has perhaps been performed too hastily. -- -- The attached 'PGI-Requirements-2010-10-26-Review-Etienne.xls' file -- contains the 'Complete list of requirements' of EDGI, and displays the -- 'Agreement OGF29' column (but I have NOT added any EDGI vote for any -- requirement NOT having 'yes' status). -- -- I suggest that each PGI member carefully checks the content of this -- spreadsheet. -- -- -- Anyway, I still agree with the priorities stated at OGF30 : -- 1) XML rendering for GLUE 2.0 -- 2) Usage of GLUE 2.0 entities and attributes inside JSDL -- 3) Usage of GLUE 2.0 entities and attributes inside JSDL for SPMD and MPI -- 4) Usage of GLUE 2.0 entities and attributes inside JSDL to describe -- Applications -- 5) Usage of GLUE 2.0 entities and attributes inside BES -- -- -- Best regards. -- -- ----------------------------------------------------- -- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS -- Bat 200 91898 ORSAY France -- Tel: +33 1 64 46 84 87 Skype: etienne.urbah -- Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -- ----------------------------------------------------- -- -- -- -------- Original Message -------- -- Subject: Re: OGF PGI - Requirements triggered by the EDGI Use Cases -- Date: Tue, 19 Oct 2010 14:33:25 +0200 -- From: Etienne URBAH <urbah@lal.in2p3.fr> -- To: Morris RIEDEL <m.riedel@fz-juelich.de>, Johannes WATZL -- <watzl@nm.ifi.lmu.de>, pgi-wg@ogf.org -- CC: lodygens@lal.in2p3.fr, edgi-na2@mail.edgi-project.eu -- -- Morris, Johannes and all, -- -- Please find below the OGF PGI requirements triggered by the EDGI Use Cases : -- -- -- +-----------------------------+ -- | A) Mandatory requirements | -- +-----------------------------+ -- Following is the list of requirements with 'yes' status which are seen -- as mandatory for EDGI. Interoperation would be very difficult without them. -- -- -- Information functionality -- ------------------------- -- 1 : All grid entities (if possible) MUST be described using the GLUE -- model. If not possible, extensions for the GLUE model are necessary. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS1 -- -- 5 : The Execution Service MUST NOT expose detailed information about -- the GLUE entities which the Execution Service does not manage (all that -- are not expressed by the computing part of GLUE). For example, Storage -- Element GLUE entity NOT exposed by Execution Service, NO details about -- Storage entity. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS4 -- -- 165 : For already finished Activities, the Information functionality -- SHOULD accept requests querying the Activity Status, but MAY return an error -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS9 -- -- 172 : In order to prevent overloading the Execution Service (which has -- performance requirements for Activity Management), the Information -- functionality SHOULD be separated from the Execution Service -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqIS14 -- -- -- Security (Authentication, Authorization, Delegation) -- ---------------------------------------------------- -- 9 : If server authentication to clients, then it must be done with -- X.509 certificates on TLS (as mandatory option, allowing also other -- mechanisms additionally) -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA1 -- -- 11 : Each Service MUST publish the Authentication and Authorization -- methods accepted by its Endpoints in conformance with GLUE recommendations -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA2 -- -- 32 : There must be a mechanism which allows users to manage Activities -- submitted by other users (access control lists/methods/policies). In -- order to authorize (or not) an request on an Activity, each instance of -- the Execution Service MUST enforce a consistent authorization method. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAA9 -- -- -- Application Repository -- ---------------------- -- 34 : An easy way of launching applications or pre-configured -- /pre-installed software w/o specifying location details. -- Installed/pre-configured ones should be exposed as well as part of the -- resource description. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAR1 -- -- -- Accounting -- ---------- -- 36 : The Execution Service SHOULD provide Accounting records for each -- managed Activity. e.g. OGF Usage Records, for tracking resource usage. -- Most likely improving UR in terms of network and storage resource -- tracking and improvements of compute parts of multi-core-business. -- Grid-level attributes (for example: start-time on Grid vs. in batch-system). -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAc2 -- -- 173 : In order to prevent overloading the Execution Service (which has -- performance requirements for Activity Management), the Accounting -- functionality MUST be separated from the Execution Service -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqAc1 -- -- -- Logging and Bookkeeping -- ----------------------- -- 37 : WITH ITS ORIGINAL TITLE : In order to permit efficient Log -- analysis and Security audit, some Logging and Bookkeeping functionality -- MUST secure persistence at the grid level of Activity logs from various -- logging systems and MUST permit Client access to these Activity logs, -- even after Activities have finished. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqLB1 -- -- -- -- Activity Management -- ------------------- -- 45 : On creation of an Activity, the Execution Service MUST return to -- the Client an Activity ID permitting the Client to perform subsequent -- actions (Query, Cancel, ...) on this precise Activity -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM4 -- -- 62 : The Execution Service MUST log enough grid information inside -- logging systems (which MAY vary during the lifetime of the Activity), in -- order to permit efficient Log analysis and Security audit -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6 -- -- 67 : If a Client queries for an already finished Activity, the -- Execution Service MAY response with an error -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6.8 -- -- 74 : The execution service MUST NOT expose activity information when -- queried for resource information -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM6.1... -- -- 94 : Requirement to have a purge (maybe called wipe) operation. -- Removing all presence (except logs & usage records) of the activity -- (when it is not longer active or once finished). This functionality is -- only allowed on any final state according to the PGI state model. The -- functionality is not supposed to kill Activities, that is why its only -- allowed on final states. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJM20 -- -- -- Job Description -- --------------- -- 100 : The Job Description document MUST reference all grid entities in -- conformance to the GLUE specification -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD3 -- -- 101 : The Job Description document specification MUST permit the Client -- to request automatic data stage-in and stage-out -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD4 -- -- 107 : Job Description should be only used for Job Description not for -- any kind of feedback. Job status information should not be communicated -- with a 'changed JSDL' -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqJD11 -- -- -- State Model -- ----------- -- 119 : The Execution service MUST support a common state model -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqSM1 -- -- 131 : The Execution service MUST perform the transition between -- Activity states requested by the Client ONLY if it makes sense. -- Otherwise, the Execution service MUST return an error to the Client. -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqSM10.... -- -- -- Data Management -- --------------- -- NO requirement with 'yes' status is essential. -- -- -- Non functional -- -------------- -- 146 : Software components (Services and Clients) MUST ease traceability -- of the original author of a request -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF3 -- -- 147 : Software components (Services and Clients) MUST generate adequate -- logs -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF4 -- -- 148 : Software components (Services and Clients) MUST generate and -- propagate meaningful error messages, including context description -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF5 -- -- 149 : Specifications SHOULD prevent the occurrence of SPOFs and bottlenecks -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF7 -- -- 154 : Basic SW Engineering basic principles - implementation -- encapsulation, separation of policies, construction by composition, -- don't re-invent new mechanisms when some existing -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF12 -- -- 160 : Execution Service MUST NOT try to provide ALL grid -- functionalities, but MUST have a well defined scope, and MUST work -- together with other grid services : Security, Accounting, Data (Storage, -- Movement, Catalog, ...), perhaps Information, Logging and Bookkeeping -- http://forge.gridforum.org/sf/wiki/do/viewPage/projects.pgi-wg/wiki/ReqNF13 -- -- -- +------------------------------------+ -- | B) Complete list of requirements | -- +------------------------------------+ -- Following is the complete list of requirements with 'yes' status which -- are seen as useful for EDGI. -- -- Information functionality : 1, 3, 4, 5, 6, 8, 165, 166, 172 -- -- Security (Authentication, Authorization, Delegation) : 9, 11, 17, 19, -- 20, 21, 22, 32 -- -- Application Repository : 34 -- -- Accounting : 36, 173 -- -- Logging and Bookkeeping : 37 WITH ITS ORIGINAL TITLE -- -- Activity Management : 43, 44, 45, 46, 55, 58, 59, 62, 63, 64, 65, 66, -- 67, 68, 74, 81, 82, 86, 90, 94 -- -- Job Description : 100, 101, 104, 107, 112, 114, 116, 118 -- -- State Model : 119, 120, 121, 122, 123, 124, 125, 128, 131, 134 -- -- Data Management : 143 -- -- Non functional : 145, 146, 147, 148, 149, 150, 154, 156, 159, 160 -- -- -- Best regards. -- -- ----------------------------------------------------- -- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS -- Bat 200 91898 ORSAY France -- Tel: +33 1 64 46 84 87 Skype: etienne.urbah -- Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr -- -----------------------------------------------------