Technical Strategy Document

Folks, This is now (I believe) ready for Public Comment. I have done as much as possible with the time and effort available (mine and other's). The process we agreed to at the F2F is as follows: 1) Between now and next Friday, this document is in "WG Last Call", with the combined forces of the GFSG and the TSC acting as the WG. 2) Please for minor changes send text-only based suggestions in an email to me, but the document should be pretty clean now. 3) Major suggestions for future work should be emailed to me for inclusion in the trackers for later versions. 3) Major objections at your peril. This version is changed tracked, except for the tables 1 and 3, which are all new. Enjoy. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

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. Page 3 insertion in Collaboration grid "and should no be" s/b "and should not be" Page 5 2nd para below Fig 1 "These three parts the requirements" described was deleted.... s/b describe? Page 8 Capabilities table - lots of bookmark errors... 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.... Tom _______________________________________________ Tom Maguire +1(845) 729-4806 -----Original Message----- From: tsc-bounces@ogf.org [mailto:tsc-bounces@ogf.org] On Behalf Of David Snelling Sent: Friday, January 19, 2007 11:48 AM To: GFSG GFSG; TSC Subject: [tsc] Technical Strategy Document Folks, This is now (I believe) ready for Public Comment. I have done as much as possible with the time and effort available (mine and other's). The process we agreed to at the F2F is as follows: 1) Between now and next Friday, this document is in "WG Last Call", with the combined forces of the GFSG and the TSC acting as the WG. 2) Please for minor changes send text-only based suggestions in an email to me, but the document should be pretty clean now. 3) Major suggestions for future work should be emailed to me for inclusion in the trackers for later versions. 3) Major objections at your peril. This version is changed tracked, except for the tables 1 and 3, which are all new. Enjoy. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

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. Best, chris

David, Thanks for moving this document along and maturing the content and my thanks to the entire TSC for the hard work and thoughts! Regarding immediate tactical feedback (Nits:-) 1. All the page numbers are set to 18 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 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. 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. 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." 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 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. 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 :-) Thanks again to the team. I think this is a reasonable start and I very much appreciate the hard work that it has taken by the team and contributors to reach this first milestone. All the best, Mark Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org -----Original Message----- From: gfsg-bounces@ogf.org [mailto:gfsg-bounces@ogf.org] On Behalf Of David Snelling Sent: Friday, January 19, 2007 10:49 AM To: GFSG GFSG; TSC Subject: [gfsg] Technical Strategy Document Folks, This is now (I believe) ready for Public Comment. I have done as much as possible with the time and effort available (mine and other's). The process we agreed to at the F2F is as follows: 1) Between now and next Friday, this document is in "WG Last Call", with the combined forces of the GFSG and the TSC acting as the WG. 2) Please for minor changes send text-only based suggestions in an email to me, but the document should be pretty clean now. 3) Major suggestions for future work should be emailed to me for inclusion in the trackers for later versions. 3) Major objections at your peril. This version is changed tracked, except for the tables 1 and 3, which are all new. Enjoy. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

Dave, 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 mulitple 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 mulitiple administrative domains". Mark From: Linesch, Mark Sent: Wednesday, January 24, 2007 11:35 AM To: 'David Snelling'; GFSG GFSG; TSC Subject: RE: [gfsg] Technical Strategy Document David, Thanks for moving this document along and maturing the content and my thanks to the entire TSC for the hard work and thoughts! Regarding immediate tactical feedback (Nits:-) 1. All the page numbers are set to 18 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 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. 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. 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." 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 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. 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 :-) Thanks again to the team. I think this is a reasonable start and I very much appreciate the hard work that it has taken by the team and contributors to reach this first milestone. All the best, Mark Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org -----Original Message----- From: gfsg-bounces@ogf.org [mailto:gfsg-bounces@ogf.org] On Behalf Of David Snelling Sent: Friday, January 19, 2007 10:49 AM To: GFSG GFSG; TSC Subject: [gfsg] Technical Strategy Document Folks, This is now (I believe) ready for Public Comment. I have done as much as possible with the time and effort available (mine and other's). The process we agreed to at the F2F is as follows: 1) Between now and next Friday, this document is in "WG Last Call", with the combined forces of the GFSG and the TSC acting as the WG. 2) Please for minor changes send text-only based suggestions in an email to me, but the document should be pretty clean now. 3) Major suggestions for future work should be emailed to me for inclusion in the trackers for later versions. 3) Major objections at your peril. This version is changed tracked, except for the tables 1 and 3, which are all new. Enjoy. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

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. 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... :-) Cheers, Andre. Quoting [Linesch, Mark] (Jan 26 2007):
Dave,
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 mulitple 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 mulitiple administrative domains". Mark
From: Linesch, Mark Sent: Wednesday, January 24, 2007 11:35 AM To: 'David Snelling'; GFSG GFSG; TSC Subject: RE: [gfsg] Technical Strategy Document
David,
Thanks for moving this document along and maturing the content and my thanks to the entire TSC for the hard work and thoughts!
Regarding immediate tactical feedback (Nits:-)
1. All the page numbers are set to 18 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 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. 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. 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." 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 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.
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 :-)
Thanks again to the team. I think this is a reasonable start and I very much appreciate the hard work that it has taken by the team and contributors to reach this first milestone.
All the best,
Mark
Mark Linesch: Open Grid Forum (OGF): Hewlett Packard 281-514-0322 (Tel): 281-414-7082 (Cell) mark.linesch@hp.com : linesch@ogf.org
-----Original Message----- From: gfsg-bounces@ogf.org [mailto:gfsg-bounces@ogf.org] On Behalf Of David Snelling Sent: Friday, January 19, 2007 10:49 AM To: GFSG GFSG; TSC Subject: [gfsg] Technical Strategy Document
Folks,
This is now (I believe) ready for Public Comment. I have done as much as possible with the time and effort available (mine and other's). The process we agreed to at the F2F is as follows:
1) Between now and next Friday, this document is in "WG Last Call", with the combined forces of the GFSG and the TSC acting as the WG.
2) Please for minor changes send text-only based suggestions in an email to me, but the document should be pretty clean now.
3) Major suggestions for future work should be emailed to me for inclusion in the trackers for later versions.
3) Major objections at your peril.
This version is changed tracked, except for the tables 1 and 3, which are all new.
Enjoy.
-- "So much time, so little to do..." -- Garfield
participants (5)
-
Andre Merzky
-
Chris Kantarjiev
-
David Snelling
-
Linesch, Mark
-
Maguire_Tom@emc.com