Hi all, below is my attempt at intros for 7.1 through 7.5. There are 2 "FIXME" instances in the text that pertain to this question: how can we publish an access protocol that has a fixed endpoint? For example, a dCache instance might have a fixed gsidcap or gsiftp server for legacy clients that cannot deal with the SRM. I suppose we discussed this before the public comment phase, but I do not recall the outcome, so I went with the content of the "pc_r2" draft currently published on the GLUE web site: the access protocol would have to be published as an Interface. Comments? Thanks, Maarten ---------------------------------------------------------------------- 7.1 StorageService A StorageService represents a grid-enabled storage system, most often hosted by a single site, but possibly distributed over multiple sites. A StorageService makes StorageShares of given properties available to selected UserDomains, typically (not necessarily) through one or more explicitly identified StorageEndpoints. Data can be stored in or retrieved from StorageShares through one or more StorageAccessProtocols. A StorageShare is a composition of chunks from one or more DataStores. StorageShares may overlap. A DataStore represents a physical device that can hold data (e.g. a disk or a tape robot). Each DataStore is managed by a StorageManager, an instance of a particular product identified by the ProductName and ProductVersion. StorageServiceCapacity objects summarize capacity-related information for which details may be available associated to StorageShares and DataStores. 7.2 StorageServiceCapacity A StorageServiceCapacity summarizes capacity-related information for all the StorageShares and DataStores of a given homogeneous type. The summaries may be compared to the sums of the relevant StorageShareCapacity attributes for the StorageShares of the given type. Capacities of overlapping StorageShares must only be counted once. An inconsistency between a summary value and the corresponding sum of relevant attributes can occur if part of the capacity is not explicitly published, or if the attributes concerned could not all be exactly determined or recorded at the same time. The summaries may also be compared to the sums of the relevant attributes of the DataStores of the given type, where inconsistencies may arise due to similar causes. 7.3 StorageAccessProtocol A StorageAccessProtocol describes a protocol that can be used to store data in or retrieve data from StorageShares. The "file" protocol indicates that for ComputingServices given by ToComputingService objects the StorageShares are available through POSIX I/O. The mount point details are given by corresponding ToStorageService objects published by those ComputingServices. Most protocols require a negotiation between the client and a StorageEndpoint. For example, a StorageEndpoint implementing a version of the SRM protocol can be asked for a data transfer URL corresponding to a desired access protocol. An access protocol that does not require prior negotiation can be published as the Interface in a StorageEndpoint supporting that protocol [FIXME]. 7.4 StorageEndpoint A StorageEndpoint represents a service that can be contacted by clients to manage StorageShares and to store or retrieve data. The StorageEndpoint typically implements a control protocol given by the Interface, which allows for the manipulation of StorageShares and the properties of their data content. Access to StorageShares for storing or retrieving data often has to be negotiated through the given control protocol. The available access protocols can be published in StorageAccessProtocol objects. The StorageEndpoint Interface may also indicate itself an access protocol that does not require prior negotiation [FIXME]. The StorageEndpoint may be able to serve only a subset of the StorageShares within the StorageService, in which case that subset can be indicated through explicit associations with those StorageShares. 7.5 StorageShare A StorageShare is a composition of chunks from one or more DataStores. StorageShares that overlap have the same SharingID, which in that case must neither be empty nor the string "dedicated". A DataStore represents a physical device that can hold data (e.g. a disk or a tape robot). A StorageShare need not be composed of homogeneous devices. The AccessLatency gives the maximum latency category for a file stored in the StorageShare to be made available for reading. For example, if the StorageShare comprises both disk and tape, and data may need to be recalled from tape, the published AccessLatency is "nearline". The RetentionPolicy indicates the probability of the StorageShare losing data. For example, "custodial" represents a very low probability, while "replica" indicates that the StorageShare is not suitable for keeping the only copy of precious data, but can be used for keeping a replica of such data. The ExpirationMode indicates what happens to data whose lifetime has expired, if ever. The Identifier allows the StorageShare to be given a tag that is meaningful for the UserDomain(s) served by the StorageShare. For example, for version 2.2 of the SRM control protocol a StorageShare would represent a Space and the Identifier the corresponding SpaceTokenUserDescription. Capacity-related information is made available through StorageShareCapacity objects. A StorageShare need not be available through StorageEndpoints not explicitly listed. ----------------------------------------------------------------------

Dear all, if Glue 2.0 lists the Supported Security protocols, please, do not forget to add the one xroot supports for Alice: tkauthz Flavia Sergio Andreozzi wrote:

Dear all,

the next GLUE call is scheduled for Monday 2 February, 4:15 PM CET: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting2...

By the end of the weekend I plan to send the new GLUE draft and the list of open issues.

For those involved in the following action, please provide your contribution by Monday lunch time:

"Write descriptive introductory paragraph for each class to be added before each table * Sergio: Main entities * Balazs: 6.1-6.5 * Stephen: 6.6-6.10 * Maarten: 7.1-7.5 * Paul: 7.6.7.9 "

Today we have no call.

Cheers, Sergio