- ogsa-wg - lists.ogf.org

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Carl Kesselman 14 Mar '06

14 Mar '06

Hi, While I have no wish to engage in the "what is a Grid" argument, there are some elements of your base use case that I would be concerned about. Specifically, the assumption that the submission in into a "local cluster" on which there is an existing account may lead one to a solution that may not generalize to the solution to the case of submission across autonomous policy domains. I would also argue that ignoring issues of fault tolerance from the beginning is also problematic. One must at least design operations that are restartable (for example at most once submission semantics). I would finally suggest that while examining existing job schedule systems is a good thing to do, we should also examine existing remote submission systems (dare I say Grid systems). The basic HPC use case is one in which there is a significant amount implementation and usage experience. Thanks, Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Monday, March 13, 2006 2:42 PM To: Ian Foster; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; Ian, you are correct that I view job submission to a cluster as being one of the simplest, and hence most basic, HPC use cases to start with. Or, to be slightly more general, I view job submission to a "black box" that can run jobs - be it a cluster or an SMP or an SGI NUMA machine or what-have-you - as being the simplest and hence most basic HPC use case to start with. The key distinction for me is that the internals of the "box" are for the most part not visible to the client, at least as far as submitting and running compute jobs is concerned. There may well be a separate interface for dealing with things like system management, but I want to explicitly separate those things out in order to allow for use of "boxes" that might be managed by proprietary means or by means obeying standards that a particular job submission client is unfamiliar with. I think the use case that Ravi Subramaniam posted to this mailing list back on 2/17 is a good one to start a discussion around. However, I'd like to present it from a different point-of-view than he did. The manner in which the use case is currently presented emphasizes all the capabilities and services needed to handle the fully general case of submitting a batch job to a computing utility/service. That's a great way of producing a taxonomy against which any given system or design can be compared to see what it has to offer. I would argue that the next step is to ask what's the simplest subset that represents a useful system/design and how should one categorize the various capabilities and services he has identified so as to arrive at meaningful components that can be selectively used to obtain progressively more capable systems. Another useful exercise to do is to examine existing job scheduling systems in order to understand what they provide. Since in the real world we will have to deal with the legacy of existing systems it will be important to understand how they relate to the use cases we explore. In the same vein, it will be important to take into account and understand other existing infrastructures that people use that are related to HPC use cases. I'm thinking of things like security infrastructures, directory services, and so forth. From the point-of-view of managing complexity and reducing total-cost-of-ownership, it will be important to understand the extent to which existing infrastructure and services can be reused rather than reinvented. To kick off a discussion around the topic of a minimalist HPC use case, I present a straw man description of such below and then present a first attempt at categorizing various areas of extension. The categorization of extension areas is not meant to be complete or even all that carefully thought-out as far as componentization boundaries are concerned; it is merely meant to be a first contribution to get the discussion going. A basic HPC use case: Compute cluster embedded within an organization. * This is your basic batch job scheduling scenario. Only a very basic state transition diagram is visible to the client, with the following states for a job: queued, running, finished. Additional states -- and associated state transition request operations and functionality -- are not supported. Examples of additional states and associated functionality include suspension of jobs and migration of jobs. * Only "standard" resources can be described, for example: number of cpus/nodes needed, memory requirements, disk requirements, etc. (think resources that are describable by JSDL). * Once a job has been submitted it can be cancelled, but its resource requests can't be modified. * A distributed file system is accessible from client desktop machines and client file servers, as well as compute nodes of the compute cluster. This implies that no data staging is required, that programs can be (for the most part) executed from existing file system locations, and that no program "provisioning" is required (since you can execute them from wherever they are already installed). Thus in this use case all data transfer and program installation operations are the responsibility of the user. * Users already have accounts within the existing security infrastructure (e.g. Kerberos). They would like to use these and not have to create/manage additional authentication/authorization credentials (at least at the level that is visible to them). * The job scheduling service resides at a well-known network name and it is aware of the compute cluster and its resources by "private" means (e.g. it runs on the head node of the cluster and employs private means to monitor and control the resources of the cluster). This implies that there is no need for any sort of directory services for finding the compute cluster or the resources it represents other than basic DNS. * Compute cluster system management is opaque to users and is the concern of the compute cluster's owners. This implies that system management is not part of the compute cluster's public job scheduling interface. This also implies that there is no need for a logging interface to the service. I assume that application-level logging can be done by means of libraries that write to client files; i.e. that there is no need for any sort of special system support for logging. * A simple polling-based interface is the simplest form of interface to something like a job scheduling service. However, a simple call-back notification interface is a very useful addition that potentially provides substantial performance benefits since it can enable the avoidance of lots of unnecessary network traffic. Only job state changes result in notification messages. * There are no notions of fault tolerance. Jobs that fail must be resubmitted by the client. Neither the cluster head node nor its compute nodes are fault tolerant. I do expect the client software to return an indication of failure-due-system-fault when appropriate. (Note that this may also occur when things like network partitions occur.) * One does need some notion of how to deal with orphaned resources and jobs. The notion of job lifetime and post-expiration garbage collection is a natural approach here. * The scheduling service provides a fixed set of scheduling policies, with only a few basic choices (or maybe even just one), such as FIFO or round-robin. There is no notion, in general, of SLAs (which are a form of scheduling policy). * Enough information must be returned to the client when a job finishes to enable basic accounting functionality. This means things like total wall-clock time the job ran and a summary of resources used. There is not a need for the interface to support any sort of grouping of accounting information. That is, jobs do not need to be associated with projects, groups, or other accounting entities and the job scheduling service is not responsible for tracking accounting information across such entities. As long as basic resource utilization information is returnable for each job, accounting can be done externally to the job scheduling service. I do assume that jobs can be uniquely identified by some means and can be uniquely associated with some principal entity existing in the overall system, such as a user name. * Just as there is no notion of requiring the job scheduling service to track any but the most basic job-level accounting information, there is no notion of the service enforcing quotas on jobs. * Although it is generally useful to separate the notions of resource reservation from resource usage (e.g. to enable interactive and debugging use of resources), it is not a necessity for the most basic of job scheduling services. * There is no notion of tying multiple jobs together, either to support things like dependency graphs or to support things like workflows. Such capabilities must be implemented by clients of the job scheduling service. Interesting extension areas: * Additional scheduling policies o Weighted fair-share, ... o Multiple queues o SLAs o ... * Extended resource descriptions o Additional resource types, such as GPUs o Additional types of compute resources, such as desktop computers o Condor-style class ads * Extended job descriptions (as returned to requesting clients and sys admins) * Additional classes of security credentials * Reservations separated from execution o Enabling interactive and debugging jobs o Support for multiple competing schedulers (incl. desktop cycle stealing and market-based approaches to scheduling compute resources) * Ability to modify jobs during their existence * Fault tolerance o Automatic rescheduling of jobs that failed due to system faults o Highly available resources: This is partly a policy statement by a scheduling service about its characteristics and partly the ability to rebind clients to migrated service endpoints * Extended state transition diagrams and associated functionalities o Job suspension o Job migration o ... * Accounting & quotas * Operating on arrays of jobs * Meta-schedulers, multiple schedulers, and ecologies and hierarchies of multiple schedulers o Meta-schedulers * Hierarchical job scheduling with a meta-scheduler as the only entry point; forwarding jobs to the meta-scheduler from other subsidiary schedulers o Condor-style matchmaking * Directory services o Using existing directory services o Abstract directory service interface(s) * Data transfer topics o Application data staging * Naming * Efficiency * Convenience * Cleanup o Program staging/provisioning * Description * Installation * Cleanup Marvin. ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Monday, February 20, 2006 9:20 AM To: Marvin Theimer; ogsa-wg(a)ggf.org Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: Enclosed is a paper that advocates an additional set of activities that the authors believe that the OGSA working groups should engage in. Broadly speaking, the OGSA and related working groups are already doing a bunch of important things: * There is broad exploration of the big picture, including enumeration of use cases, taxonomy of areas, identification of research issues, etc. * There is work going on in each of the horizontal areas that have been identified, such as EMS, data services, etc. * There is working going around individual specifications, such as BES, JSDL, etc. Given that individual specifications are beginning to come to fruition, the authors believe it is time to also start defining vertical profilesthat precisely describe how groups of individual specifications should be employed to implement specific use cases in an interoperable manner. The authors also believe that the process of defining these profiles offers an opportunity to close the design loopby relating the various on-going protocol and standards efforts back to the use cases in a very concrete manner. This provides an end-to-end setting in which to identify holes and issues that might require additional protocols and/or (incremental) changes to existing protocols. The paper introduces both the general notion of doing focused vertical design effortsand then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a first principlesmanner since the authors believe that this increases the chances of identifying issues. As a consequence, existing specifications and the activities of existing working groups are not mentioned and this paper is not an attempt to actually define a specifications profile. Also, the absence of references to existing work is not meant to imply that such work is in any way irrelevant or inappropriate. The paper should be viewed as a first abstract attempt to propose a new kind of activity within OGSA. The expectation is that future open discussions and publications will explore the concrete details of such a proposal. This paper was recently sent to a few key individuals in order to get feedback from them before submitting it to the wider GGF community. Unfortunately that process took longer than intended and some members of the community may have already seen a copy of the paper without knowing the context within it was written. This email should hopefully dispel any misconceptions that may have occurred. For those people who will be around on for the F2F meetings on Friday, Marvin Theimer will be giving a talk on the contents of this paper at a time and place to be announced. Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

2 1

Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Ian Foster 13 Mar '06

13 Mar '06

Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: >Enclosed is a paper that advocates an additional set of activities that >the authors believe that the OGSA working groups should engage in. > > > >Broadly speaking, the OGSA and related working groups are already doing a >bunch of important things: > >· There is broad exploration of the big picture, including >enumeration of use cases, taxonomy of areas, identification of research >issues, etc. > >· There is work going on in each of the horizontal areas that have >been identified, such as EMS, data services, etc. > >· There is working going around individual specifications, such as >BES, JSDL, etc. > > > >Given that individual specifications are beginning to come to fruition, >the authors believe it is time to also start defining vertical >profilesthat precisely describe how groups of individual specifications >should be employed to implement specific use cases in an interoperable >manner. The authors also believe that the process of defining these >profiles offers an opportunity to close the design loopby relating the >various on-going protocol and standards efforts back to the use cases in a >very concrete manner. This provides an end-to-end setting in which to >identify holes and issues that might require additional protocols and/or >(incremental) changes to existing protocols. The paper introduces both >the general notion of doing focused vertical design effortsand then >focuses on a specific vertical design effort, namely a minimal HPC design. > > > >The paper derives a specific HPC design in a first principlesmanner since >the authors believe that this increases the chances of identifying >issues. As a consequence, existing specifications and the activities of >existing working groups are not mentioned and this paper is not an attempt >to actually define a specifications profile. Also, the absence of >references to existing work is not meant to imply that such work is in any >way irrelevant or inappropriate. The paper should be viewed as a first >abstract attempt to propose a new kind of activity within OGSA. The >expectation is that future open discussions and publications will explore >the concrete details of such a proposal. > > > >This paper was recently sent to a few key individuals in order to get >feedback from them before submitting it to the wider GGF >community. Unfortunately that process took longer than intended and some >members of the community may have already seen a copy of the paper without >knowing the context within it was written. This email should hopefully >dispel any misconceptions that may have occurred. > > > >For those people who will be around on for the F2F meetings on Friday, >Marvin Theimer will be giving a talk on the contents of this paper at a >time and place to be announced. > > > >Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox > > _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

2 1

Proposed agenda for March 13th call
by Hiro Kishimoto 13 Mar '06

13 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 13th. Monday from 4pm to 6pm (CST). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0313 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (March 8th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060308/en/1 OGSA WSRF BP 1.0 status update (Tom) Agenda bashing 2) EMS scenarios review (60 min) Steven sent out his deployment and provisioning scenarios to the list. Thanks Steven!! http://www-unix.gridforum.org/mail_archive/ogsa-wg/2006/03/msg00024.html > ACTION: Steven Newhouse to write up a first draft of a few more > scenarios on the relationship between JSDL and CDL. > - To be included in the current EMS scenarios document. > - To be delivered by mid-March > - Review on an OGSA call and continue refinement Previous F2F meeting minutes; https://forge.gridforum.org/projects/ogsa-wg/document/ggf16-f2f-minutes-200… https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… https://forge.gridforum.org/projects/ogsa-wg/document/cddlm-acs-joint-sessi… EMS module diagram reference by Stuart (under discussion) https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-F2F-OGSA-CDDLM-… BLAST JSDL document example by Chris Smith https://forge.gridforum.org/projects/ogsa-wg/document/jsdl_blast_instance/e… EMS architecture scenario document https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-ems-sc… 3) April F2F meeting venue and agenda (30 min) >From March 8th minutes; > Discussed possible venues in the Bay area. There was a clear > preference for doing the meeting in the Sunnyvale area. It is > expected that the site can be confirmed next week. > Actions: > - Jay will look into IBM facilities in Almaden and Santa Theresa. > - Hiro/Andreas to confirm whether the availability or not of the > Fujitsu facility > - Hiro to ask Ravi whether the Intel facility is available Proposed agenda review https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session Survey result as of March 7th (20 answers). https://forge.gridforum.org/projects/ogsa-wg/document/200604_Survey 4) Wrap up (10 min) AOB <NEXT CALL> March 15 (Wed): CDDLM-WG joint call (Dejan and Steven) March 20 (Mon): OGSA-HPC profile (Marvin) March 22 (Wed): Security Architecture (Takuya and Frank) March 27 (Mon): EMS scenarios, Steven's scenarios review, Information Model, Ellen's CIM profile review Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 1

OGSA-EMS Telecon
by Steven Newhouse 13 Mar '06

13 Mar '06

All, Following on from the discussions at the F2F in Athens here are some deployment and provisioning scenarios for discussion on Monday's telecon. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

2 2

FINAL CALL: OGSA 1.5 (Architecture and Glossary)
by Andreas Savva 11 Mar '06

11 Mar '06

Final drafts of the OGSA 1.5 documents ([Arch] and [Glossary]) are available on Gridforge. We'd like to submit both documents to the GGF Editor *after the March 8 (Wednesday this week) teleconference*. It's a short deadline but both drafts have been in a fairly stable condition for some time now. Also note that OGSA 1.5 is intended as a minor revision to OGSA 1.0 (GFD-I.30). Please comment on the list or at one of the calls this week. After submission to the GGF Editor these documents will go through a 30-day public comment period, so you will have further opportunities to comment. [Arch] https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec-1… (For a change tracked version, see draft 6: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec-1…) [Glossary] https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-glossa… -- Andreas Savva Fujitsu Laboratories Ltd

1 1

Teleconference minutes - 8 March 2006
by Andreas Savva 09 Mar '06

09 Mar '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060308/en/1 OGSA Teleconference - 8 March 2006 ================================== * Participants Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ellen Stokes (IBM) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Summary of Actions Actions: - Jay will look into IBM facilities in Almaden and Santa Theresa. - Hiro/Andreas to confirm whether the availability or not of the Fujitsu facility - Hiro to ask Ravi whether the Intel facility is available * March 6 minutes approved with no changes * April F2F update Discussed possible venues in the Bay area. There was a clear preference for doing the meeting in the Sunnyvale area. It is expected that the site can be confirmed next week. Group chairs should send agenda requests to Hiro. Marvin can probably attend for one day and Andrew would like to arrange that to be Tuesday or Wednesday so that Naming can also be discussed. Actions: - Jay will look into IBM facilities in Almaden and Santa Theresa. - Hiro/Andreas to confirm whether the availability or not of the Fujitsu facility - Hiro to ask Ravi whether the Intel facility is available * "Guidelines for Information Modeling for OGSA Resources" document review Agreed that in the future reviews documents should have line numbers turned on. (Especially early draft documents.) Section by section review, mainly concentrating on Hiro's comments sent to the list. ** Section 1 - 1.2) Title and contents do not match well. The content is along the lines of use cases. - It is an early draft and will be revised. - Need more description on how to do the rendering/data model. Three options were discussed: 1. Rendering as part of the interface specs 2. RM team draws up guidelines 3. DMTF does rendering It was agreed that 1 & 3 are viable options but 2 is not. Some concerns were also raised on the timeliness of option 3. For example it looks like the WS-CIM will take some time to complete. So option 1 might be better for GGF use. - The text under Figure 1 seems to be slightly out of sync with the example in Figure 2. The example should be showing an XML Schema rather than the representation of an instance. ** Section 2 Agreed with Hiro's proposal to re-organize the text to start from modeling and then move to CIM Profiling. In other words identify what is in the domain specific model, identify CIM portions and generate changes/extensions to CIM. In Section 2.1 OGSA resource is used in a different way from the Glossary definition. Fred will review the definitions and also use Jay's description of 'interesting level of resource' from the point of view of the different capabilities. ** Section 3 Section 3.2 describes 2 ways of doing the modeling work. Involving the RM team in each effort does not scale. So there is a clear need to get involvement from more DMTF experts. Ideally the option of involving the RM team should not even appear in the document but it is probably necessary during the spin up phase. Agreed to re-order the text to put the second approach first. State that it is 'preferred'. ** Section 4 Discussed the standardization process. - Should the documents be information or recommendation track? - Recommendation track may be better. Experimental may also be an option. - There is also a question of the document structure and whether the proposal to the DMTF should be a separate document that is referenced by the profile, or part of the profile. - One idea was to package everything together in one profile document, identify the changes to CIM and then summarize the proposed changes to CIM as an appendix. Doing so would provide the necessary context for the work when taking it to DMTF. - In the case of the JSIM change request the document produced within GGF was submitted with a cover document. - What is the interaction between the GGF and DMTF process? For example, what happens when a DMTF TC changes things in the original GGF document for incorporation into CIM. - Early participation or communication with DMTF WG/TC is important so they know a change request is going to be submitted and noone is surprised. - However even in the case of the JSIM proposal where the CGS WG already had a lot of participation from CIM experts there were changed made in DMTF. - It would make it harder to get buy-in from GGF WGs if their work is subject to modification by a process they have no control over. There should be one more section to cover OGSA interface documents. ** Other comments Should this document reference DSP1001 (profile specification usage guide)? - Probably need a simpler profile template that leads to simpler (shorter) profiles. - Ellen is doing the current work in the spirit of the template but tailored to the needs of GGF. - Security section: Change text to discuss 'secure management' and 'management of security' instead - There should be some description of the tools to be used. E.g., RSM, the Cisco tool for CIM profiling if appropriate, etc. * Webcast update - Jem reported that HP has no branding conditions on the slides etc. - April 26 1:30-3:30 EST is the candidate date. In practice presenters should be available from about 1pm. - Andrew Grimshaw agreed to be a presenter. - Dave Snelling may have a conflict that day. - The webcast preparation will be discussed at the F2F. - The latest slide deck is probably the one used for the IPSphere presentation and should be on gridforge. It needs to be updated--- at the very least to remove/reformat any animations. * OGSA 1.5 - no comments * Next call EMS Scenarios

1 0

Modeling guidelines document -- please review for teleconference on Wednesday
by Fred Maciel 08 Mar '06

08 Mar '06

Hi, I updated the modeling guidelines document. Changes from the previous (pre-GGF16) version are indicated. The latest version can always be found at: http://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guidelines /en/ We will review this document on the teleconference next wednesday, so please give a look. I'm looking forward to your feedback. Regards, Fred Maciel Hitachi America R&D

2 1

Regrets today
by Maguire_Tom＠emc.com 08 Mar '06

08 Mar '06

Another late night telecon overlap. Btw, I do have a conflict with the April f2f dates. As it stands now I can only attend the first day. Sorry. The following week is not good either. Last two weeks are ok Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-580-3477 (8280 3477) Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery

1 0

Last call for Application Contents Service Specification 1.0
by Keisuke Fukui 08 Mar '06

08 Mar '06

Folks in ogsa-wg, cddlm-wg and acs-wg, We, acs-wg, has come to completion of the ACS Specification 1.0 after discussions and reviews. This is the last call for comments before submission to the GGF Editor for publication. If you have comments, please get them to me by 9 am Japan time on Monday November 7. If there are no significant comments I plan to submit the document on Monday afternoon. Below is the link for the document: https://forge.gridforum.org/projects/acs-wg/document/draft-ggf-acs-spec-1.0… Regards, Keisuke Fukui ACS-WG co-chair

1 1

Proposed agenda for March 8th call
by Hiro Kishimoto 07 Mar '06

07 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 8th Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0308 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (March 7) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060306/en/1 Agenda bashing 2) April F2F meeting venue (20 min) > Re-selected April 4-7 at west coast (Bay Area) as the first choice. > Possible hosts: > - Hitachi America (Fred to check network connectivity) > - IBM (at a choice of location in the Bay area) > > Action: Candidate hosts should check availability and facilities for > F2F and report back on Wednesday's call F2F session proposal; https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session Survey result as of March 7th (20 answers). https://forge.gridforum.org/projects/ogsa-wg/document/200604_Survey 3) Information Modeling Guideline review (60 min) > Fred updated the modeling guidelines document. Changes from the > previous (pre-GGF16) version are indicated. The latest version can > always be found at: > > http://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guidelines > /en/ 4) OGSA webcast discussion (20 min) > Jem reported that HP can provide the facilities to do an OGSA > webcast, including recording and archiving for later use. Features > also include polls during the webcast, online chat, keeping track of > number of people registering, attendind, how long they attended, > etc. > > Considering the above, a date late in April is better to allow more > time to prepare. The webcast preparation should also be added to the > F2F agenda. > > Action: Jem will check whether there are any HP branding conditions > (or formatting, logos, etc) to the webcast. 5) Wrap up (10 min) AOB <NEXT CALL> March 13 (Mon): EMS scenarios, Steven's scenarios review March 15 (Wed): CDDLM-WG joint call (Dejan and Steven) March 20 (Mon): OGSA-HPC profile (Marvin) March 22 (Wed): Security Architecture (Takuya and Frank) March 27 (Mon): EMS scenarios, Steven's scenarios review, Information Model, Ellen's CIM profile review Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0