[glue-wg] Open enumeration values for the generic service provider

[Florido Paganelli]

On 07/04/2012 02:37 PM, stephen.burke at stfc.ac.uk wrote:
> glue-wg-bounces at ogf.org
>> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Florido Paganelli
>> said: Which of those have a single endpoint? all of them but Argus
>> and VOMS?
>
> Also
>
> org.glite.ce.Monitor org.glite.ce.ApplicationPublisher
>
> are normally part of CREAM, which I think publishes a ServiceType of
> org.glite.ce.CREAM (the Service publisher in that case is part of the
> CREAM distribution).
>
>> ok so during the last ServiceType_t review we decided that
>> org.glite.voms was a ServiceType_t, is that an error?
>
> VOMS is what's in the code at the moment. It can be changed if that's
> the decision; as usual that will mean we have some period where both
> forms will be in use, but since nothing is likely to be relying on it
> yet that shouldn't be a problem.
>

GOCDB people will not be happy, but I would like it to be changed the 
same as the InterfaceName.

>> Any remark on this org.glite.standard?
>
> It's the format we've been using in glite for GLUE 1
> AccessControlBaseRules. I think the only formal description is here:
>
> https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallenges/WLCG_GlueSchemaUsage-1.8.pdf
>
>  page 33. For GLUE 2 we should not allow the deprecated form b), i.e.
> a bare VO name. The wildcard format has so far not been implemented.
> In addition to that, for myproxy we publish rules with a prefix
> MYPROXY:, e.g.
>
> GLUE2PolicyRule:
> MYPROXY:authorized_renewers=/C=DE/O=GermanGrid/OU=DESY/CN=host/grid-lb2.desy.de
>
>  (actually I just spotted a bug, at the moment there's a trailing "
> which shouldn't be there).
>
> For GLUE 2 we also have the reserved word ALL meaning no
> authorsiation, and for Argus I added a new reserved word NONE meaning
> no access (for users, Argus is used only by other services).
>

I think we should decide a way to define these policies, I mean 
instances of them, or a canonical way of representing them...

I think the description in GFD147 is vague, and on the other hand it 
would be nice to have some kind of "library" for these policies to be 
reused by coders.

Can you sketch a definition that is consistent with GFD147 for GLUE2? 
maybe we can use that as an example for future policy definitions.

The problem is also related on how to store those, as they should be 
coupled to a grammar and an evaluation algorithm in the most generic 
case, if I am not wrong.

Thanks for your quick answers, anyway!
cheers
-- 
Florido Paganelli
Lund University - Particle Physics
ARC Middleware
EMI Project