Still going back over the previous mails ... glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Jensen, J (Jens) said: It may be better to provide attributes for ExpirationMode and RetentionPolicy (etc) and explain what they're for, but not to prescribe the values.
I think we have two possibilities there: either allow open enumerations for the values, as you suggest, or define those attributes to be SRM-specific and provide different attributes for non-SRM use. The first one is obviously easier, but might cause problems e.g. if a differt technology also had a Replica QOS but meant something different by it. However, I guess we could just insist that the name mustn't clash. Since we don't really have any other examples we can't do much more. (Presumably even future SRM versions might have more/different categories?)
For example, if a StorageEnvironment contains both tape and disk, its AccessLatency should be Nearline - as it is the lowest common denominator.
This only makes sense if you have a partial order on capabilities.
In LCG that would clearly be wrong, we *define* Disk1Tape1 to mean Online! I think this needs more thought. Similarly you could argue that any SE which can provide Custodial storage must be good enough for Replica - but you may not want to use it for that if it costs more, and maybe the SRM does not in fact accept requests for Replica spaces (or does it have to?).
3. A StorageShare is associated with a StorageEnvironment if and only if they contain a common StorageCapacity.
I can't resist pointing out that this language implies that a Capacity has an identity - what does "common" mean? The thing which is common is the hardware (Datastore), not the Capacity, indeed the value of the capacity (number of bytes) is likely to be different (the Share usually doesn't fill the whole storage).
Where did the network description go? We used to have one.
The idea is that certain protocols can be used only locally, or on certain networks.
It was considered to be too complicated to represent all the possibilities (potentially everything could depend on everything else!).
I think we need to put it back, and StorageAccessProtocol seems to me the more obvious location.
Maybe, but we need a concrete use case which is likely to occur (and be important) in the real world. Stephen