[glue-wg] DENY rules

[Laurence Field]

If no specification exists then we have to use the defacto standard 
which is the current usage. As this is a Nordugrid use case, they should 
just state what syntax they currently use.

Laurence



Burke, S (Stephen) wrote:
> glue-wg-bounces at ogf.org 
>   
>> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Laurence Field said:
>> The aim of Glue within OGF is to try and bring 
>> some of the other specifications together and not define so much by 
>> ourselves. 
>>     
>
> That's fine where specifications exist, but if they don't and people
> nevertheless want to publish something we have to establish some kind of
> rules. The alternative is that we tell Nordugrid that they can't publish
> such things unless someone else decides the standard - is that
> acceptable? Or else Nordugrid publish things which aren't interoperable
> so e.g. we can't submit jobs from EGEE to them, as I believe you are
> trying to do. For that matter, the decisions by the EGEE authz working
> group don't represent any kind of standard, in practice they can only be
> standardised if we include them in Glue. 
>
>   
>>  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.
>>     
>
> This particular case is nothing to do with EGEE, the request comes from
> Nordugrid. However, if EGEE had decided to keep DENY tags I don't see
> that we would have any choice but to include it in Glue - the
> alternative would be that EGEE would have to abandon interoperability.
> Similarly we have agreed to include the EGEE wildcard matching rules in
> Glue - are you saying we should refuse to do that? If so it will not be
> possible for GLUE-compliant middleware to submit to EGEE.
>
>   
>> We should just be able 
>> to published the ACLs in the FQAN format and that is it.
>>     
>
> If it doesn't satisfy real use cases that can't be it.
>
>   
>> 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 don't think that's realistic. It's a major struggle to get people to
> adopt Glue at all - I would give only 50/50 odds that Glue 2 will in
> fact be adopted by LCG for example (we're still trying to get glue 1.3
> features adopted). If we can't support significant use cases the chance
> drops to pretty much zero.
>
> Stephen
>