Mass Move

Sorry for my delay in looking this over.  This document has clearly
received lots of careful attention, and is nicely written and
presented.  I did not find any changes to suggest.

As GGF Editor, I approve publication of this document.

It will be published as GGF-30.

I've updated the referece to OGSA RM to reflect GFD #45.  The OGSA 
glossary will be GFD #44.

I'm uploading the changed document for Stacey to confirm final
formatting.  I've applied the GFD headers, and the reference to OGSA
RM, but no other changes.  Thanks again to the authors & WG for
excellent work on this document.

Note: When this document is approved for publication it was be numbered as GFD.030

These comments were provided during AD review prior to Public Comment, but did not warent a delay to Public Comment. There are included here for 
completness.


AD Comments (D. Snelling)

1. Introduction

The introduction accurately reflects the actual nature of the document. Anyone reading it will not be surprised or disappointed with the contents that
 follow. However, someone omitting the Introduction and relying on their expectations may find the rest of the document more abstract than expected.  
The abstract might be used to point this up or even other chapter refer back to the Introduction by way of setting the context.

2. Requirements

Staring with a one line summary of each on the OGSA Use cases (already in the editor's pipeline), this chapter is one of the most concise (7 pages) 
and yet complete description of what Grid computing (both scientific and commercial) is all about.

3. Capabilities

Sub sections 3.1. and 3.2 provide a good picture of how the many and complex parts of OGSA fit together. There are few problems here:

   - What are the fine arrows on figure 1 for. They are not intuitive
     nor are they referred to in the text.

   - The third bullet at the start of section 3.2 needs to be elaborated.
     This is a very important aspect of OGSA that distinguishes it from
     traditional approaches to software architecture. The approach is needed
     to realize the complexity of OGSA, without creating many artificial,
     thin layers. The nature of the coupling of Resources to the capabilities
     should be used to motivate the OO-like content in an otherwise SOA based
     architecture.

   - The service relationships section need to be separated out as a section
     in it's own right and elaborated much more clearly and precisely. The
     vertical stacking in Figure 3 is not motivated.

Sub section 3.3, Infrastructure, could be more forceful in identifying these components. This would provide the community with a very clear indication
 of where OGSA starts and what should be understood first when building OGSA compliant constructing. The choices indicated are the correct one from my
 perspective and the document should make the case for them more forceful.

Sub Section 3.4: Execution Management Services

The bullet list in 3.4.1 basically delineates a rough event/state model for tasks. presented as such would help the reader follow the discussion. It 
is not quite clear how Figure 4 relates to the service categories outlined in 3.4.3. Otherwise, OK.

Sub Section 3.5: Data Services

Given the reuse of the Supply/Demand model, perhaps it could be abstracted to cover all of OGSA. In which case it could probably be better described. 
In fact the process of attempting to abstract it would probably help clarify it's use even if it doesn't generalize well. Otherwise, this section is 
very strong.

Sub Section 3.6: Resource Management Services

Two sections here need more elaboration. Section 3.6.3 need more detail. I realize that much of the management detail will actually be provided by 
WSDM, but there are several higher level capabilities that could be presented in more detail. The other is section 3.6.5. The goal of an architecture 
document is to elucidate not just the interfaces that are needed, but how they interact. The way in which WSDM builds on WSRF is an example of what I 
am referring to, but that example would not be necessary here.

Sub Section 3.7: Security Services

Security is always a complicate issue. This section is nonetheless pretty well done. Now that WS-Security is a published specification, it should be 
referenced along with the White Paper. I would like to see a more business related use case analyzed in this section, e.g. dynamically arranged 
auction on the Grid.

Sub Section 3.8: Self Management Services

This is a difficult section to address. The nature of "self-management" seems more like a required property of management, rather that a component of 
the architecture itself. Might this section simply be an implementation of Resource Management rather than a separate section of the architecture? 
What are the interfaces that are required to implement Self Management? Are they actually different than Resource Management and provisioning.

Sub Section 3.9: Information Services

This is the only section that uses UML. This seems to point the way toward the V2 document. These should be replaced with more abstract approaches in 
line with the other sections. Then V2 should address this level of detail for all sections. This section should elaborate the relationship to WSN and 
possible WS-RM standard.

The rest of the document is fine, particularly the Glossary, an artifact that the Grid community has needed for a long time.

Attached pdf file I re-created has all diagrams.
Thanks Charlie.