Comments on the Technical Document:
 
- The stated purpose in section 1.1 is "2. Provide a mechanism to align key stakeholder        requirements with OGF 
technical directions and  priorities". It should be clear that the stakeholder
 requirements" influence OGF's technical decision and priorities, not the other way round.
 
 - The definition of "Cluster Grid" excludes dynamic provisioning and scheduling; this is mapping the traditional use of
 Clusters, but may be to restrictive within 3-5 years

  - for a five-year objective, the section 2 is too weak. The *direction* is OK - the metric should be it should be 
about uptake in the real world, but as written, uptake of a single OGF standard in two deployments would constitute "
mission accomplished" ... this body should be more ambitious. OGF's impact has to be more substantial.

  - the "alignment meetings" as discussed on page 4 are to much  focused at the academic constituency. I'd like to see a
 mechanism to include the feedback from *relevant* commercial parties - the "Enterprise Voice of Community" that is 
mentioned will likely not be adequate.

  - the figure in section 3 emphasizes "architecture" as the main output from standards groups - but the main results 
should surely be specs of the semantic&interfaces of Grid *components* or *capabilities*.

  - which OGF body actually provides or allocates the resources that  TSC can plan with? Will the TSC be able to re-
orient standards or working groups?  Can it shut down activities and move resources elsewhere?
 
- in the high priority issues list, no mention is made of  virtualization (CPU, I/O, network), virtual organization/SLAs
, Grid management (resources, users). These areas must not be neglected...

  - section 4.1: Grid APIs are important, right. SAGA is a good start,  but it does not address the needs of middleware 
developers, and it purposefully did *exclude* most of the commercial use cases. It should be clear that SAGA is an 
example for a part of the academic Grid apps work.

  - section 4.2: "Job Submit" is too narrow. This should be about how to define, discover, use and monitor Grid 
computing resources. OGF needs to accommodate the needs of long-running, server-style applications (like DB engines) in 
addition to the "job submit" model.

  - section 4.3: please also look at how to do *many, small-grain* data access/transmit operations. This actually is a 
pain-point  with today's OGF Grid standards ... not everybody wants to transmit a 100 Gig file.

  - section 4.4: What about provisioning the *execution environment*?  What about virtualization?

  - section 4.5: Data provisioning - does not cover the use case where persistent data repositories are accessed over 
the Grid. Seems  to dive architecture/implementation issues prematurely.

  - section 4.6: for security, why not simply state as a goal to use/invoke already generated security standards and 
methods where applicable vs. create new ones?

    - section 4.6.1: the one significant aspect Grids bring to the table is the need for delegation. Basically 
everything else should be available from existing standards.

    - section 4.6.2: should track and use whatever the WS community defines here. WS-I Basic Security is a good first 
step. The text about credentials seems to belong in 4.6.1, not here.

    - section 4.6.3: again, have to work with existing authorization  systems - no way around that. Interestingly, 
Active Directory is not even mentioned - must include the industrially relevant systems here. Why not build a "Basic 
Profile" (aka a simple,  portable set of interfaces that covers the basic functionality) and then take it from there? 
Don't think Grid has specific requirements to authorization ...
 
  - table 1: Grid API row disregards commercial use cases. File  movement: GridFTP is at odds with many network security
 policies. Apps provisioning is missing anything on virtualization.