[tsc] Responses to Public Comments

[David Snelling]

Folks,

Here are the last three Public comments I took charge of responding  
to. Chris K has volunteered (I think that's the word) to draft the  
others. Thank you Chris.

Same drill as before: Objections by the 25th.

email #6
https://forge.gridforum.org/sf/go/topc4011

This one includes a bit of threaded discussion along with the  
original comment:

>>> >>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.
> >
> >I put that in there, because the experience at Oracle is that
> >virtualization of
> >resources is a big part of the grid story expected and experienced
> >by our
> >customers. My intention there was mostly to try to recapture a bit
> >of mindshare
> >for OGF.
> >
> >That said, I agree that we have no business defining/spec'ing/
> >implementing
> >virtualization, but our deployment/management strategy must (I
> >assert) include
> >an understanding of managing virtualized resources.
> >

The response provided in the thread is I think correct. We should  
make it clear that specifications at this level are out of scope, but  
I would reserve the right for the OGF to develop Profiles in this  
area where specific support for virtualization is needed in a Grid  
context.

email #4
https://forge.gridforum.org/sf/go/topc4009

> >I also appreciate the brevity and clarity of the definition.
> >I think that defining the term 'Grid Computing' in such a
> >short and concise manner is one of the tasks of OGF.
> >
> >Also, but unrelated, I happen to agree with the definition.
> >The usage of Grid technologies within a single
> >administrative domain is thereby not excluded (just as many
> >programs use TCP for communication even if they are not
> >running distributed).
> >
> >Extending the Daves definition in a way that it covers all
> >possible use cases, and makes all potential users happy, is,
> >IMHO, impossible, and would weaken the definition.

The intra-enterprise Grid was always intended as part of the  
definition. In the current version we have already clarified the  
statement to make sure this is clear in the text.

> >One could, for example, say: the definition does not say
> >anything about data management / virtualization / web
> >services / APIs / protocols /...   But by mentioning one of
> >those terms, one would leave out 10 others.  The definition
> >Dave gives is concise, w/o limiting it to a small number of
> >use cases.
> >
> >Sorry if that answer is somewhat long, but the definition
> >as-is is actually, IMHO, worth to go on the OGF flag... :-)

Thanks, the definition currently reads:

> “Scalable distributed computing across multiple heterogeneous  
> platforms, locations, and organizations.”

With the rest of the paragraph reading:

> The notion of distributed computing as used in this definition  
> includes a wealth of highly complex technologies, some still the  
> focus of research. This definition includes the degenerate case of  
> a homogeneous HPC cluster. It also addresses operation across a  
> wide area and possibly multiple domains of administrative control.  
> The security, privacy, economic, and political aspects of Grids  
> increase by orders of magnitude with the introduction of Internet  
> scale operation.


email #2
https://forge.gridforum.org/sf/go/topc4007

> >1.  There is no use case relating to workflow and to data aware
> >scheduling.  It seems that the list was conceived in such a way
> >that most of the functions are somehow addressed by one or several
> >OGF specifications.

This is not entirely true. Work-flow standards were not ignored, they  
just didn't make the cut for the first version. It is certainly on  
the list for later versions.

> >2.  In Section 5.0 (table 2), only the base specifications are
> >mentioned, eg JSDL 1.0. What about JSDL 1.1, 2.0, ...? The roadmap
> >should show the predicted evolution of the standards instead of
> >just those specifications that are in progress today.

At present we are trying to get more groups to outline future  
roadmaps. When this is done we will consider this. But there is also  
a negative aspect to point to second generation specifications, as it  
can delay adoption. The aim with all our second generation specs is  
that they are extensions of the earlier ones, but until this is well  
known and accepted there is a risk.

> >3.  The document would also gain in providing the dependencies
> >certain OGF specifications may have on other OGF, W3C, OASIS, IETF
> >specifications.  This would allow the reader to see how the
> >proposed roadmap may be affected by external dependencies.  And
> >where relevant, it should list other specifications that may depend
> >on OGF specifications.

This was considered, however, it was dropped in the interest of  
brevity. The information is available from the working groups or more  
detailed roadmaps, e.g. the OGSA roadmap. This document is not a  
cookbook for building grids, where such detail would be needed. It is  
a more general document for a wider audience.

> >4.  Section 3, assessment criteria:  There should be a 4th point
> >under question 1:  "d) How universal is the requirement to the
> >community at large?"

Good point. We can add this with out I think creating too substantive  
a change.

> >5.  Table 1 (Capabilities of Grids):  Suggest to highlight in bold
> >the capabilities that are identified as priority targets further in
> >the section.  Not sure service level management should be in
> >Operations vs Resouce Management. One capability of Grids which
> >seems to be missing is ?grid enablement tooling? (to help deploy
> >legacy/existing applications onto a Grid).

We are considering additional entries for the next version. In  
general the categories are more for organizational purposes and clear  
several issues cross several categories.

> >6.  Table 3 (medium term and gap analysis):  In this table, the
> >gaps need to be highlighted - otherwise they get lost within all
> >the other data in the table.

I think it best to leave it as it is. the table and the document is  
general purpose. Some will be looking for gaps to work on, others  
will want to know what is ready for prime time.

> >7.  The doc needs a thorough reading by someone not intimately
> >familiar with all the text because there are many grammatical and
> >familiar with all the text because there are many grammatical and
> >spelling errors - and I'm not providing them here because you
> >requested text instead of markup.

Because of the importance of this document, we will have some one  
take a close looks, probably out OGF Editor.

-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-208-606-4649 (Office)
     +44-7768-807526  (Mobile)