I gave the v5 primer a read. Overall, it’s a pretty good intro to OGSA and technical areas being addressed. My comments
 are below. I hope they’re helpful.

Regards,
Blair Dillaway

Abstract:
“After several years of development, consensus building, and experimentation there are a suite of OGSA specifications 
that have completed, and for which there are both commercial and academic interoperable implementations. “

Is Section 5 accurate? It shows that beyond OGSA BES there’s not much in the way of ‘commercial and academic 
interoperable implementations’.  Can you beef up the info on adopters and/or implementations in-progress?  If this was 
someone’s first exposure to OGSA they could easily get to section 5 and conclude this group is way too broadly focused 
and isn’t achieving much of practical value.

Section 1:
“Grid technology has been the “secret weapon” of many early adopters,”
I have no idea what you mean by ‘secret weapon’ and it seems a very strange characterization to me.

“While the precise definition of Grid is debated, common characteristics are that Grids tend to be large-scale and 
widely distributed, to require decentralized management, to comprise numerous heterogeneous resources, and to have a 
transient user population.”
I’d include dynamically changing collection of available resources as well.

“There is considerable overlap between the goals of Grid computing and the clear benefits of a service-oriented 
architecture (SOA) based on Web services.”
I’m not sure what point this sentence is making. Do you mean many Grid requirements can be satisfied by using SOA?  

Section 2:
“Don’t re-invent the wheel. Work when possible with other proven standards. For example, OGSA relies heavily on 
existing Web Services standards and profiles such as WSDL, JSDL, WS-Security, WS-I, and others.”
This entire section is acronym heavy – above text is one example. If you’re going to use acronyms you need to either 
define them or include a reference on first use. I bet few people outside OGF members know what JSDL is.

Section 3:
“Clients may compare the EPI’s contained in two or more EPR’s……” 
This is a detail that’s too low-level for this discussion. I’d remove it. I’d also shorten up the discussion of WS-
Addressing, just too much detail for this type of overview.

“There are other infrastructure services – many of which are still in development in various standards bodies, e.g., 
reliable messaging. We look forward to leveraging those efforts.”
Its easy to read this as implying OGSA is known to be incomplete and you’re waiting on other stds bodies to fill in the
 gaps. If you view these as potentially interesting, but not required, enhancements you might want to say so.
 
“These are the major issues to be addressed by EMS. As one can see, it covers the gamut of tasks, and involves 
interactions with many other OGSA services (e.g., provisioning, logging, registries, and security.) that are expected to
 be defined by other OGSA capabilities. “
Perhaps you mean other OGSA specifications in development?  If not, I’m not sure what other OGSA capabilities means 
here.

“OGSA security model addresses trust management via the profiling of mechanisms defined in the WS-Trust specification 
in order to realize trust relationships as rules and policies for mapping identities and credentials among the involved 
organization domains.  “
Ws-Trust focuses on a protocol for obtaining, exchanging, validating, … security tokens. Section 2 briefly discusses 
trust policies and mentions some mechanism for establishing the base trust policy. These are, however, non-normative and
 not required by WS-Trust.  It also doesn’t address issuance policy at a token service. So its not really a sufficient 
basis for establishing “trust  relationships as rules and policies”.
I find it surprising the subject of delegation of access rights isn’t even mentioned.

Section 4:
I think the examples are okay. I do suggest you try to distill them down as they are quite long, complex, and jargon 
filled for this type of paper. I think it will resonate better with readers to briefly describe a key problem area(s) 
where interop stds are essential and then reference the applicable OGSA specification work.