[glue-wg] More comments on the draft spec.

[Paul Millar]

Hi all,

Some more comments.

A general comment:

To answer some questions, multiple passes through the info-system may be 
required.  For example, see "Which sites have SEs which support the gsidcap 
protocol?" within Stephen's page, here:
	http://egee-uig.web.cern.ch/egee-uig/production_pages/Advancedldapsearch.html

With LDAP, the object's RDN is often built from its ID or LocalID.  So, fields 
derived from an object's RDN (such as GlueChunkKey and GlueForeignKey) will 
be dependent on LocalID (or ID).

I believe Glue currently makes no statement about how long LocalID or ID 
should remain constant for the same object: the persistence of the LocalID 
value.  Although silly, I believe it would currently be acceptable to 
generate fresh random LocalIDs for each object every time data is published, 
provided all references were updated at the same time.

However, if one uses the RDN (for example, by following a GlueForeignKey value 
in a separate query), there is a tacit assumption that the RDN of the target 
object will not change (or, at least, that it is unlikely to change for the 
period between successive queries).  This is only true if the ID or LocalID 
used to build the RDN doesn't change.

So, it seems we have a requirement for IDs or LocalIDs to be persistent over 
time.  This should be stated somewhere, probably in section 3 (General 
Comments).


Some more comments:

*** Page 12

"activity" is misspelt in the description of the Associate End for 
Share.LocalID

*** Page 28

When providing a diagram representing the specialisation of entities (e.g., 
Fig. 3) the inherited associations are not shown.  Could these be added 
somehow (e.g., within the Main Entities section)?

Also, it isn't immediately clear that the entities in "Storage Entities" are 
the same as those in "Storage Entities - Inheritance".  Could this 
identification be included in the diagram?

*** Page 30

It's a little unclear why we have both StorageAccessProtocol and 
StorageEndpoint since StorageEndpoint can represent access protocols.

The StorageAccessProtocol seems to be only of use when talking about the 
CE-SE-bind objects.  If so, perhaps the description of StorageAccessProtocol 
could be updated to mention this.

There's still the question why Capability is a required property of 
StorageEndpoint: this is an echo of my previous point about this, suggesting 
that it is optional in Endpoint or simply removed and added to a new subclass 
of Endpoint.


*** Page 31

I feel we should mention in the description of StorageShare that it is:
	A UserDomain's view of [a utilization target for a set of 
StorageResources ...]
This may not be obvious, especially as the UserDomain--StorageShare 
association is currently not shown on the Storage entities diagram (Fig.3) as 
it's inherited.


*** Page 33

StorageResource:

The Latency is the maximum latency under normal operating conditions, not the 
maximum under any circumstance.

Cheers,

Paul.