Hi all, So, I've been thinking about publishing storage related objects, particularly with the WLCG accounting use-cases. One of the use-cases calls for associating each portion of a storage element to one or more VOs so that these can be used for per-VO accounting. In Glue 2.0, this association most naturally follows from instantiating MappingPolicy objects that act as links between StorageShare objects and UserDomain objects. An interesting issue is how to represent a single shared (i.e., multiple VOs may use) StorageShare. This can be represented (equivalently) as either: a single MappingPolicy object pointing to multiple UserDomain policies or multiple MappingPolicy objects, each pointing to the same StorageShare object. Each MappingPolicy object points to a single UserDomain object, but each of these UserDomain objects is different. (In fact, these two options are two extremes: one could publish a mixture of these) Aside: do we *really* need this flexibility? It seems to create unnecessary complication for the clients. We can remove it by changing either the Share: MappingPolicy.ID multiplicity to "optional" (0..1) or (Mapping)Policy: UserDomain.ID multiplicity to "required" (1). The former seems the better option (IMHO). We identify which StorageShares are to be used for accounting by selecting only those StorageShares that are published with a SharingID attribute value of "dedicated". The metric values to be used for storage accounting are the attached StorageShareCapacity objects. It might be worth adding another optional attribute, to allow accounting for (temporarily?) off-line storage. For example, adding: UnavaliableSize UInt64 0..1 GB Size of storage extent that is currently unavailable. The WLCG InstalledCapacity would then be: InstalledCapacity = TotalSize + UnavailableSize Cheers, Paul.