From: Owen Synge <owen@alice-dsl.de> To: "owen.synge@desy.de" <owen.synge@desy.de> Subject: Still No use case for ACL's? Leading to new questions. Date: Wed, 7 May 2008 23:29:59 +0200 X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; i486-pc-linux-gnu) On Wed, 7 May 2008 14:18:57 +0100 "Burke, S (Stephen)" <S.Burke@rl.ac.uk> wrote: Dear Steven, You still have not provided a use case for ACL's on storage areas within GLUE not satisfied by "Freedom of choice" schema could you please present one?
owen.synge@desy.de [mailto:owen.synge@desy.de] said:
Thankyou for explaining, but Im still confused why this should be in GLUE, when its dependent on who reads the ACL.
ACL's are not static (which Glue is designed for).
I don't agree with either of those. ACLs are pretty static, they might change on a timescale of weeks,
ACL's on storage areas can be changed by users at any time they wish how ever often they wish.
and in any case GLUE is designed for dynamic data, at least down to a timescale of a few minutes.
I don't believe current implantation's of GLUE are just not as fast as you suggest. GLUE is about service discovery, I suppose in a purist sense this is dynamic, but its not through intention of GLUE representation providers.
ACL's may be private (which Glue is not for).
Privacy is up to an implementation.
No its an ACL option selected by a user, hence can be changed at any time.
The BDII has no way to keep information private, which may be problematic in various cases, but other implementations may well have access control.
Agreed, BDII is limited in this respect. LDAP can be secured as can other implementations, but this makes no sense in the context of GLUE, as GLUE is about publishing, I would advise against writing a client software dependent upon on entities that may or may not exist dynamically.
Experiments have the Freedom of choice project to say where they want to write.
That's nothing to do with GLUE per se.
I disagree, GLUE is the foundation upon which many systems such as "Freedom of choice" can depend.
FoC is not a project, it's a rather hacky solution to a specific problem and is also specific to EGEE and to the BDII.
If it is a "hacky solution" why is that? Could you elaborate? I can only guess you think it is because GLUE need to be simplified?
And apart from that, the current implementation works by editing the ACL on the CE, so it's hardly an argument for not having ACLs!
I just do not understand your logic here at all, you need to expand considerably if I am to understand you.
From a purely
LCG/EGEE perspective it's actually the DPM authorisation model we would like to have and dcache and castor should come in line. This is a mater of opinion, I suggest prime mover advantage is important but not the only factor in desiding.
It's not my decision to make, but it was the decision of the recent EGEE authz working group:
https://edms.cern.ch/document/887174/1
(Recommendations document, rec. 12).
I cannot recommend that what you reference should sway GLUE in believing that this is definitive, even if the thanked people and referees where included as authors it does not include many who I should expect within wLCG or glite. It also does not reflect the latest wLCG SRM MOU, where features are discussed with the relevant parties, which directly contradicts your ACL assertions about it being fixed. I would take this document as authoritative for wLCG if it included the all the parties in the wLCG SRM MOU, can you please get them all to agree to this document or withdraw this assertion.
I feel my proposal for VO-Objects and specialisations target at services and VO's appeals more and more.
Frankly it's irrelevant to the current discussion, glue 2 is now basically fixed and we aren't going to make any fundamental changes at this stage.
I first suggested this for GLue 1.1 but I then accepted it was not backwards compatible with Glue 1.0, and have presented it repeatedly as what I consider an important simplification. Since you suggest "glue 2 is now basically fixed" I suggest defending ACL's is inconsistent with your above statement. Regards Owen Synge Paul Millar represents dCache. I represent only my own opinions.