[tsc] Responses to Nordugrid Public Comments

[David Snelling]

Fellow TSC-ers,

Here is my suggestions wrt to the Nordugrid comments:

https://forge.gridforum.org/sf/go/topc4022

If any TSC members object to my responses, please say so before the  
next call, April 25th. In the mean time, I will assume that you have  
no objections and start working on the document - time permitting.

General Comments:

1) They ask for more insight into the tactics we will use to promote  
our standards. As these are currently under development, it is  
premature to include them in this draft, but the plan already is that  
this type of information will be provided in future versions of the TSD.

2) A reference to the TSC charter will be included in the current  
version before publication. With respect to requirements gathering,  
the overall strategy is already described, and more detailed  
approaches are under development and will be included in future  
releases, e.g. a description of vendor adoption forums.

3) The  inclusion of  shared clusters within a single organization  
was always intended to be in scope and the language has been clarified.

4) The definition of resource has always been assumed to be very  
broad and to specifically include non-compute resources. The document  
will be updated to reflect this intension.

5) We confirm the importance of commercial deployment of Grid beyond  
the traditional Supercomputing context.

6) The intension is to be as consistent with the OGSA Glossary as  
possible. This will be rechecked before publication, but it is  
sometimes difficult to stay in sync, as the OGSA glossary is also  
evolving.

7) We acknowledge that Information capabilities related technology  
appear to be scattered around the technical space in OGF. This is in  
fact the state of affairs and the TSD reflects this. The observation  
is however valuable and the TSC will discuss this at some point with  
an eye to advising the steering committee.

8) We expect that more detail on the security area, including  
Authentication and VO will appear in the next version of the TSD. In  
fact, since this draft of the TSD there has been a marked increase in  
activity in this area.

Specific Detailed comments:

Page 2: Will do.

Page 3: We will attempt to make these positive definitions, rathe  
"what it is not" definitions, as you suggest. We will add these  
references.

Page 4: We do not believe that at this point quantitate numbers can  
be applied, hwever we take your point and will se if the language can  
be made more precise. "Compliance" intentionally omitted here, as OGF  
has no compliance program. We left the component very open ended to  
allow for the inclusion of community practices as well as just  
standards. WRT the use cases, they were taken, in this version from  
the OGSA use case document, and a reference to that is provided.

Page 5: Will fix "Uses cases." We will attempt to sync up the text  
and the diagram. The input from other groups is an evolving area,  
which will be  addressed in more detail in the next version.

Page 6:  Will fix the hyphens.

Page 7: I don't follow this comment. Sorry.

Page 8: Will fix table numbering and foot note placement.  The  
changes with respect to the OGSA document are intentional, as  
thinking has evolved and the TSD has a wider remit than just OGSA.

Page 9: As noted above this a recently active area and will certainly  
feature in the next version.

Page 10: WRT the authorization issue, I assume you are asking for  
specification work on authorization attributes. If so, a good  
starting point is the already published "Attributes used in OGSI  
Authorization: GFD.57. If not, I don't understand.  With respect to  
provisioning, a working group to  profile ACS and CDDLM to form a  
simple subset suitable would be the best short term strategy. At the  
moment there seems to be little activity beyond the existing  
specifications, hence it is not currently viewed as a high priority.  
The Job submit issues is an artifact of an earlier version. This can  
be fixed. Also, the simple use case is seen as very critical, since  
even here there are no existing standards. We will look at the text  
and see it is possible to clarify the details. I believe that the HPC  
Profile exactly matches your need with respect to job execution  
interface (subject to security being provided independently as is  
intended).  With respect to resource description, see above under the  
information model discussion.

Page 11: We will check the naming of the data movement category, I  
think you are right, data Movement is better. With respect to Data  
Provisioning, it is seen as a requirement in many areas and we see it  
as critical in the boarder sense of Grid computing. We will add  
another reference to the RM.

Page 13: Where possible we can update these, but listing met  
milestones in an evolving document is not a problem I think. I agree  
again on the data Movement issue. We will check the apparent  
contradiction, but I believe this is what we meant to say.

Page 14:  Will try to place the footnotes better, but tools are  
limited. "Maturity" refers to the capability not the working groups  
in question, some young groups can have very mature specifications.  
he two are independent of each other.  I would agree that "Evolving  
might be a better tag for Information Models.



One PC down 11 to go!

-- 

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)