[glue-wg] Comparison with CIM

Burke, S (Stephen) S.Burke at rl.ac.uk
Wed May 7 08:18:57 CDT 2008


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, and in any case GLUE is designed for
dynamic data, at least down to a timescale of a few minutes.

> ACL's may be private (which Glue is not for).

Privacy is up to an implementation. The BDII has no way to keep
information private, which may be problematic in various cases, but
other implementations may well have access control.

> Experiments have the Freedom of choice project to say where they want
> to write. 

That's nothing to do with GLUE per se. 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. 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!
 
> 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 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.

Stephen


More information about the glue-wg mailing list