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.htm... 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.