glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@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