On the whole, a very readable document which strikes the right balance
between being readable as a self-contained document and referring to
external resources.  Clearly a lot of work has gone into this.

The comments below should be considered more "thinking out loud" mode
rather than criticism.

As a high level note, the most obvious benefit from this OGSA
architecture is the ability to implement a modular architecture, eg. a
data federation.  The components listed in chapter 10-13 could
usefully be expanded upon.

Another useful aspect is the notification systems where web services
are well suited - we //dons storage service provider hat// have
customers who wish to be notified of events - e.g. data migrated to
tape, checksum values, replicas created - this could be explored
further.  Another thing that could be investigated further is
publishing capabilities for complex hierarchies.

I read 1-9 carefully and had a number of nitpicks, some of which are
included below.  I also read the rest of the document but slightly less
carefully.


pp.4,6,7,9,14,20,28,32,35: Ugly Word "Error source not found"
references.

p.5: I like the overview of OGSA services etc, but the Key to Fig 1
doesn't read easily: "A possible interface for a" - service.

2.9. Some of this appears to be properties of data ("currency of
data"), some would be fluctuating with time such as throughput and
time to satisfy an access request.

2.10. Nitpicking: what does "In the remainder of this document we call
out specific places where a data service must consider how it will
determine what storage to use" mean?

3. Nitpicking but shouldn't the first bulleted item not be bulleted?

3.2. On occasion, examples would be helpful - if it's possible to give one
which is not a page of XML.

4. Er, I wouldn't call the site "inherently secure".

More importantly perhaps, what is the point of imposing security at
the OGSA WS level if it can be circumvented at the site level.  I
know, this is outside the scope of this document.

Some other security questions.  Geographical location is just one
aspect (which may reveal too much about the client), and how do you
know the client isn't lying to you about its location anyway?

5. Nitpick. Why is replacing a policy not just a special case of
updating the policy (viz, by updating everything).  If replacing (as
opposed to updating) is used to "delete" parts of policies, shouldn't
that be a separate action?

6.2. "There is work required here to define a set of generic data
service properties. Currently we are not aware of any standards body
looking into this."  There is some work being done in collaboration
between GSM-WG and GLUE-WG.

Regarding resource description, one major architectural issue we /dons
GLUE and GSM hats/ have encountered is in the distinction between
dynamic and static resource descriptions.  If the dynamic descriptions
are used for resource discovery and selection, then the usual race
conditions apply: what if it isn't timely enough, if someone else
used the resource, etc.

More generally, it has proved extremely difficult to define what is
"used" and "available" capacity in general storage systems.
Modern storage systems can be extremely complex beasts
(not mentioning names here *cough*)

7. 

In table 2, I notice you need "query transfer status" - and you need
an option to summarise the transfer: when it started, when it
finished, peak rate of transfer, how many bytes transferred, possibly
which protocols it used for the transfers, maybe even which networks.

In data transfer, different optimisations may be required.  For
example, you should be able to say to the transfer service: "transfer
this data as quickly|cheaply|efficiently|securely as possible"
(options being possibly mutually exclusive)

For example, the most efficient transfer can decide to wait till a
high bandwidth network is available and then use that - and...