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

And reads:

 > Feedback on the OGF Technical Strategy document
> From: Tony DiCenzo Oracle
> 
> 1. The time frame (06-10) seems a bit stretched, considering the pace of
> technological change.

Understood, but it attempts to take into account the relatively slow pace of 
standards work, in particular the time it takes to achieve adoption of newly 
released standards.

> 2. in the intro -- the mission is to accelerate grid adoption worldwide. To
> build an international community and to make it an open forum is the way that
> will be done, ie the strategy, not the mission itself.

We'll take this under advisement; it's a worthwhile distinction.

> 3. I think it correctly identifies why the strategy is important.
> 
> 4. I think the primary job of the TSC is more than formulating the strategy.
> I see the job as formulating the strategy and then monitoring the
> implementation and revising it when and if necessary. Stating it the first
> way implies the TSC will disband after the Strategy is set, and of course it
> won't.

Yes, and see below (and section 3 of the doc).

> 5. I think the numbering in section 1.2 document structure may be wrong.
> There are two references to Section 5. Maybe they should refer to 5.1 and
> 5.2?

Yes, there are many numbering issues in this version.

> 6. The way PP 2 in section 1.3 is written it seems to imply Grid started with
> Seti at home. I believe grids were around before that.

Several readers have identified problems with this paragraph and we will rework 
it to clarify.

> 7. Did you notice all the pages say number 18????

Yes.

> 8. In the PP on Collaboration Grids, you might want to note these are
> primarily found in e-Science.

and fix the typos.

> 9. In the same vein, you might want to note Data Center Grids and Cluster
> Grids can be found in both Commercial Enterprises and e-Science.

Yes.

> 10. Section 2 -- interesting way to state the goal. Doesn't say how much of
> the grid has to be OGF- defined. Doesn't say that advanced capabilities will
> or will not be available. Doesn't say if the goal will be satisfied if 2
> customers does it or a thousand. (would need to be at least 1 commercial and
> one academic).  Doesn't say if there needs to be any measurable performance
> gain. Doesn't state the readiness and completeness of the technology, nor
> does it suggest the customers would state their grids are built upon an
> OGF-defined or OGF supported grid architecture.
> 
> In essence it doesn't feel like a technical goal to me. Feels weak to me.
> (certainly isn't as sharp as putting a man on the moon and bring him back).
> 
> But I may be too negative here. If what you are saying is that the strategy
> defined here is what is necessary to meet that goal, then it migth be ok. let
> me think more about that as I read on.

*(Not sure what to respond to this, actually.)*

> 11. i would like it better if the last sentence in section 2 said "To achieve
> the goal, the strategy defined in this report:....." The bullets would also
> need to be tweaked.

OK.

> 12. Section 3. It doesn't say it (perhaps it should) but it seems to imply a
> major aspect of the strategy is to employ an alignment process.

> 13. Section 3...I note this section say more about the 'job' of the TSC after
> the strategy is set. I knew it wouldn't be easy for the TSC to just fold
> shop. :)

Yes.

> 14. Section 4. question: does the strategy for secutiry employ modern
> secutiry techniques that are already used and being widely considered by the
> industry? I think it does, and ity would be a strong point to say so.

OK.

> 15. Section 4.4 File movement. This sounds batch and e-science oriented. It
> fails to recognize the interest in transaction oriented commercial apps where
> data might be transactional. I think that should be expanded to show
> sensitivity to the commercial customers needs.

OK. We're distinguishing between file movement and data provisioning/data grids 
as separate capabilities.

> 16. Section 4.6 I don't understand where this grid api came from or what it
> does.

SAGA is the output of the Simple API for Grid Apps RG, 
https://forge.gridforum.org/sf/projects/saga-rg and is focused on consolidating 
application driven API specifications.

> 17. section 6...isn't that covered in section 4...why not just make section 6
> the same as 4 and delete 4?

"All OGF documents must have this section."

Thanks.