[Pgi-wg] [OGSA-BES-WG] OGF OGSA-BES - Requirements for an improved Basic Execution Service

Thu Sep 15 06:00:55 CDT 2011

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 at 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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------