Glossary terms for Thursday's call
HI, I've uploaded version 4 of the glossary - this version includes the changes for deployment and provisioning, as agreed at the last discussion. You'll find it at http://tinyurl.com/2mo6r3. For Thursday's call I propose to discuss the following terms, as time permits o State. We had discussed this, and Jay has an action to improve the current proposal. So far I haven't had a proposal from Jay, but we need to put this one to bed, so we'll have a brief discussion and if we don't have a better proposal at the meeting I'll go with what we have. There will be an opportunity to improve this or any term in the final review. o Resource, Grid component, and Service. We had definitions for Resource and Service in both the OGSA and the EGA glossaries, so we need to produce a consolidated definition. Grid component comes from the EGA glossary. I've condensed it from the original, but (hopefully) haven't changed its meaning. Rather than reproduce these terms here please take a look at the working/discussion document, which you'll find at http://tinyurl.com/23a6zd. These are the first four terms listed, and the text you'll find is a starting point for discussion. If you have comments and you're not going to make tomorrow's meeting, please pass them on to me; otherwise I'll follow up after the meeting with revised text for review. Thanks! - Jem Jem Treadwell Software Engineer HP Software 856.638.6021 office | 856.638.6190 fax | jem.treadwell@hp.com 6000 Irwin Road | Mount Laurel | NJ 08054 www.hp.com/go/software <http://www.hp.com/go/software>
Treadwell, Jem wrote:
I’ve uploaded version 4 of the glossary – this version includes the changes for deployment and provisioning, as agreed at the last discussion. You’ll find it at http://tinyurl.com/2mo6r3.
For Thursday’s call I propose to discuss the following terms, as time permits
o State. We had discussed this, and Jay has an action to improve the current proposal. So far I haven’t had a proposal from Jay, but we need to put this one to bed, so we’ll have a brief discussion and if we don’t have a better proposal at the meeting I’ll go with what we have. There will be an opportunity to improve this or any term in the final review.
o Resource, Grid component, and Service. We had definitions for Resource and Service in both the OGSA and the EGA glossaries, so we need to produce a consolidated definition. Grid component comes from the EGA glossary. I’ve condensed it from the original, but (hopefully) haven’t changed its meaning.
Rather than reproduce these terms here please take a look at the working/discussion document, which you’ll find at http://tinyurl.com/23a6zd. These are the first four terms listed, and the text you’ll find is a starting point for discussion. If you have comments and you’re not going to make tomorrow’s meeting, please pass them on to me; otherwise I’ll follow up after the meeting with revised text for review.
On the Service definition: I'm concerned that the proposed definition constrains a service to be part of a SOA (which to my mind is a multi-component architecture where the interfaces between the components are characterized by service interfaces, a term I define below) as opposed to just saying that this is typically the case. Strictly, a service is a reactive software entity that responds to requests sent by clients (either through receiving messages or by listening for the start of a conversation). A service is also defined by the fact that it exposes a particular method of accessing it using a defined set of messages and/or phrases in defined patterns; this is the Service Interface, and clients of the service only need to know the service interface in order to be able to use the service; the service interface might make statements about the internal state model of the service (in which case the service is a stateful service) but is not required to do so. On the Resource definition: Are resources always stateful? On the State definition: I think the defining feature of a state (as opposed to a configuration) is that a state is capable of changing over time, whereas an altered configuration can be said to lead to a different entity/component. (There is a separate question of whether the set of existing grid components in a grid is itself a state, or whether it only becomes one if you have registries of the components, and hence the component-set state of the grid is the state of the registries.) On the Grid Component definition: I'd like to note that grid components *must* have state, minimally to describe their situation in their lifecycle, though the state does not inherently need to be exposed to all users. Trawling through the other definitions, do we need to define Abstraction or DAG/Acyclic Digraph? I'd have thought that we could just use the standard Computer Science definitions of these. Also, I came up with a definition of a Grid (or perhaps it really defines a Grid Architecture?) a few weeks ago that might be useful/relevant: A (potentially) inter-organizational dynamic stateful SOA. Now, there is one problem with this definition in that it directly conflicts with the definition of an Enterprise Grid (I'm really suspicious of calling something a grid if it is entirely within a single management domain) but the above bit of pithy buzzwordisms does encompass a lot of what we're really about. For example, "inter-org" means that we want to be both secure and standards-based, "dynamic stateful" forces real consideration of management of the state (instead of just sweeping it under the carpet, which seems to be the more usual SOA approach), and I find it impossible to imagine a grid that does not meet the definition of a SOA. Donal.
Hi, Thanks to all those who joined today's call for the glossary segment - we had an excellent discussion that resulted in agreement on definitions for state, resource and service. The agreed-upon definitions (with some minor post-meeting wordsmithing) are below - please take a look, and let me know if you have any comments. I'll move them into the draft document if there are no objections by Monday - after that you can still comment at any time, and there will, of course, be a review period for the full document later. Thanks! - Jem - State: An entity's state is the combined values of its "interesting" attributes. Interesting attributes are those for which external observers may see changes over time. Examples include the position of a switch, the price of a stock, or the amount of memory allocated to a process. Since not all attributes may be available or interesting to all possible observers, different observers may have different views of the state of an entity at a given time. A change in state is an event. Resource: A resource is a physical or logical entity that supports use or operation of a computing application or environment. In a Grid context the term encompasses entities that provide a capability or capacity (e.g., servers, networks, disks, memory, applications, databases, IP addresses, and software licenses). Dynamic entities such as processes, print jobs, database query results and virtual organizations may also be represented and handled as resources. Service: A service in the most general sense is an entity, usually composed of one or more software components, that provides functionality in response to client requests. A service is often a part of a service-oriented architecture, and participates in realizing one or more capabilities. For example, an electronic bookstore application is a service, and its database component provides a database service to the bookstore. Thus high-level services may be decomposed into lower-level constituent services. In general, a service and all of its decomposable sub-services are considered to be components. Jem Treadwell Software Engineer HP Software 856.638.6021 office | 856.638.6190 fax | jem.treadwell@hp.com 6000 Irwin Road | Mount Laurel | NJ 08054 www.hp.com/go/software <http://www.hp.com/go/software> ________________________________ From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Treadwell, Jem Sent: Wednesday, April 11, 2007 11:50 AM To: ogsa-wg Subject: [ogsa-wg] Glossary terms for Thursday's call HI, I've uploaded version 4 of the glossary - this version includes the changes for deployment and provisioning, as agreed at the last discussion. You'll find it at http://tinyurl.com/2mo6r3. For Thursday's call I propose to discuss the following terms, as time permits o State. We had discussed this, and Jay has an action to improve the current proposal. So far I haven't had a proposal from Jay, but we need to put this one to bed, so we'll have a brief discussion and if we don't have a better proposal at the meeting I'll go with what we have. There will be an opportunity to improve this or any term in the final review. o Resource, Grid component, and Service. We had definitions for Resource and Service in both the OGSA and the EGA glossaries, so we need to produce a consolidated definition. Grid component comes from the EGA glossary. I've condensed it from the original, but (hopefully) haven't changed its meaning. Rather than reproduce these terms here please take a look at the working/discussion document, which you'll find at http://tinyurl.com/23a6zd. These are the first four terms listed, and the text you'll find is a starting point for discussion. If you have comments and you're not going to make tomorrow's meeting, please pass them on to me; otherwise I'll follow up after the meeting with revised text for review. Thanks! - Jem Jem Treadwell Software Engineer HP Software 856.638.6021 office | 856.638.6190 fax | jem.treadwell@hp.com 6000 Irwin Road | Mount Laurel | NJ 08054 www.hp.com/go/software <http://www.hp.com/go/software>
An observation State - The definition of state is interesting. I like the definition in UML - "A condition or situation during the life of an object [during] which it satisfies some condition, performs some do[sic] activity, or waits for some event." [The UML Ref Manual, 2nd ed by Rumbaugh, Jacobson and Booch]. It says to me that the attributes that define state are those that allow one to determine the whether some condition is satisfied, what activity is being undertaken or what event is being waited upon. Within the RM-WG we have split attributes into configuration attributes and state attributes. Configuration attributes to some degree define behavior, defining or constraining the set of allowed states, as well as the possible values of state attributes and allowed transitions between states. Clearly configuration attributes are "interesting", and thus according to the definition below they would be considered part of the state. I'm not sure that this is the case. Regards Paul ________________________________ From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Treadwell, Jem Sent: Thursday, April 12, 2007 11:06 AM To: ogsa-wg Subject: Re: [ogsa-wg] Glossary terms for Thursday's call Hi, Thanks to all those who joined today's call for the glossary segment - we had an excellent discussion that resulted in agreement on definitions for state, resource and service. The agreed-upon definitions (with some minor post-meeting wordsmithing) are below - please take a look, and let me know if you have any comments. I'll move them into the draft document if there are no objections by Monday - after that you can still comment at any time, and there will, of course, be a review period for the full document later. Thanks! - Jem - State: An entity's state is the combined values of its "interesting" attributes. Interesting attributes are those for which external observers may see changes over time. Examples include the position of a switch, the price of a stock, or the amount of memory allocated to a process. Since not all attributes may be available or interesting to all possible observers, different observers may have different views of the state of an entity at a given time. A change in state is an event. Resource: A resource is a physical or logical entity that supports use or operation of a computing application or environment. In a Grid context the term encompasses entities that provide a capability or capacity (e.g., servers, networks, disks, memory, applications, databases, IP addresses, and software licenses). Dynamic entities such as processes, print jobs, database query results and virtual organizations may also be represented and handled as resources. Service: A service in the most general sense is an entity, usually composed of one or more software components, that provides functionality in response to client requests. A service is often a part of a service-oriented architecture, and participates in realizing one or more capabilities. For example, an electronic bookstore application is a service, and its database component provides a database service to the bookstore. Thus high-level services may be decomposed into lower-level constituent services. In general, a service and all of its decomposable sub-services are considered to be components. Jem Treadwell Software Engineer HP Software 856.638.6021 office | 856.638.6190 fax | jem.treadwell@hp.com 6000 Irwin Road | Mount Laurel | NJ 08054 www.hp.com/go/software <http://www.hp.com/go/software> ________________________________ From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Treadwell, Jem Sent: Wednesday, April 11, 2007 11:50 AM To: ogsa-wg Subject: [ogsa-wg] Glossary terms for Thursday's call HI, I've uploaded version 4 of the glossary - this version includes the changes for deployment and provisioning, as agreed at the last discussion. You'll find it at http://tinyurl.com/2mo6r3. For Thursday's call I propose to discuss the following terms, as time permits o State. We had discussed this, and Jay has an action to improve the current proposal. So far I haven't had a proposal from Jay, but we need to put this one to bed, so we'll have a brief discussion and if we don't have a better proposal at the meeting I'll go with what we have. There will be an opportunity to improve this or any term in the final review. o Resource, Grid component, and Service. We had definitions for Resource and Service in both the OGSA and the EGA glossaries, so we need to produce a consolidated definition. Grid component comes from the EGA glossary. I've condensed it from the original, but (hopefully) haven't changed its meaning. Rather than reproduce these terms here please take a look at the working/discussion document, which you'll find at http://tinyurl.com/23a6zd. These are the first four terms listed, and the text you'll find is a starting point for discussion. If you have comments and you're not going to make tomorrow's meeting, please pass them on to me; otherwise I'll follow up after the meeting with revised text for review. Thanks! - Jem Jem Treadwell Software Engineer HP Software 856.638.6021 office | 856.638.6190 fax | jem.treadwell@hp.com 6000 Irwin Road | Mount Laurel | NJ 08054 www.hp.com/go/software <http://www.hp.com/go/software>
Strong, Paul wrote:
Within the RM-WG we have split attributes into configuration attributes and state attributes. Configuration attributes to some degree define behavior, defining or constraining the set of allowed states, as well as the possible values of state attributes and allowed transitions between states. Clearly configuration attributes are “interesting”, and thus according to the definition below they would be considered part of the state. I’m not sure that this is the case.
An argument that I made during the call (and which it might have been nice to have delved into in more detail if we'd had a few days instead of 15 minutes!) is that an altered configuration creates a different resource/stateful entity[*], but an altered state is something that is expected during the normal working lifetime of a resource and does not change the fundamental nature of that resource. That is, a change of config is qualitatively different to a change of state, even if both are (represented as) attributes. In general, there are loads of definitions of state (I've got a background which leads me to regard it as really a partial function whose domain is the cartesian product of time and names for "stateful" things) but they're just different ways of looking at the same thing. The good aspects of the current definition are that it is observable and changes in it are events, things which are not implicit in the standard CS definitions of the term and yet are very useful for grids. Donal. [* As you can tell, I've lost track of what kind of thing contains such attributes. I know *I* think of them as resources, but that doesn't make me right. :-) ]
-----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Friday, April 13, 2007 4:38 AM To: Strong, Paul Cc: ogsa-wg; rm-wg@ogf.org Subject: Re: [ogsa-wg] Glossary terms for Thursday's call
Strong, Paul wrote:
Within the RM-WG we have split attributes into configuration attributes and state attributes. Configuration attributes to some degree define behavior, defining or constraining the set of allowed states, as well as the possible values of state attributes and allowed transitions between states. Clearly configuration attributes are "interesting", and
according to the definition below they would be considered part of
Paul/Donal/All, Thanks for the comments, and sorry to be slow in responding - I'm not able to work on this quite as much these days :( Now that I've taken time to read Paul's comment and Donal's response a little more carefully, I think Donal makes an excellent point - I would expect that an entity would exist only after it has been configured. Its configuration attributes would *contribute* to its state, but would not be a part of it unless the details are associated with (*maybe* contained within) the entity, are visible to some external observer (possibly a debugger), and might change. I'm happy to add a little more explanation in the definition if anyone thinks it would be helpful. For example, at the end of Para 1 I could add: Configuration attributes typically affect an entity's initial state, but would not be considered to be part of the state unless they can be changed during the entity's lifetime, and thus affect its behavior. Other suggestions welcome! - Jem thus the
state. I'm not sure that this is the case.
An argument that I made during the call (and which it might have been nice to have delved into in more detail if we'd had a few days instead of 15 minutes!) is that an altered configuration creates a different resource/stateful entity[*], but an altered state is something that is expected during the normal working lifetime of a resource and does not change the fundamental nature of that resource. That is, a change of config is qualitatively different to a change of state, even if both are (represented as) attributes.
In general, there are loads of definitions of state (I've got a background which leads me to regard it as really a partial function whose domain is the cartesian product of time and names for "stateful" things) but they're just different ways of looking at the same thing. The good aspects of the current definition are that it is observable and changes in it are events, things which are not implicit in the standard CS definitions of the term and yet are very useful for grids.
Donal. [* As you can tell, I've lost track of what kind of thing contains such attributes. I know *I* think of them as resources, but that doesn't make me right. :-) ] -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Michael Behrens wrote:
Most insightful. Would the available attributes vary directly with the lifecycle state of the resource? Or would there simply be a way to categorize attributes and might this affect future resource specifications?
I don't know for sure, but when I raised the point originally I was thinking that although both "configuration" and "state" are state in the UML sense, in the "useful grid sense" they're different. Because of that, we should define them to mean what we want them to mean, and note in the model/glossary that both are specializations of the more general notion. This is an application of the Humpty Dumpty Maxim: “When I use a word,” Humpty Dumpty said, in a rather scornful tone, “it means just what I choose it to mean - neither more nor less.” -- _Alice Through the Looking Glass_, Lewis Carroll Donal.
On the other hand, perhaps the proper way to manage most configuration is to make it more runtime-configurable so it is just state! (Now I duck out before someone tries to develop a theory of configuration and partial configurators.) karl -- Karl Czajkowski karlcz@univa.com
I think the difference, as per previous email is that config parameters are externally set, whereas indicators of state are typically internally set. Clearly state changes can be externally triggered, but the attributes that indicate the state would typically not be directly manipulated by an external entity. This means that the whole run-time configurable debate goes away :o) Paul -----Original Message----- From: rm-wg-bounces@ogf.org [mailto:rm-wg-bounces@ogf.org] On Behalf Of Karl Czajkowski Sent: Tuesday, May 01, 2007 11:43 AM To: Donal K. Fellows Cc: Michael Behrens; ogsa-wg; rm-wg@ogf.org Subject: Re: [rm-wg] [ogsa-wg] Glossary terms for Thursday's call (statedefinition) On the other hand, perhaps the proper way to manage most configuration is to make it more runtime-configurable so it is just state! (Now I duck out before someone tries to develop a theory of configuration and partial configurators.) karl -- Karl Czajkowski karlcz@univa.com _______________________________________________ rm-wg mailing list rm-wg@ogf.org http://www.ogf.org/mailman/listinfo/rm-wg
Strong, Paul wrote:
I think the difference, as per previous email is that config parameters are externally set, whereas indicators of state are typically internally set. Clearly state changes can be externally triggered, but the attributes that indicate the state would typically not be directly manipulated by an external entity.
This means that the whole run-time configurable debate goes away :o)
I think that's one place I'm trying to head to. The other thing that I'd love to see is that anything which is runtime changeable state is also potentially capable of notifying interested parties when that state changes. I'm deliberately not defining what that exactly means since it varies with the particular nature of the grid, but thinking in terms of WS-Notification or WS-Eventing is reasonable. :-) Donal.
Hi, I'm mainly an appreciative lurker here, so apologies in advance if this comment fails to add anything useful to the discussion: In my experience (mostly telecom), we have sometimes used "Provisioned" to indicate the state in which an entity has been "configured for initial operation and awaiting activation (i.e., being put into active service)". "Configuration" is then the changes (if any) that are made to the entity between activation and "retirement" (pulled from service). (An entity may go through multiple activation/retirement cycles over its service lifetime, and the final configuration at a retirement might be the provisioned state at the next activation.) Cheers, BobN ________________________________ From: rm-wg-bounces@ogf.org [mailto:rm-wg-bounces@ogf.org] On Behalf Of Michael Behrens Sent: Monday, April 30, 2007 8:54 PM To: Treadwell, Jem Cc: rm-wg@ogf.org; ogsa-wg; Donal K. Fellows Subject: Re: [rm-wg] [ogsa-wg] Glossary terms for Thursday's call (statedefinition) Most insightful. Would the available attributes vary directly with the lifecycle state of the resource? Or would there simply be a way to categorize attributes and might this affect future resource specifications? Treadwell, Jem wrote: Paul/Donal/All, Thanks for the comments, and sorry to be slow in responding - I'm not able to work on this quite as much these days :( Now that I've taken time to read Paul's comment and Donal's response a little more carefully, I think Donal makes an excellent point - I would expect that an entity would exist only after it has been configured. Its configuration attributes would *contribute* to its state, but would not be a part of it unless the details are associated with (*maybe* contained within) the entity, are visible to some external observer (possibly a debugger), and might change. I'm happy to add a little more explanation in the definition if anyone thinks it would be helpful. For example, at the end of Para 1 I could add: Configuration attributes typically affect an entity's initial state, but would not be considered to be part of the state unless they can be changed during the entity's lifetime, and thus affect its behavior. Other suggestions welcome! - Jem -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Friday, April 13, 2007 4:38 AM To: Strong, Paul Cc: ogsa-wg; rm-wg@ogf.org Subject: Re: [ogsa-wg] Glossary terms for Thursday's call Strong, Paul wrote: Within the RM-WG we have split attributes into configuration attributes and state attributes. Configuration attributes to some degree define behavior, defining or constraining the set of allowed states, as well as the possible values of state attributes and allowed transitions between states. Clearly configuration attributes are "interesting", and thus according to the definition below they would be considered part of the state. I'm not sure that this is the case. An argument that I made during the call (and which it might have been nice to have delved into in more detail if we'd had a few days instead of 15 minutes!) is that an altered configuration creates a different resource/stateful entity[*], but an altered state is something that is expected during the normal working lifetime of a resource and does not change the fundamental nature of that resource. That is, a change of config is qualitatively different to a change of state, even if both are (represented as) attributes. In general, there are loads of definitions of state (I've got a background which leads me to regard it as really a partial function whose domain is the cartesian product of time and names for "stateful" things) but they're just different ways of looking at the same thing. The good aspects of the current definition are that it is observable and changes in it are events, things which are not implicit in the standard CS definitions of the term and yet are very useful for grids. Donal. [* As you can tell, I've lost track of what kind of thing contains such attributes. I know *I* think of them as resources, but that doesn't make me right. :-) ] -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) (703) 714-0442 (land)
I think we need to modify Jem's definition slightly. A component has to be manageable before it can be configured. Thus it exists before it is configured :o) This is the goal of the Ref Model life cycle where we have the notion of - Extant - the component is manageable, i.e. it can be configured Configured - the component has been configured sufficently to allow it to be started Active - the component is serving the purpose for which it was intended, i.e. responding to requests, doing a calculation etc. I find a useful way of thinking about this is that state is really reflected by attributes that cannot typically be set externally. Whilst configuration parameters may be. Clearly state may be changed by applying verb externally to a managed component, such as start or stop, but this is not the same. Paul ________________________________ From: Michael Behrens [mailto:michael.behrens@r2ad.com] Sent: Tuesday, May 01, 2007 1:54 AM To: Treadwell, Jem Cc: Donal K. Fellows; Strong, Paul; ogsa-wg; rm-wg@ogf.org Subject: Re: [ogsa-wg] Glossary terms for Thursday's call (state definition) Most insightful. Would the available attributes vary directly with the lifecycle state of the resource? Or would there simply be a way to categorize attributes and might this affect future resource specifications? Treadwell, Jem wrote: Paul/Donal/All, Thanks for the comments, and sorry to be slow in responding - I'm not able to work on this quite as much these days :( Now that I've taken time to read Paul's comment and Donal's response a little more carefully, I think Donal makes an excellent point - I would expect that an entity would exist only after it has been configured. Its configuration attributes would *contribute* to its state, but would not be a part of it unless the details are associated with (*maybe* contained within) the entity, are visible to some external observer (possibly a debugger), and might change. I'm happy to add a little more explanation in the definition if anyone thinks it would be helpful. For example, at the end of Para 1 I could add: Configuration attributes typically affect an entity's initial state, but would not be considered to be part of the state unless they can be changed during the entity's lifetime, and thus affect its behavior. Other suggestions welcome! - Jem -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: Friday, April 13, 2007 4:38 AM To: Strong, Paul Cc: ogsa-wg; rm-wg@ogf.org Subject: Re: [ogsa-wg] Glossary terms for Thursday's call Strong, Paul wrote: Within the RM-WG we have split attributes into configuration attributes and state attributes. Configuration attributes to some degree define behavior, defining or constraining the set of allowed states, as well as the possible values of state attributes and allowed transitions between states. Clearly configuration attributes are "interesting", and thus according to the definition below they would be considered part of the state. I'm not sure that this is the case. An argument that I made during the call (and which it might have been nice to have delved into in more detail if we'd had a few days instead of 15 minutes!) is that an altered configuration creates a different resource/stateful entity[*], but an altered state is something that is expected during the normal working lifetime of a resource and does not change the fundamental nature of that resource. That is, a change of config is qualitatively different to a change of state, even if both are (represented as) attributes. In general, there are loads of definitions of state (I've got a background which leads me to regard it as really a partial function whose domain is the cartesian product of time and names for "stateful" things) but they're just different ways of looking at the same thing. The good aspects of the current definition are that it is observable and changes in it are events, things which are not implicit in the standard CS definitions of the term and yet are very useful for grids. Donal. [* As you can tell, I've lost track of what kind of thing contains such attributes. I know *I* think of them as resources, but that doesn't make me right. :-) ] -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) (703) 714-0442 (land)
participants (6)
-
Donal K. Fellows -
Karl Czajkowski -
Michael Behrens -
Natale, Bob -
Strong, Paul -
Treadwell, Jem