[glue-wg] Comparison with CIM

[owen.synge at desy.de]

From: Owen Synge <owen at alice-dsl.de>
To: "owen.synge at desy.de" <owen.synge at 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 at 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 at desy.de [mailto:owen.synge at 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.