December 2005 - ogsa-wg - lists.ogf.org

Teleconference minutes - 12 December 2005
by Andreas Savva 13 Dec '05

13 Dec '05

Minutes attached. Also https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051212/en/1 -- Andreas Savva OGSA Teleconference - 12 December 2005 ====================================== * Participants Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (EMC) Takuya Mori (NEC) Darren Pulsipher (Xango) Andreas Savva (Fujitsu) Jem Treadwell (HP) Peter Ziu (Northrop Grumman) Minutes: Andreas Savva * Minutes of Dec 5 and 7 approved with no changes. * Jan 2006 F2F update Hiro posted draft agenda and survey. There were 12 replies to the survey so far. Unfortunately some did not have a name or email. - Fellow WGs should send Hiro their detailed agenda - WS-Management session: Only if the situation clears up with respect to MS participation * GGF16 Update - Proposal for 2 sessions: - Town hall: need to prepare for this and attract the right people. - How popular is this expected to be? Talk with Andrew G who proposed the idea. - One idea is to split the session in two parts: outreach followed by town hall - Technical session: Last GGF this was a joint session with CDDLM. CDDLM is scheduling a joint session with EMS as part of their agenda this time so a different topic should be chosen. - Proposal for an Information Model joint session---how it relates to other activities such as BES, ByteIO and JSDL and so on. - Fred will bring a proposed agenda to the Jan F2F * GGF 16 F2F update - Revisit the agenda discussion for this meeting during the Jan F2F. * Basic security profile status review Takuya explained the current status. The Secure Channel was split into Core and Secure Channel a couple of weeks ago. But the relationship, if any, of these two specifications is still unclear. Alternatives were discussed and Takuya took on the assignment to clarify whether there is a need for a Core profile---if its contents are all MLS (message level security) specific perhaps it should be included within the (scheduled) MLS profile instead. Takuya is discussing this issue with Frank and he will send out a proposal to the list. * OGSA 1.5 review ** Glossary Reviewed a small number of definitions: - Resource: Fred to look at revising this definition (take out 'managed' aspect and move to 'manageable resource'). Send to Jem and Andreas first. - Component: reviewed and revised Michael B's proposal. - Task: Only used in a technical sense in 3.8.4.1. Andreas to look into revising that text (remove task) and Jem will then remove from Glossary. ** OGSA 1.5 - Recap of status: missing text for parts of Infrastructure and Data Integrity; otherwise only minor revisions. - Reviewed minor changes to clear up 'use case' and 'scenario' usage. - Andreas is thinking of updating Figure 5 in EMS. He will talk with Andrew. - Andreas to add the ByteIO reference. * Other business - Note that 'Profile Definition' final call is due this week. - IPsphere presentation update - Joint call last week went very well. Andrew gave a very good OGSA introduction based on the MDC slides. - Identified a lot of similarities with IPsphere work. They are also looking at defining a set of high level services. They will review OGSA material. - No actions or follow up call scheduled at this moment. Franco T is continuing as liaison and he will contact OGSA-WG is follow up meetings are neeeded. - Hiro has received permission and he will upload their slides to gridforge. * Next call - Hiro and Tom are unavailable Wednesday. Andreas will send out an agenda and chair the call instead. - Expected agenda: EMS composite roadmap and deployment scenarios breakdown.

1 0

Teleconference minutes - 5 December 2005
by Andreas Savva 12 Dec '05

12 Dec '05

Minutes attached. Also https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051205/en/1 Thanks to all who attended. -- Andreas Savva OGSA Teleconference - 5 December 2005 ===================================== * Participants Hiro Kishimoto (Fujitsu) Mark Morgan (UVa) Takuya Mori (NEC) Andreas Savva (Fujitsu) Jem Treadwell (HP) Minutes: Andreas Savva * November 30 minutes approved with no changes * Jan 2006 F2F update - Reviewed Hiro's revised agenda - Added a 1 hour slot for OGSA 1.5 on Tuesday - Hiro to do attendance survey * GGF16 update - Hiro to send out request for topic ideas to the list for 2 sessions at GGF16 and Friday F2F. * Review of BSP - Secure channel - Review of tracker artifacts based on draft 12 uploaded by Takuya - 1697: Fixed; Closed - 1698: as agreed split off some of the topics to a separate document. Modified Abstract, Introduction, and removed Claims relating to tokens and key information exchange. - Abstract: also delete saml token profile from first paragraph - Agreed to change name of the 'OGSA BSP' to something like 'OGSA BSP - Core' - Proposed that Secure Channel and WSRF profile composition is optional while composition with 'OGSA BSP' is mandatory - Discussed at length with no consensus reached. In particular it is unclear whether the functionality in the Core profile is required by all using the WSRF BP, or not. Also whether there is a real dependency between the Core and the Secure Channel. - Takuya will review and try to clarify the relationship between the Core profile and the Secure Channel further: in particular if there is a dependency between the two (core must be used with secure channel) or a looser relationship (may be combined). And whether there is any change in the relationship with the WSRF BP. E.g., if only the core may expose the claim defined by the WSRF BP should the text currently in the WSRF BP be modified? - Allow 1 week to settle this issue; rather than another document review discuss this issue on the list or on a call with Tom M and Frank S. - Normative and Non-normative references - Should these be separated and if so, should they be split by type of usage? (There are some inconsistent examples.) - Agreed on the call that if they are separated then they should be separated by usage. - Andreas will follow up with the GGF Editor. - Namespace table - The table should be re-checked since some of remaining entries seem unlikely to be used in the document. E.g., soap. - Appendix A. delete obsolete references (the first 2) - Appendix C needs update * OGSA 1.5 review - Andreas gave a quick overview of status - Waiting for 'Data Integrity' section from Andrew G. - Waiting for 'Infrastructure : Representing State' proposal from Jay U. - Waiting for Naming issue to be settled to fix a sub-section in Infrastructure. - Waiting for BES and Naming policy to be fixed to review the EMS revision - Fixing some terminology issues (use case and scenario, acronyms, etc) - Reviewed the glossary draft: new entries for acronyms. - Some concerns with drawing technical references from Wikipedia. The main issue being that the information may change at a later point so a reference might no longer look the way it was when cited. - In principle try to avoid such references. It is fine to put an informative link but there should be a more formal reference to a more stable source, e.g., an RFC.

4 5

Report on UK Interop Meeting
by Mark Morgan 12 Dec '05

12 Dec '05

Andrew and I thought that a number of people might be interested in the status of the UK BES interoperability meeting. As of 10:30 AM UK time, we have two separate BES implementations. One written by Uva using WSRF.NET, the other written by Imperial College using GridSAM. The interoperability chart for the meeting is this: Operation Uva Client/ICL BES ICL Client/Uva BES ------------------------------------------------------------------- CreateActivity Working Working GetActivityStatus Working Working StartAccepting Working Working StopAccepting Working Working GetJSDLForActivi. Not Tested Not Tested IsAccepting Not Tested Not Tested -Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.mark-morgan.net mark(a)mark-morgan.net

2 1

Re: [ogsa-rss-wg] RE: [ogsa-wg] Teleconference minutes - 2 November 2005
by Donal K. Fellows 12 Dec '05

12 Dec '05

Donal K. Fellows wrote: > First, at this year's London F2F people began talking about the need to > do scheduling over all services, not just execution services. I.e. we > may need to schedule access to data services and network services. It > would be desirable to have a framework generic enough to handle all > sorts of resources (as long as they in turn provide the necessary > information). Has anyone considered this w.r.t. RSS? It's not being actively considered as such, but it is certainly at the back of my mind and I'm trying to not take any decisions that would close off such use. > Second, there are lots of ways to implement scheduling. Would it be > possible just to specify the interfaces and allow implementations of the > services to use whichever algorithms they want? E.g. in the data > architecture we say almost nothing about the functioning of a data > federation service, because we can abstract from most of the inner > workings. Do we clearly understood what the output of the RSS service > should be? We're most certainly not saying much about the innards of the services! That would be a mistake as it is clear from the pre-existing work (done by the GSA-RG) that there are many approaches in this space. From my own experience, I suspect that it is likely that there will be many different "brokering" systems about, many of which are specialized to dealing with a particular domain. At the moment, I thinking about the abstract output of the RSS services as ordered sets of candidate execution plans, probably encapsulated within WS-Agreement Templates. The ground elements of the plans (or at least those parts that relate to computational activity, of course) will likely be JSDL documents suitable for submission to BES containers. When it comes to data stuff, I don't understand the requirements well enough to say much, but I believe that the suggested outer structure (ordered set of agreement templates) will extend to that sort of thing nicely; it is just the leaves of such a tree that I don't understand. > Third, you mention the idea of passing in a ranking function parameter. > This sounds similar to a question I raised recently on this list about > selecting data sources, in which I suggested passing in a policy > argument. Admittedly I was making that suggestion in the particular > context of passing a policy argument to a reference renewing service, > but the two cases do seem sufficiently similar to merit a comparison. > The replies I received then expressed a strong preference for letting > the selection be done by the client rather than attempting to > parameterise a service. I think it's worth drilling down on this issue, > and this is what I attempt to do for the rest of this message. The problem with the other way (caller gets all offers and then chooses) is that it doesn't scale well when the number of potential candidates goes up. By supplying a ranking function to the generator side and using a service concretization based on something like WS-Enumeration, you can come up with protocols that take reasonably high quality decisions with very little network traffic or local computation. Note that I'm looking for "good enough" decisions and not optimal ones. I think that optimality is something of a chimera, and that you can get within a few percent of it for far less effort. This will produce an overall system that works very well cheaply most of the time, and in those cases where the costs are so massive that even a small difference is expensive it will be possible to use a non-standard service that tries harder for optimality (while probably charging extra for the privilege of course). [...] > If we have parameterisation, then the question arises of how expressive > a language we need to specify the parameterisation. Do we need a > general-purpose programming language (e.g. Python script) or will the > draft WS-Agreement language be sufficient? As far as I can see from reading the version that went out to public comment, WS-Agreement currently just punts on this issue. I'm hoping that it will be possible to avoid putting a general programming language expression though; it's remarkably hard to secure such things, and mandating one language over another (necessary for interoperability) would trigger a lot of arguments. This is an area that's definitely going to need more work. (If we can't specify something XMLish, we need to choose a suitable language based on capabilities and safety properties.) > The replies I received suggested both that the parameterisation would > require a general programming language and that the client may have > privileged knowledge that it does not wish to share, and therefore it > would be better to leave decisions to the client. I'm rather sceptical > of the first point but it would be good to examine real systems to > determine what is really needed. I think that as long as you are just ordering and not selecting, you have far less of a problem. The final decision rests with the client still; all they're doing is exporting the first stage of their selection process (the initial sort) to the server side. But you can only make that efficient if you use something like WS-Enumeration. The other advantage of doing this is that you end up with the equivalent of a distributed merge sort when you start doing tricky things with delegated candidate set generation. > There are clearly many possible answers in this space - which brings us > back to Ian's list of schedulers. One question might be whether we can > identify an interface, or a small number of interfaces, that generalises > a significant number of practical use cases. I thought that (modulo that RSS isn't working on reservation; out of scope according to the current charter) was what we were working on. :-) Donal.

2 1

Proposed agenda for Dec. 12th call
by Hiro Kishimoto 12 Dec '05

12 Dec '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Dec. 12th Monday from 4pm to 6pm (CST). The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 1212 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (Dec. 5 & 7) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051205/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051207/en/1 Agenda bashing 2) Jan. F2F and GGF16 update (30 min) Hiro upload revised schedule and launch survey for Jan. F2F. Please have a look and answer this survey. https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… http://www.zoomerang.com/survey.zgi?p=WEB224URW95UZU Hiro sent out session topic idea request to the list. > Since deadline for GGF16 session request is 14 December (Wednesday), > I would solicit session topics for; > (1) Outreach session at GGF16 > e.g. OGSA Town hall meeting > (2) Technical session at GGF16 > e.g. information model CIM profile guideline discussion > (3) Technical sessions at Back-to-back OGSA-WG F2F meeting on Friday. > e.g. EMS architecture, security architecture, ... 3) Basic Security Profile open issue discussion (30 min) > - Proposed that Secure Channel and WSRF profile composition is > optional while composition with 'OGSA BSP' is mandatory > - Discussed at length with no consensus reached. In particular > it is unclear whether the functionality in the Core profile is > required by all using the WSRF BP, or not. Also whether there > is a real dependency between the Core and the Secure Channel. > - Takuya will review and try to clarify the relationship between > the Core profile and the Secure Channel further: in particular > if there is a dependency between the two (core must be used > with secure channel) or a looser relationship (may be > combined). And whether there is any change in the relationship > with the WSRF BP. E.g., if only the core may expose the claim > defined by the WSRF BP should the text currently in the WSRF > BP be modified? > - Allow 1 week to settle this issue; rather than another > document review discuss this issue on the list or on a call > with Tom M and Frank S. 4) OGSA Arch and Glossary 1.5 (30 min) 5) Wrap up (10 min) AOB <NEXT CALL> Dec. 14 (Wed) EMS architecture Dec. 19 (Mon) OGSA-AuthZ joint call Naming requirement discussion Jan F2F preparation Dec. 21 (Wed) EMS Arch CDDLM/ACS/GRAAP joint call ** This is the last call before holiday season. ** Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 1

Survey for OGSA-WG F2F meeting in January 2006
by Hiro Kishimoto 12 Dec '05

12 Dec '05

Hi all, and sorry for the cross-posting. As you already know, OGSA-WG and fellow WGs are planning to have F2F meeting in January 2006. The meeting will be held in the week of January 16 from Monday morning to Friday noon at Fujitsu campus in Sunnyvale (SF Bay Area). Please let us know your plan for attendance by answering the following on-line survey. Deadline is EoB December 21st. http://www.zoomerang.com/survey.zgi?p=WEB224URW95UZU Session owners: Please provide detailed session agenda, I will incorporate your in the meeting schedule. The latest proposed agenda for January OGSA-WG and the fellow WGs F2F meeting is uploaded to the GridForge. https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… Thanks, -- Hiro Kishimoto

1 0

RE: [ogsa-wg] Teleconference minutes - 2 November 2005
by Dave Berry 11 Dec '05

11 Dec '05

Donal, I see from the RSS description on GridForge that RSS will consist of a Candidate Set Generator, which I assume could be loosely described as a "matching" service, and an Execution Planning Service, which I assume could loosely be described at a "scheduling service"). Come to think of it, I guess the combination of the two could be loosely described as a "broking service". A couple of questions come to mind. First, at this year's London F2F people began talking about the need to do scheduling over all services, not just execution services. I.e. we may need to schedule access to data services and network services. It would be desirable to have a framework generic enough to handle all sorts of resources (as long as they in turn provide the necessary information). Has anyone considered this w.r.t. RSS? Second, there are lots of ways to implement scheduling. Would it be possible just to specify the interfaces and allow implementations of the services to use whichever algorithms they want? E.g. in the data architecture we say almost nothing about the functioning of a data federation service, because we can abstract from most of the inner workings. Do we clearly understood what the output of the RSS service should be? Third, you mention the idea of passing in a ranking function parameter. This sounds similar to a question I raised recently on this list about selecting data sources, in which I suggested passing in a policy argument. Admittedly I was making that suggestion in the particular context of passing a policy argument to a reference renewing service, but the two cases do seem sufficiently similar to merit a comparison. The replies I received then expressed a strong preference for letting the selection be done by the client rather than attempting to parameterise a service. I think it's worth drilling down on this issue, and this is what I attempt to do for the rest of this message. At a sufficiently high level, we are attempting to do something simple. We have two inputs: a list of activities and a list of resources, and one output: a mapping of activities to resources. In the simplest case, we are selecting one resource (e.g. the replica to read data from or the protocol/source from which to transfer the data), and this may be so simple that we treat it differently (e.g. always in client code instead of a separate service). More complicated cases might produce a set of pairs, or a more complicated conditional mapping. In each case we could either (i) move the data to the client and perform the selection in client code (ii) pass the algorithm as a parameter to another service (iii) have a separate service that incorporates some aspects of the algorithm while allowing some parameterisation by policy. One factor that influences this choice might be who has the access to the necessary information. If the client has privileged information that should not be made public, then the choice might have to be made by the client; or the framework should encrypt the policy parameter and provide a trust relationship with the selection service. Conversely, the client may want to see only an abstraction of the detailed selection process. If we have parameterisation, then the question arises of how expressive a language we need to specify the parameterisation. Do we need a general-purpose programming language (e.g. Python script) or will the draft WS-Agreement language be sufficient? The replies I received suggested both that the parameterisation would require a general programming language and that the client may have privileged knowledge that it does not wish to share, and therefore it would be better to leave decisions to the client. I'm rather sceptical of the first point but it would be good to examine real systems to determine what is really needed. There are clearly many possible answers in this space - which brings us back to Ian's list of schedulers. One question might be whether we can identify an interface, or a small number of interfaces, that generalises a significant number of practical use cases. Best wishes, Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: 09 December 2005 09:37 To: 'ogsa-wg' Cc: ogsa-rss-wg(a)ggf.org Subject: Re: [ogsa-wg] Teleconference minutes - 2 November 2005 Steven Newhouse wrote: > A selector interface is being defined as part of the RSS activities > (https://forge.gridforum.org/projects/ogsa-rss-wg/) . They may have a > comment to make on the nature of the interface they are considering - > and how it could/could not encompass these services. I (as OGSA-RSS co-chair) welcome any input people have over possible strategies. At the moment, I'm thinking in terms of ordered sets where the caller supplies a ranking function[*] (or input to such a function). That gives plenty of flexibility and power. I'd love to have input from other people as to what sorts of things ought to go in the ranking function parameter; we could leave it unspecified (easy for the RSS WG!) but that's not good for working towards an interoperable solution so I'd like to seed the space with at least a minimal level of things that must be supported. Donal Fellows. [* Experience with Condor indicates that a "general acceptability" filter is also useful, but a first hack at that is a straight resource satisfaction check which ought to be performed anyway. ]

2 1

Teleconference minutes - 2 November 2005
by Andreas Savva 09 Dec '05

09 Dec '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051102/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 2 November 2005 ===================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Ellen Stokes (IBM) Chris Smith (Platform) Andreas Savva (Fujitsu) Steven Newhouse (OMII) Mark Morgan (UVa) Steve McGough (Imperial) Tom Maguire (EMC) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Dave Berry (NeSC) Michael Behrens (R2AD, LLC) Minutes: Andreas Savva * October 26 minutes approved with no changes * Information Model discussion - Postponed for next Wednesday - Action: Andrew to identify the attributes needed for BES container * EMS Sequence review - Reviewed sequence diagram and text sent to the list http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00003.html The diagram has not changed since the last review. There is additional text explaining the steps. - An open issue is the meaning of the 'abstract JSDL document'. - In the simplest case a document that does not specify a particular resource (host) for execution. - A more abstract case is that of specifyin only an application name and data (input, output) and leaving the rest to the system. - Taking the OS as an example, if the OS element is defined then only that specific OS can be used. If left undefined then any OS can be used. There is no in between choice with JSDL 1.0. The expectation is that JSDL should be combined with some other language to provide more flexible descriptions. - (WS-Agreement is one option but the assumption is that it is not used in this sequence. ) - Other existing work on preferences or selection policy? - EGEE uses Condor classads (with EGEE extensions) - Globus (no, since no there is no scheduler) - Can the Policy document may be empty? Then would just get whichever resource the EPS considers good enough. - Job management is out of scope of this scenario - How about job termination? It was discussed last time and is out of scope at this stage. - But it is a good idea to add the simplest case of 'control' returning to JM at the end of the job. - Agreed that this should be a separate sequence diagram. * Naming discussion - There was substantial confusion with the statements made at the last F2F. - Confirmed that the gist of the statement was: "In OGSA pointers are EPRs that may or may not be WS-Names." - The additional question is whether individuals WGs, because of the service specifications they are defining, can choose to require WS-Names (their reasons for doing so may vary). - Why does a service require EPR comparison? Does it fall in the category of "Nice but..." - One example is to distinguish EPRs for identity purposes. - And one common usage may be to enable additional functionality for monitoring, etc. - The expectation is that even if some OGSA services mint WS-Names and other OGSA services deal with them, those other OGSA services may also have to tolerate vanilla EPRs because there may be non-OGSA services in the system. - Does the requirement for WS-Names have to be part of the interface signature or is it more of a compliance statement that should be in a profile instead? - Is it an optimization? Can there be implemenations that functionally work without this feature, even if sub-optimally? So to make this feature mandatory becomes an overstatement. - It is also putting the onus on the client to manage the identities vs requiring the service to provide an operation. - Filesystem traversal as one(another) case where such an optimization (WS-Name) is useful. - The logging use case mentioned earlier is a commonly cited one. But in Jay's experience the identifiers have to be explicitly designed for the specific system and do not generalize. - Also the 'unique-in-space-and-time' statement is another point of disagreement. - To guarantee uniqueness there are two approaches: 1) arbitrator; or 2) agreed upon algorithm (with some unique input) used by everyone. - Agreed that something closer to (2) is expected but it is more of a best-effort. So the space-time guarantee is not expected to hold literally. - Noone on the call doubts the usefulness of WS-Names in helping build quality implementations. The disagreement is whether they must be mandated in the interface signatures of basic specs. - The open issue is what is the statement OGSA should make to the fellow WGs. Is this issue something that can be left to each individual WG or should it be tackled by the Architecture (so within OGSA-WG). - Hiro proposed to write up a document defining the problem, what are the requirements and proposed approach; and circulate to interested parties. Continue discussion on the list and possibly re-review next week with Ian Foster and Frank Siebenlist. - Tom volunteered to start a draft * UML Tool discussion - postponed

5 4

Re: [ogsa-naming-wg] One more attempt at date/time
by Frank Siebenlist 08 Dec '05

08 Dec '05

Has the call-in information be posted yet? -Frank. Andrew Grimshaw wrote: > > That’s 10 AM eastern … sorry for the mistake. > > ------------------------------------------------------------------------ > > *From:* owner-ogsa-naming-wg(a)ggf.org > [mailto:owner-ogsa-naming-wg@ggf.org] *On Behalf Of *Andrew Grimshaw > *Sent:* Sunday, December 04, 2005 4:49 PM > *To:* 'Andrew Grimshaw'; ogsa-naming-wg(a)ggf.org > *Subject:* RE: [ogsa-naming-wg] One more attempt at date/time > > All, > > The votes are in: December 9^th , 9AM eastern. > > Now all I have to do is get a call in number. > > Andrew > > ------------------------------------------------------------------------ > > *From:* owner-ogsa-naming-wg(a)ggf.org > [mailto:owner-ogsa-naming-wg@ggf.org] *On Behalf Of *Andrew Grimshaw > *Sent:* Wednesday, November 30, 2005 4:52 PM > *To:* ogsa-naming-wg(a)ggf.org > *Subject:* [ogsa-naming-wg] One more attempt at date/time > > All, > > Several people who have a strong interest in the topic could not make > one or the other of the date/times. I’d really like to get the folks > on the call who really care. > > So, one more attempt to find date/times (all dates/times US Eastern): > > December 7: 10 AM > > December 8: 10 AM (bumps BES call) > > December 9: 10 AM > > Please let me know. > > Andrew Grimshaw > > Professor of Computer Science > > University of Virginia > > 434-982-2204 > > grimshaw(a)cs.virginia.edu > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

2 1

OGSA Overview presentation and MDC delivery ...
by Subramaniam, Ravi 08 Dec '05

08 Dec '05

Hi, I have uploaded the overview to /projects/ogsa-wg/document/OGSA_Introduction_-_High_Level/en/1 I think we need to keep this updated to be the representative presentation. We need to have a review item every two months to make sure that the presentation is up to date. There are some edits that need to be done to make this generic. I have also update the MDC draft to the final version. BTW, the presentation went well. There were many questions though many were related to how we will be using the DMTF standards like CIM, WBEM and how comfortable we are with being public about our commitment to them. There were also clarifying questions on the OGSA process and architecture. Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: Wednesday, December 07, 2005 5:06 PM To: Ogsa-Wg Cc: Mark Morgan; Franco Travostino; Subramaniam, Ravi Subject: [ogsa-wg] IPsphere and OGSA-WG joint call (Dec. 8th) Hi all, IPsphere and OGSA-WG will have a first joint call tomorrow. (http://www.ipsphereforum.org/home) Franco Travostino, GGF Infrastructure Area Director, is arranging this joint call. I encourage you to call in. Data: Thu Dec 8th Time: 5-7pm EST dial-in number: +1-919-997-8152 passcode: 248-7708 OGSA-WG attendees (planned at Wednesday OGSA-WG call): - Andrew Grimshaw (UVa, Architecture Area Director) - Hiro Kishimoto (Fujitsu, co-chair) - Michael Behrens (R2AD LLC) - Mark Morgan (UVa) - Jem Treadwell (HP) Presentation material: I am now asking Ravi to send the final version of OGSA overview slide deck for Management Developer Conference 2005 this Tuesday. I will send it to IPsphere folks before the call. You can find a working draft at https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-high-level/en /6 Agenda: IPsphere folks will provide meeting agenda. AFAIK, the following items may be included. 1. Introduce the IPSphere and the problem that it is trying to solve (from a technical perspective). Maybe sent some material 2. A presentation of the OGSA 3. The current status of the OGSA 4. How does the OGSA address identity federation, security and discovery. 5. Discuss the whether it makes sense for the IPSphere Forum to building on top of the OGSA. 6. Roadmap of the OGSA 7. Conclusion. From OGSA-WG meeting minutes (Dec. 7th) > * IPsphere OGSA presentation > > - Planning an initial call tomorrow. Looking for volunteers to do > the presentation. > - This is fairly short notice. The call was arranged this week. > - Andrew G and Mark M volunteered to do the presentation using the > "OGSA Introduction" slide deck prepared for MDC. > - Hiro has asked Ravi to send back the last version of the MDC > slides; use the one on gridforge otherwise. > - A number of other people are also planning to call in: Hiro, > Michael, Jem. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051207/e n/1 -- Hiro Kishimoto

2 1