Here's another response. Same drill as Dave's - object by the 25th. The comment is here: https://forge.gridforum.org/sf/go/topc4006 And reads:
Regarding immediate tactical feedback (Nits:-)
1. All the page numbers are set to 18
Yes.
2. 1.2 - you still have the term "while section 4 we identify the current result of this process in the form of high value use cases and scenarios". I believe this should be "capabilities" which is the term I think we are now using
"... in the form of high-value capabilities and scenarios that need ..." ?
3. 1.3 - The last sentence "Our focus is on standards and tools to effectively build and utilize the last of these" is a little confusing... Is the "last of these "Grids built on dedicated resources ranging from blade servers in a corporate data center to tans-national collections of supercomputers" or does this statement only refer to "trans-national supercomputers". I would reword for clarity.
You read it correctly, but the possibility for confusion is noted. The entire paragraph needs work, as noted by other readers.
4. Section 3, in the paragraph below the picture, the word "to" needs to be included in the sentence "Each of these groups meets to capture requirements that are particular [to] that group.
Yes.
5. Section 3, "range of actions and responses", there seem to be some redundancy here. Bullet 4 talks about "ignore as out of scope" (not great language) and bullet 10 has the same idea. Bullet 2 "start a new standards group" and bullet 6 "form a new standards working group" also overlap. I would reword bullet 7 to make it less "Enterprise-specific" and clearer. Possibly something like ... "Form a new Research or Community group to develop a best practice document that might offer an interim solution until a more standardized approach can be matured and adopted."
Yes. Bullet 10 is redundant. Bullets 2 and 6 are different. Bullet 2 is plowing new ground, while bullet 6 is taking existing technology and preparing a formal specification of that technology, such that others may interoperate with it. We will make this distinction (more) clear - especially in light of comments that some readers had the impression that we are only interested in OGF-sourced technology.
6. Section 4, Title .... The title is "High Priority Capabilities" but then you go on to explain that "no priority has been associated with the list" - seems inconsistent. Also the first sentence needs CAPs
Yes, this is inconsistent. The intent is that these are important capabilities, but there is no internal rank ordering. We'll reword this.
7. I think you need to unify the "tables". Table 1 has Category/Capability, Table 2 has Capability but they are not organized by "Category" (except that our Areas are a type of Category :-). I would opt'd for changing table 2 to align with Category/Capability and loose the Area designation. This way you have a consistent table throughout showing (1) Category/Capability; (2) Category/Capability/OGF Specification/Status/Milestone; (3) Category/Capability/Group or Comment and Maturity level. I think this will simplify things a little.
Agreed that the Area column is probably not useful here. We'll investigate combining the columns - it will make it much obvious just how much work there is left undone!
Longer-term feedback for after the public comment period I think we need to bring into this document a little more of the broader context and landscape upon which we are operating. The notion that
(1) we don't want to or have to do all the standards for distributed computing and so we collaborate extensively with other Standards Development organizations and leverage existing and well adopted standards extensively needs to be better articulated
(2) we are no longer in a green field situation. Organizations around the world are building and operating grids today and thus our standardization efforts should be informed by both architecture and community practice. And ... we may want to state what our "architectural approach" or "principles" are for the reader in a future version
(3) I would continue to like to see work done on relating Categories/Capabilities to Use Cases to enable the reader to make the connection to relevance. I know this is continuing to be discussed ...
(4) not to state the obvious, but our current gap analysis needs quite a bit of maturing :-)
These are good comments, but currently out of scope :-)