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)
Folks, Here's my next one. Much easier than last night's. Same drill as before - object by the 25th. The comment is here: https://forge.gridforum.org/sf/go/topc4015 And reads:
Additional comments Page 10, Authorisation: The feedback for the OGSA Data WG notes that the architecture whereby a using service "calls out" to an authorisation service is inadequate for some use cases. Another example occurs when a portal wants to show only those services available to a given user; if authorisation is done by the service then the portal will not have the necessary information.
Page 10, Application Provisioning: Is it worth noting that possible solutions include the user of virtual servers?
Response: The first above sounds more like a message to OGSA Authorization WG. The TSC document can only echo what the experts are actually working on. I recommend that the message be carried directly to the Security area. We can certainly make that note about Virtual servers, as they are clearly on the roadmap. -- 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)
Here's my first response; I'm starting with the easy ones. Same drill as Dave's - object by the 25th. The comment is here: https://forge.gridforum.org/sf/go/topc4008 And reads:
I re-reading the TS&R document, I have one additional comment that may or may not be controversial ...
In the document, we start out Section 1.3 with a statement of vision "Distributed computing across multiple administrative domains". Although I like the simplicity of this statement, I am a little concerned that it excludes "distributed computing within an existing domain" I believe our stakeholders want grid architectures and standards "both within and across multiple administrative domains". Mark
We have reworded this several times, none of them completely satisfactory. Let me propose one more: "Distributed computing at (small-i) internet scale, both within and across administrative domains." I agree that our long-term vision needs to explicitly include operation within a single administrative domain, even if it is a large one.
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.
Here's another response. Same drill as Dave's - object by the 25th. The comment is here: https://forge.gridforum.org/sf/go/topc4012 And reads:
I absolutely agree that our management/deployment story must handle virtualized resources. Perhaps if we added 'management' to the bullet? And moved it down the list a bit...
Maguire_Tom@emc.com wrote:
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.
We will change the bullet to "Management of Virtualized Infrastructure".
Here's another response. Same drill as Dave's - object by the 25th. The comment is here: https://forge.gridforum.org/sf/go/topc4016 And reads:
Here are my comments on the draft.
Section 1.3 - In types of grids discussion, 'Collaboration Grids' is in bold, other types are not. Make this consistent.
Yes.
Section 2 - the last sentence of the OGF goal definition says "... build real operation grids using OGF-defined components.". I believe this should say 'standards' rather than 'components'. Component to me implies an implementation, a standard should allow for multiple implementations.
On the other hand, the phrase "OGF-defined standards" could lead the reader to believe that our goal does not allow for external standards - this is certainly not an impression we would like to leave. Defining a component and implementing a components are two very different things.
Section 4.1.3 - first sentence should read "... PERMIS [5], and XACML." rather than "... PERMIS [5], XACML."
Yes.
Section 5 - In the 'Current Status' discussion I suggest this be modified to follow the the same 3-tier recommendation convention as defined GFD.1. The current wording implies that having reference implementations and interop test preceeds a Proposed Recommendation, while GFD.1 says this is required to transition from Proposed to Draft Recommendation. So the steps might be recast as: Concept, WrkGrp, WG-Draft, Proposed-Std, Draft-Std, Grid-Std, Product, Deploy.
We should track GFD.1 accurately, but we also want to emphasize that there should be implementations and interop testing before the spec is finalized. We'll rework this section accordingly.
Table 3 - under Web services security the 'OGSA-SBP' specs should be 'OGSA-BSP' specs. Also, both of these have now achieved Proposed Recommendation status.
Thanks.
Table 4 - under security, web service protocol security, change 'OGSA Secure Channel" to "OGSA-BSP specs". Both of the BSP specs are applicable.
Thanks.
Here's another response. Same drill as Dave's - object by the 25th. The comment is here: https://forge.gridforum.org/sf/go/topc4006 And reads:
Regarding immediate tactical feedback (Nits:-)
1. All the page numbers are set to 18
Yes.
2. 1.2 - you still have the term "while section 4 we identify the current result of this process in the form of high value use cases and scenarios". I believe this should be "capabilities" which is the term I think we are now using
"... in the form of high-value capabilities and scenarios that need ..." ?
3. 1.3 - The last sentence "Our focus is on standards and tools to effectively build and utilize the last of these" is a little confusing... Is the "last of these "Grids built on dedicated resources ranging from blade servers in a corporate data center to tans-national collections of supercomputers" or does this statement only refer to "trans-national supercomputers". I would reword for clarity.
You read it correctly, but the possibility for confusion is noted. The entire paragraph needs work, as noted by other readers.
4. Section 3, in the paragraph below the picture, the word "to" needs to be included in the sentence "Each of these groups meets to capture requirements that are particular [to] that group.
Yes.
5. Section 3, "range of actions and responses", there seem to be some redundancy here. Bullet 4 talks about "ignore as out of scope" (not great language) and bullet 10 has the same idea. Bullet 2 "start a new standards group" and bullet 6 "form a new standards working group" also overlap. I would reword bullet 7 to make it less "Enterprise-specific" and clearer. Possibly something like ... "Form a new Research or Community group to develop a best practice document that might offer an interim solution until a more standardized approach can be matured and adopted."
Yes. Bullet 10 is redundant. Bullets 2 and 6 are different. Bullet 2 is plowing new ground, while bullet 6 is taking existing technology and preparing a formal specification of that technology, such that others may interoperate with it. We will make this distinction (more) clear - especially in light of comments that some readers had the impression that we are only interested in OGF-sourced technology.
6. Section 4, Title .... The title is "High Priority Capabilities" but then you go on to explain that "no priority has been associated with the list" - seems inconsistent. Also the first sentence needs CAPs
Yes, this is inconsistent. The intent is that these are important capabilities, but there is no internal rank ordering. We'll reword this.
7. I think you need to unify the "tables". Table 1 has Category/Capability, Table 2 has Capability but they are not organized by "Category" (except that our Areas are a type of Category :-). I would opt'd for changing table 2 to align with Category/Capability and loose the Area designation. This way you have a consistent table throughout showing (1) Category/Capability; (2) Category/Capability/OGF Specification/Status/Milestone; (3) Category/Capability/Group or Comment and Maturity level. I think this will simplify things a little.
Agreed that the Area column is probably not useful here. We'll investigate combining the columns - it will make it much obvious just how much work there is left undone!
Longer-term feedback for after the public comment period I think we need to bring into this document a little more of the broader context and landscape upon which we are operating. The notion that
(1) we don't want to or have to do all the standards for distributed computing and so we collaborate extensively with other Standards Development organizations and leverage existing and well adopted standards extensively needs to be better articulated
(2) we are no longer in a green field situation. Organizations around the world are building and operating grids today and thus our standardization efforts should be informed by both architecture and community practice. And ... we may want to state what our "architectural approach" or "principles" are for the reader in a future version
(3) I would continue to like to see work done on relating Categories/Capabilities to Use Cases to enable the reader to make the connection to relevance. I know this is continuing to be discussed ...
(4) not to state the obvious, but our current gap analysis needs quite a bit of maturing :-)
These are good comments, but currently out of scope :-)
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@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.
Folks, And a longer one: Comments from OGSA Data https://forge.gridforum.org/sf/go/topc4014 Responses in line:
Comments from the OGSA Data WG Page 8, Table: The list of data capabilities here does not reflect the OGSA architecture. I suggest that it be replaced with:
Data description Data access Data transfer Data storage Data replication Data federation Data caching Data security Data provisioning Session management Distributed transactions
This list includes areas that are currently addressed by the OGSA Data Architecture and additional areas that are relevant. Data provisioning has been addressed by the EGA Reference Model.
To update the list to the current OGSA Data thinking is an excellent idea, but this change is more substantial than a simple edit, so I would prefer to action this change in the next document version.
"Metadata" is not a capability. It is simply data that describes other data. There are many issues related to metadata, including formats, schemas, ontologies, consistency and more. Add particular ones if you wish, but don't just list " metadata".
At the level of generality addressed by the document, all the above apply. I believe that the reference covers all the sub categories you list, so I think we will leave it for now.
This table should list provenance tracking as a capability. This could be added to the data section or possibly another
I would push it to the next version.
Page 10, Authorisation: Note that the architecture whereby a using service "calls out" to an authorisation service is inadequate for some use cases. For example, the authorisation policy may be associated with the data being processed rather than the processing service.
As is an earlier response, this I believe is a more technical comment. But in any case it will probably still need to be a call out. We won't make any changes here until the next version.
Page 11, section 4.4: This should be called "Data transfer", or, if you insist, "Data movement". The body of the text correctly avoids the inaccurate assumption that all data is held in files.
This has been noted by several people and will be fixed.
Page 11, section 4.5: This should just be called "Data Provisioning". Data Grids include the other capabilities listed and they shouuldn't be lumped together. The first paragraph seems too general for inclusion here; everything it says is perfectly correct but it should appear earlier in the document.
These are good points and I this we can make these changes without disrupting the document.
I suggest that you add other sections called "Data Access" and "Storage". You might possibly others called "Data Replication" and "Data Federation".
These are certainly areas for inclusion, but this document is not aiming at the whole space, but rather an attempt hit high priorities. In the next version we may become broader, but this depends of the requirement gathering process in OGF. No changes are planed in this version.
Page 13, Table: "File Movement" -> "Data Transfer"
Agreed.
"Data Provisioning and Data Grids" -> "Data Access"
Above you suggested just Data Provisioning" I agree.
ByteIO should be listed under Data Access rather than Data Transfer.
Agreed. We should fix this.
Page 14, Table: "OGSA Data" should be listed against Data Access, Data Transfer, Data Replication, Data Storage, Data Federation and Data Security - or perhaps just against "Architecture". It should not be listed against Data Provisioning. The GSM-WG should be listed against Data Storage. Possibly DFDL-WG should be listed against Data Description.
Thank you. I agree with these changes, except I think that Data Provisioning is certainly within the remit of a Data Architecture WG.
Typos:
Page 2: The phrasing of the last sentence on page 2 could be read as saying that our focus is only "trans-national collections of supercomputers". This would disappoint most of our industry members.
Will fix.
Page 3, Collaboration Grids: "should no" -> "should not"
Will fix.
Page 8: "Table 2" -> "Table 1"?
Yes.
Page 8, Table: There are many references in this table to footnotes that do not exist.
There does seem to have been a word problem here. We will try to fix it.
Page 13: "Table 3" -> "Table 2"?
Yes.
Page 13, section 5.1: "Table 4" -> "Table 3", "Table 3" -> 'Table 2"?
Yes.
Page 14: "Table 4" -> "Table 3"?
Yes
Page 15: "Geoffery Fox" -> "Geoffrey Fox".
Yes. -- 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)
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)
participants (2)
-
Chris Kantarjiev
-
David Snelling