[glue-wg] DENY rules

[Laurence Field]

The problem with an information model is that we can end up describing 
everything.  The aim of Glue within OGF is to try and bring some of the 
other specifications together and not define so much by ourselves.  For 
example, JSDL should describe the job and Glue should reflect this so 
that the job can be matched. The group defining JSDL should worry about 
the matchmaking should be worked out jointly between the JSDL group and 
Glue, but JSDL should be the definition which Glue reflects and likewise 
for the Authorization.

We need to narrow our focus or we will end up "boiling the ocean" which 
has happened to many other Groups and the definition will take forever.

 From what I can see on the use of DENY tags within EGEE, this is a big 
hack to work around a implementation problem in the glite middleware and 
as such should not dictate what is done in Glue.  We should just be able 
to published the ACLs in the FQAN format and that is it.

The reason for the DENY tags is the inconsistency with the simple 
matchmaking done by the WMS and the mapping of VOMS FQANs in a CE.

If publishing only the FQANs does not work, it is not necessarily an 
information model problem but architectural issue that needs to be fixed 
and should be pushed back to those dealing the Authentication and 
Authorization. We need to take a more minimalistic approach do the 
schema definition and not try to fix other peoples problems.

I completely realize that we need to be pragmatic but just like over 
design we can also be too pragmatic.





> The syntax of the FQAN itself is defined by the VOMS developers, but
> they don't consider how it should be published in GLUE, or in general
> how it should be used for matching. This is similar to the situation
> with access protocol names - in principle they should be defined by SRM,
> but in practice they aren't so we have to do it. Indeed the recent
> review of authorsiation in EGEE basically endorsed the GLUE model and
> will change both the WMS and LCMAPS to follow it!
>
> Stephen
>