[tsc] Responses to Public Comments
Chris Kantarjiev
chris.kantarjiev at oracle.com
Fri Apr 20 18:22:47 CDT 2007
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 :-)
More information about the tsc
mailing list