March 2011 - gridrpc-wg - lists.ogf.org

Security Consideration section
by Eddy Caron 01 Apr '11

01 Apr '11

Dear all, Last step we must add a security consideration section as mentioned by Greg : > De : "Greg Newby" <newby(a)arsc.edu> > Date : 28 mars 2011 08:15:48 HAEC > À : Eddy Caron <Eddy.Caron(a)ens-lyon.fr> ... "Unfortunately nobody noticed earlier that you had not included a security considerations section. This is one of the requirements -- take a look at GFD #152 for discussion & example. I'm sorry for not pointing this out when the document was originally submitted." ... See www.ggf.org/documents/GFD.152.pdf for all information. I checked in the last SAGA-API document (because we are close to the behavior) and I propose the following update from the Andre's paragraph to be compliant to the GridRPC document. Security Considerations As the GRPC API is to be implemented on different types of Grid (and Cloud) middleware, it does not specify a single security model, but rather provides hooks to interface to various security models. A GRPC implementation is considered secure if and only if it fully supports (i.e. implements) the security models of the middleware layers it builds upon, and neither provides any (intentional or unintentional) means to by-pass these security models, nor weakens these security models’ policies in any way. The implementations of advert services (the “backend” services to this API), need to take security concerns into account, because such a service might cause leaks of user (meta) data beyond the runtime of the applications using this API. This is the same risk as with storage and file systems, to which the GRPC Data Management core API provides an API. Unlike with established file systems, however, the risks associated with advert services might be less obvious to their implementors. Andre can I use your text as based ? No strong copyright on it ? :-) If someone from the GridRPC-WG have some remarks, constraints or additional information, let me know or update the CVS. Best Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

3 2

GRPC_STICKY vs GRPC_PERSISTENT
by Eddy Caron 26 Mar '11

26 Mar '11

Dear Daniel, After discussions, we have improved the definition of GRPC_STICKY. Definitions are now: – GRPC STICKY: used when a data is kept inside the platform but cannot be moved between the servers, except if the user explicitly ask for the migration. This is used if the client needs that data in the platform for a second computation on the same server for example. Note that in this case, the data can also be replicated and that potential coherency issues may arise. – GRPC PERSISTENT: used when a data has to be kept inside the platform. The underlying data middleware is explicitly asked to handle the data: the data can migrate or be replicated between servers depending on scheduling decisions, and potential coherency issues may arise if the user attempt to modify the data on his own. With you external point of view, do you think it's more clear and enough ? Thanks you for your feedback. Best Regards Yves and Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

3 3

Re: [GRIDRPC-WG] GridRPC document (Re: [wg-all] New documents published)
by Eddy Caron 23 Mar '11

23 Mar '11

Dear all, We have checked with Dan and indeed Greg didn't send the last document. I did it. Nevertheless the remark about the Persitent and Sticky still true. From my point of view: GRPC_Persitent means that the data is available in the platform. This data can move. Thus the middleware should manage this data as asked page 6 of the standard "The underlying data middleware is explicitly asked to handle the data" (I'm agree with that, I don't see another other way). GRPC_STICKY means that the data is available and can not move ! I found nothing in the document that explains that the data must be handle by the user (and it's sound good for me). From my point of view GRPC_STICKY is handle by the user or by the middleware. It depends on the implementation. I agree with Yves but somewhere, I am a little bit confuse if a data mode implies a behavior rule of the middleware usage. If I want to have a Sticky data somewhere but I don't care about where. I don't give the target of the data (the middleware will do it) or if I give both informations target and sticky mode then I manage myself the data. No ? Eddy Regards, Le 23 mars 2011 à 10:26, Yves Caniou a écrit : > Hello, > > Not rude remarks here, but I'm a bit confused: it seems that Dan read an old > version of the document? > - I can't find the typo in the URI > - I can't find the "To discuss:" that he's talking about. But it reminds me of > the paragraph that I put there from the beginning concerning the diffusion of > a data on the servers (Broadcast, multicast, and such things that were > available in OmniStorage)... > > BUT, concerning the distinction between GRPC_Persistent and GRPC_Sticky: > if we have to emphasize that the second one is when the user completely relies > on the data manager on the opposite of the second one where he manages > himself the data, can't we have a data managed by the underlying data manager > (transparent transfer) with some particularities (like if making the data > sticky or unique if the DM wants to migrate the data)? > > Cheers. > > .Yves. > > Le Wednesday 23 March 2011 02:26:15 Eddy Caron, vous avez écrit : >> Dear all, >> >> We have received the final comment from Dan. With Yves we will update the >> document to take into account these comments. >> >> Best Regards, >> Eddy >> >> Début du message réexpédié : >>> De : "Daniel S. Katz" <dsk(a)ci.uchicago.edu> >>> Date : 22 mars 2011 11:21:57 UTC+08:00 >>> À : Greg Newby <newby(a)arsc.edu> >>> Cc : Eddy Caron <Eddy.Caron(a)ens-lyon.fr>, Alan Sill <Alan.Sill(a)ttu.edu>, >>> Wolfgang Ziegler <Wolfgang.Ziegler(a)scai.fraunhofer.de> Objet : Rép : >>> GridRPC document (Re: [wg-all] New documents published) >>> >>> Hi, >>> >>> I think it generally looks fine, and the GrdiRPC session today was >>> helpful. Some specific issues I have: >>> >>> On page 6, the distinction between GRPC_Persistent and GRPC_Sticky is not >>> clear. >>> >>> On page 7, "“http://myName:/myhome/data/matrix1”" has an extra ":" in the >>> middle. >>> >>> On page 11, the items under "to discuss:" are confusing. It seems like >>> these should be resolved at this point, or marked as potential >>> extensions. Also, in the second item, the "on" should be "one". >>> >>> Dan >>> >>> -- >>> Daniel S. Katz >>> University of Chicago >>> (773) 834-7186 (voice) >>> (773) 834-3700 (fax) >>> d.katz(a)ieee.org or dsk(a)ci.uchicago.edu >>> http://www.ci.uchicago.edu/~dsk/ >> >> --------------------------------------------------------------------------- >> ------------------- Eddy Caron. Mcf ENS Lyon >> ENS Lyon - LIP - Projet GRAAL >> 46 Allee d'Italie, 69364 Lyon Cedex 07, France >> E-Mail : Eddy.Caron(a)ens-lyon.fr >> [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] >> --------------------------------------------------------------------------- >> --------------------- > > > > -- > Yves Caniou > Associate Professor at Université Lyon 1, > Member of the team project INRIA GRAAL in the LIP ENS-Lyon, > Délégation CNRS in Japan French Laboratory of Informatics (JFLI), > * in Information Technology Center, The University of Tokyo, > 2-11-16 Yayoi, Bunkyo-ku, Tokyo 113-8658, Japan > tel: +81-3-5841-0540 > * in National Institute of Informatics > 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japan > tel: +81-3-4212-2412 > http://graal.ens-lyon.fr/~ycaniou/ ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

2 1

Talk Material of OGF'31 is available on the GridForge
by Eddy Caron 22 Mar '11

22 Mar '11

Dear all, In live from the OGF'31 GridRPC session at Taipei. https://forge.gridforum.org/sf/docman/do/listDocuments/projects.gridrpc-wg/… Best Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron(a)ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------

2 1