[glue-wg] GLUE 2.0 Specification - draft 41 - Working Group LastCall

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org 
> [mailto:glue-wg-bounces at ogf.org] On Behalf Of Sergio Andreozzi said:
> This is the official Working Group last call for GLUE 2.0 and 
> we invite
> all of you to read the specification and to send your feedback by
> Friday, 12 AM CEST.

OK, I've started, but it's hard going! I'll just comment on the main
entities for now and come back to the rest. One general comment is that
I think most things could do with more detailed explanation; even I find
it difficult to understand what some things mean, and I think someone
new to this will get lost fairly quickly. Can we give some examples in
the text?

  Page 5, I think there is still some problem with the multiplicities,
or perhaps with my understanding of what they mean ... for example I can
see "1"s near Endpoint, Share and Resource, and yet all of them also
have *s - so they are optional in some directions and mandatory in
others?! (Formally I think they should all be optional.)

  All the definitions have a section labelled "Association End" - what
does "End" mean there?

   Now comments on the entities ...

Entity: I'm not sure why the attributes are mandatory - also they are
missing in all the other entities even though they all inherit from
Entity! In fact although the description says that everything inherits
from Entity I suspect that excludes Extension? Also I'd be inclined to
add Name and OtherInfo to Entity - at the moment not everything has a
Name but I don't think it does much harm to include it.

Extension: despite the statement at the start that everything must have
an opaque ID Extension doesn't, the ID is the Key. I think that's a
mistake - among other things you might have multiple instances of the
same Key. That relates to another question which is why is the Value
multiplicity *? I would suggest it should be 1 but you could have
multiple instances for the same Key.

Location: is missing OtherInfo, but it will get it automatically if it
gets added to Entity.

AdminDomain: I think Owner needs to be defined better.

UserDomain: similarly I think UserManager and Member need more
explanation and/or examples. Also it's not clear if what's there can
work - for example if UserManager is supposed to be a VOMS URL the
scheme would just be https, so how can you tell that it's VOMS and not
something else? Probably it would need some kind of Type attribute.

Service: it's not entirely obvious to me why Capability is mandatory.
Also I think the enumerated Type list in the appendix is inadequate,
it's not really clear to me how this is supposed to work, given that
every Service is supposed to have a unique Type (what about computing
and storage services?!). Conversely many of the things which are listed
(e.g. org.teragrid.gpfs) don't seem to represent things I would consider
to be Services at all.

Endpoint: again I wonder why Capability is mandatory. And I don't
understand why or how Type and Version are combined as a single
Interface URI: at the very least this needs *much* more explanation
since it's absolutely vital to using the endpoints! And the Type list
needs to be enumerated (as it is now). Basically I don't understand why
we haven't kept the Type and Version as we have them in 1.3. For
QualityLevel, how do the Endpoint QLs relate to the one in the parent
Service? For StartTime, is this different to Entity.CreationTime which
should be inherited? I still think that TrustedCA belongs in
AccessPolicy and not Endpoint - if we can't figure out how to fit it in
there it probably means that we still don't have a good enough
definition of the AP object. And I still think the Downtime attributes
should be in a separate object, to me it makes no sense to put them
there - among other things, if the service is down the Endpoint will
probably not be published so you won't be able to read the Downtime
information.

Share: the Endpoint and Resource relations are marked as mandatory,
which doesn't seem right since the objects are supposed to be optional.

Manager: I'm not sure why it needs a globally unique ID? And again the
Resource relation is mandatory which can't be right since the Resource
itself is optional.

Resource: as above, the description and the relations say that
Endpoints, Shares and Managers are mandatory, which doesn't seem right.
And again I don't think it needs a global ID. Also there is no
accompanying text, which should at the very least say that it's an
abstract entity.

Activity: it looks odd to have two identical lines for the
Activity-Activity relation.

Policy: I think we still have some problems with this ... for one thing
I think the Rule has to have type "string", since we can't possibly
specify all formats. And I'm not sure why the Rule is optional,
shouldn't it be 1..*? Also I think we need to say something about the
semantics in the case where you have multiple Policy objects, either
with the same Scheme or with different Schemes. Also the UserDomain
relation should be * - the Rules may relate to several VOs, and
conversely the UD object itself is optional. We also still need feedback
on whether this can meet all the use cases - for EGEE I think we should
be OK, but it's certainly a long way from being generic (DENY rules!).

AccessPolicy: One basic point is that it seems to me that APs should be
related to Service as well as Endpoint, otherwise service discovery will
be a lot more complex and messy than it is now. Also as I said above I
think TrustedCA should be here.

MappingPolicy: I'm not clear if the concept of the Default mapping can
actually work as stated. As mentioned above I don't think the relation
to UD can be mandatory, it may well not be published, and while the
Rules implicitly relate to a VO (or perhaps more than one) it may not be
in any simple way, e.g. it may involve groups and roles. What exactly
does it mean to say that there MUST be only one default MP per UD, in a
way which is guaranted to be meaningful for all possible policy Schemes,
all technologies, all service types, ...?

 OK, that's all the main entities, I'll get to the Computing part
tomorrow.

Stephen