[tsc] Responses to Public Comments

[Chris Kantarjiev]

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 :-)