[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/topc4010

And reads:

> Page 3 (characteristics and goals) Infrastructure Virtualization It may be a
> characteristic of Grids (but not a necessary one).  I don't think it is a
> goal either (at least w.r.t. Infrastructure). I would remove that one.
> Further virtualization work is not being done (infrastructure-wise) in OGF,
> storage, network and server virtualization are all be defined, spec'd and
> implemented elsewhere.

This has been mentioned by a few others readers. I agree that OGF is not and 
should not be involved in the technology of virtualization, but I strongly 
believe that virtualized resources are an important component of grids going 
forward.

The suggestion that we change this to "Management of Virtualized Infrastructure" 
resonates with me, and I recommend that we change the document in that fashion.

> Page 3 insertion in Collaboration grid "and should no be" s/b "and should not
> be"

Thank you.

> Page 5 2nd para below Fig 1 "These three parts the requirements"  described
> was deleted.... s/b describe?

The current sentence is "These three parts, the requirements gathering, the 
standards work and the technical alignment, all operate simultaneously and in 
parallel.

That seems fine to me.

> Page 8 Capabilities table - lots of bookmark errors...

Yes.

> I like the addition of Maturity to Table 3.  For me it draws into focus the 
> areas that we need to agree upon and areas that need work.  I assume that 
> some in OGF would disagree with some of the characterizations of Maturity for
> some of the capabilities.  Further, I assume that even though there is a 
> broad maturity associated with the capability there may be functional gaps in
> the WG charter or specs referenced.  For instance, one could argue that the
> liberty alliance federated identity handles the Multiple Security 
> infrastructures capability.  In fact, I think the heart of the issue we need 
> to wrestle to the ground is that "better is the enemy of good enough".  When 
> can we just adopt commercially available techniques and implementations vs 
> when must we define and build from scratch?  This undercurrent has been 
> running through GGF/OGF since I have been a participant.  We need to use this
> document as vehicle to get those arguments on the table.  To that end, how
> would someone disagree, how do we empower that discussion and what artifacts
> do we need to capture from the outcomes....

I agree that we need to wrestle with this issue. I am not sure that this 
document is the right place to do it.

The bulleted list at the end of section 2 identifies, at least in passing, that 
this is an issue - and that there may already be a "concrete specification".
In addition, the last section of the alignment process description includes, in 
item 5, acknowledging, connecting to (and possibly adopting) the work of an 
existing standards body, and in item 6, forming a new group to create a 
specification for an existing technology.

We will consider adding something to the end of this section to clarify our 
desire not to boil the ocean.