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)