Hi Etienne, thanks for creating this consolidated requirements document, it is very interesting to read. I have a few comments, mostly related to whether certain features are a "MUST" or not. In many cases it was not clear to me whether you talk about the BES interface specification, or about the way a BES instance should be deployed and operated. It would be good to remove the operational and deployment concerns, so that only the specification parts remain. I hope my comments can be used to make the document clearer and easier to digest. So, in detail: 1.4 Methodology * ref 4: glite user guide -> out of scope, gLite is too complex and too specific in its architecture (if there is such a thing) to be useful as a base for BES 2.4 Collaboration with other services While this is important for interoperability, it is unimportant for the specification of a BES. The BES spec should NOT try to specify all the interaction with the rest of the world. This is the task of a "grid architecture specification" like OGSA. Specifically, the interactions with security, monitoring, accounting and logging framework are OPERATIONAL concerns that MUST NOT be a mandatory part of a BES specification. 4. BES non-functional requirements 4.1.2 Traceability - should be SHOULD not MUST 4.1.3 Security - how can a specification "implement" a policy? You probably meant "BES implementations SHOULD ..." - availability/reliability: while I agree, you cannot enforce quality of an implementation via the specification. So all of 4.1.3 is SHOULD in my opinion. 4.2 all of this is out of scope. For example the UNICORE service container hosts a number of services including an execution service. Probably you mean that the execution service SPECIFICATION should be limited to the execution service and MUST NOT specify accounting, security etc. 5 BES requirements applying to the info system Introduction: this is a requirement on the grid, not on the BES. 6 BES requirements applying to security Introduction: when you say "The Execution Service MUST NOT be overloaed by implementing a security framework", it is not clear what you mean by "service". Do you mean the service as defined by its interfaces, or do you mean the actual BES process or even machine which is running BES? For example, a BES may be one of many services hosted by a service container, which may include a full featured security framework. This should be clarified. 6.1 * "SSL certificates MUST be signed by a CA..." this is an operational decision, and has nothing to do with the BES spec. For example, a site may run an inhouse deployment of BES using an in-house CA. This requirement should be deleted. 6.3 * "For Client authentication, the Execution Service MUST accept all following authentication methods: Full X509, RFC-3820-compliant X509 Proxy" This requirement is invalid. I agree that it would be nice to be able to specify authentication methods, but it is impossible. For example Shibboleth, Username/password, OpenID, OAuth (e.g. for a REST interface over plain HTTP), or even NOTHING (e.g. in an inhouse grid) all can be valid authentication methods in some circumstances. Furthermore, making proxies a MUST implies that nonstandard authentication libraries instead of TLS/SSL must be used, making the BES implementation insecure. For some implementors (like UNICORE) proxies on the transport level are very much a no-go. 6.4. "This authorization mechanism MUST be consistent across all instances of the Execution Service" This violates the autonomy of a site. Site administrators often wish to stay in control of their resources, and do not accept external authorisation decision points. And anyway, who cares? Since the AuthZ mechanism is internal to the BES, it cannot be specified in the BES spec as such. 6.5 These are reqiurements on the security layer (or framework) and should not be used as requirements on BES. 7 BES requirements related to "Application Repositories" While I agree that BES should understand the notion of an "Application" (see e.g. JSDL ApplicationName), I don't agree that the BES should use these for Scheduling. Rather, this is the job of a broker. 8 BES requirements applying to Accounting As a "MUST", these are out of scope, and should be made "SHOULD". 9 Logging/Bookkeeping Same as 8. 10 Jobs 10.1 Types of job Support for parallel jobs: it should be "MUST" :-) Best regards, Bernd. On Tue, 2011-09-13 at 20:51 +0200, Etienne URBAH wrote:
Andrew, Steven and all OGSA-BES stakeholders,
In the document named 'Requirements for an improved Basic Execution Service (BES)' and available at http://forge.gridforum.org/sf/go/doc16306 I have performed following improvements :
- For each functionality, clearly separate : - the requirements about the corresponding Client interface (often 'MUST'), - the requirements about the implementation of the functionality (sometimes 'MAY').
- Add short titles in bold to improve readability.
Thank you in advance for reading and criticizing this requirements document.
Best regards.
Etienne URBAH
On Fri, 09/09/2011 22:51, Etienne URBAH wrote:
Andrew, Steven and all OGSA-BES stakeholders,
I have finished written down a document named 'Requirements for an improved Basic Execution Service (BES)' and available at http://forge.gridforum.org/sf/go/doc16306
I will use this requirements document to propose improvements to the current specification of BES 1.0 described in GFD.108, as agreed at the OGSA-BES session at OGF32 in Salt Lake City on 17 July 2011.
Thank you in advance for reading and criticizing my requirements document.
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 -----------------------------------------------------
[...]
-- Dr. Bernd Schuller Federated Systems and Data Juelich Supercomputing Centre, http://www.fz-juelich.de/jsc Phone: +49 246161-8736 (fax -8556) ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------