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

Resource Management design team teleconference
by Fred Maciel 02 May '05

02 May '05

Hi again, The first teleconference of the Resource Management design team will be next Tuesday, May 3rd, from 11AM to noon PDT. My apologies to those in Japan, this was one of the few slots available (I'll sync with you in the OGSA teleconferences). The proposed agenda is: (1) CIM-Glue-JSDL comparison, mainly: - decide the format of the comparison - decide a few milestones (London OGSA F2F and GGF14) - divide the work (2) Discuss ways to lower the bar for people to start using WBEM and related software on their projects. (Is there anyone knowledgeable in the DMTF academic alliance partnerships? Any experiences document?). (3) Time allowing, discuss the state of GGF-DMTF liaisons, incuding the OGSA-related work. Dial-in: Toll Free: (888) 422-7120 Int'l Access: (608) 250-0194 Participant code: 693305 See you there, Fred Maciel.

2 1

RE: [ogsa-wg] [Fwd: Hotel links]
by Dave Berry 02 May '05

02 May '05

Folks, Which hotel are we choosing: the Rydges or the Concord? Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andreas Savva Sent: 27 April 2005 23:11 To: 'ogsa-wg' Subject: [ogsa-wg] [Fwd: Hotel links] Here's Andrew's email [F2F Hotel information] I was asked to forward. Andreas

2 1

Data: telcon agenda for May 4 - WS-DAI & ByteIO
by Dave Berry 29 Apr '05

29 Apr '05

Dear all, Here are the planned topics for upcoming telcons: May 4 - Data access (WS-DAI and ByteIO) May 11 - Data storage May 18 - Document review & plan for F2F This week's telcon will be at the usual time of Wednesday (4th May), at 8:00am PDT / 11:00am EDT / 4:00pm BST / 5:00pm CEST. PIN for all calls: 632 065 UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 Here is a provisional agenda for this week. 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (attached) Agenda bashing 2) Action report (5 min) - Fred to send notes on how to use Majordomo to Allen and Dave. - Dave to try to arrange data transfer discussion. - Allen to write up naming use cases for passing to OGSA WG (after review in our WG). - Ann and Allen to clean up the draft and mail it around. 3) WG status (5 min) 4) F2F planning (5 min) 5) Technical content (35 min) - WS-DAI - ByteIO 6) Wrap up (5 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Monday May 2 Teleconference: BP and Profile Template
by David Snelling 29 Apr '05

29 Apr '05

Folks, We have a teleconference on Monday afternoon/night. We should try to close all issues on the Basic Profile and the Profile Template. Time: 18:00-20:00 Eastern Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Agenda: 1) Early discussion Note taker assignment Roll call Agenda bashing 2) Profile Template discussion 3) Basic Profile discussion 4) Wrap up AOB Tracker numbers: Tracker 1322: Tracker 1323: Tracker 1363: Tracker 1367: Tracker 1365: Tracker 1257: -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

ByteIO WG Mailing List and Minutes from Last Call
by Hiro Kishimoto 29 Apr '05

29 Apr '05

Neil's email bounced. ---- Hiro Kishimoto Subject: ByteIO WG Mailing List and Minutes from Last Call Date: Thu, 28 Apr 2005 15:35:53 +0100 Dear All, the ByteIO WG charter has been approved and our mailing list is now setup! To subscribe, please send a message to majordomo(a)ggf.org with just the following line in the body of the message: subscribe byteio-wg my.email(a)ddress.org (substituting your own email address) We have fortnightly telcons at 14:00 UTC - the schedule for the next telcons and the details for participating are below. Notes from our previous telcon are attached to this message, and will be posted online once our GridForge account is setup. Date of next Telcon: 3 May 05 at 14:00 UTC (09:00 CDT / 10:00 EDT / 15:00 BST / 16:00 CEST) Call details: - UK Dial In: 0845 245 0224 - US Dial In: 1-866-838-0046 - International Dial In: +44 1452 542309 - PIN Number: 369786 Agenda of future telcons: - 3 May: discuss draft template for use cases and discuss initial use cases - 17 May: continue looking at use cases, discuss bulk data transfer protocols, and requirements for F2F meeting - 26 May: OGSA Data and ByteIO F2F in London (extreme discussion of documents) - 31 May: Discussion of arrangements for GGF, discussion of prototype specification and draft documents - 14 June: Further discussion of specification and use case documents - 26-29 June: GGF14 Chicago Best regards, neil -- << NOTE ROOM CHANGE, OTHER DETAILS REMAIN CONSTANT >> Neil P Chue Hong | T: [+44] (0)131 650 5957 Project Manager, EPCC | F: [+44] (0)131 650 6555 Rm 2409, JCMB, Mayfield Rd. | E: N.ChueHong(a)epcc.ed.ac.uk Edinburgh, EH9 3JZ, UK | W: http://www.epcc.ed.ac.uk "A film is like a battleground. It's love, hate, action, violence, death - in a word, emotion." - Sam Fuller ------=_NextPart_000_00FE_01C54C07.FFAE1D10 Content-Type: text/plain; name="20050419 byteio.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="20050419 byteio.txt" Minutes from the ByteIO Telcon on 19/4/05 ----------------------------------------- Attending: Mark Morgan, UVa (MM) Neil Chue Hong, EPCC (NCH) Dave Berry, NeSC (DB) Mario Antonioletti, EPCC (MAA) Date of next Telcon: 3 May 05 at 14:00 UTC (09:00 CDT / 10:00 EDT / = 15:00 BST / 16:00 CEST)=20 Call details: - UK Dial In: 0845 245 0224 - US Dial In: 1-866-838-0046 - International Dial In: +44 1452 542309 - PIN Number: 369786 Agenda of future telcons: - 3 May: discuss draft template for use cases and discuss initial use = cases - 17 May: continue looking at use cases, discuss bulk data transfer = protocols, and requirements for F2F meeting - 26 May: OGSA Data and ByteIO F2F in London (extreme discussion of = documents) - 31 May: Discussion of arrangements for GGF, discussion of prototype = specification and draft documents - 14 June: Further discussion of specification and use case documents - 26-29 June: GGF14 Chicago Discussion of data transfer protocols ------------------------------------- MM had looked at WebDAV, does it really apply?=20 Also at PBIO, looks like an alternative to XDR. Bill Allcock recommended looking at XIO as well for background. Does ByteIO fit more at the client API level? MAA: What does PBIO stand for? - MM will pass on link MTOM will be in WSE3.0 but unclear when it will be released. Axis2 has MTOM in plans, but not yet done. NCH try to ask Microsoft Europe contact whether WSE3.0 is coming out = soon and whether DIME will still be around. Discussion of use cases ----------------------- Came up with a use case from the point of view of an NFS server = accessing a ByteIO web service. Then a more grid aware application, = which knows about ByteIO interface, so can make decisions. Have a client = which wishes a more connection oriented view of a ByteIO stream, = establishes an endpoint, which marks a particular position in a file. One of the things which pops up is a way of locking the data source. Avaki allowed the placing of an advisory lock, which is used by NFS = protocol, but doesn't seem to be heavily utilised. People worry about it = but don't often do anything about it. Simple cases don't need locking but we will probably have a lot of = people standing up at next GGF saying we need locking :-) DAIS discussion of use case has revealed a possible hole in their = specification to do with getting data into a data service (rather than = getting data out). =20 DB contacted the NEC guys, and they sent along a simple visualisation = application use case. Use Cases - write some down, come up with a template on what we want to = get from a use case, reformat our use cases into this format. what functionality will be layered on top of ByteIO [MM] Mail out a draft template for use cases for next Telcon. ------=_NextPart_000_00FE_01C54C07.FFAE1D10--

1 0

Telecon Minutes for OGSA BES (21 April 2005 and 28 April 2005)
by Hiro Kishimoto 29 Apr '05

29 Apr '05

Mark's email bounced. ---- Hiro Kishimoto Subject: Telecon Minutes for OGSA BES (21 April 2005 and 28 April 2005) Date: Thu, 28 Apr 2005 13:10:08 -0400 Here are the two telecon minutes documents from the first to OGSA BES teleconferences. Andreas, can you point Me at the correct place on gridforge to be putting these? -Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.mark-morgan.net mark(a)mark-morgan.net ------=_NextPart_000_0012_01C54BF3.9A259EA0 Content-Type: text/plain; name="Minutes - 28 April 05 BES.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Minutes - 28 April 05 BES.txt" Minutes for BES Telecon -- 28 April 2005 Attendees --------- Andrew Grimshaw Mark Morgan (Minutes) Steven Newhouse Darren Pulsipher Fred Maciel Tom McGuire Andreas Savvas Karl Czajkowski * Many presentations at GGF had something at the bottom end that started = up services - create - instantiate - submit - etc. - Took some kind of JSDL or something and returned some kind of handle -- EPR -- etc. - Since that seemed like fairly consistent pattern, can we agree that = that is the pattern that we are looking for for factory like operations? -- Yes * Last call we agreed that we were going to work with both legacy jobs = and service instantiation. Is there a consensus that this is the basic = approach that we want to be taking here? - No dissagreement. * Karl brings up WS-Agreement. - Concern about WS-Agreement is that going with it could stall the = pipe. - We are under pressure to have something tangiable come out of this process in a fairly short period of time. -- Waiting on WS-Agreement could hurt that. - On the other hand, it seems like if we could come up with a basic = thing here, we could sometime in the future refactor in terms of = WS-Agreement. - Is there agreement that we should wait on WS-Agreement? -- Would like to know more about the timing for WS-Agreement? -- Current plan in the group is to try and have the next rev for GGF = in Chicago for another comment period. Hoping that this will be a "pat on the back" comment period so the hope is that it might be ready in a soon time frame (a few months). - Is the draft in gridforge close to what is expected to be presented = in Chicago? How closely does this match what we are talking about here. -- WS-Agreement is a WSRF based approach. Current issues include technical issues so the technology isn't frozen...there will be changes, but the basic idea is pretty close. -- The factory pattern is to create an agreement. The operatoin is called createAgreement and it returns an EPR which is the agreement (in the synchronous case) or an EPR which you have to talk to to = see if the agreement was accepted (in the asynch. case). -- That pattern isn't too far from what we have here. -- The big difference is that what we are talking about here in BES is that there are other things that we have put into the container = that are more specific to container like things then to a general agreement. - Propose to the group, put on the agenda for next week, a discussoin = of how we want to deal with agreement. -- Karl to send out mail with links to which documents we should be looking at. -- Karl to confirm the projected schedule for agreement. * Current Prototype - What is the purpose of submissionIdentifier? -- This is a message identifier, like UUID. -- Question whether or not we really need this because JSDL already = has it. -- If it's already in JSDL, then we don't need this parameter. -- The objective is to eliminate duplicate requests. -- We'll take the parameter out as an input, but replace it with a comment to indicate that we need this duplication detection somewhere -- either at message/SOAP layer, or perhaps in JSDL. - Do we want to presume that something like WS-Names will be finished = in time? - Leave it for now that it will be defined elsewhere. If we get down = the pipe and WS-Names aren't there, we will have to get more concrete and = get back to it. - Punt for now on faults -- one of the things we will have to figure out later is the fault model. -- Mentioning the faults is good, but it's not time to talk about the mechanism. --- We'll have a call later with "bring your own favorite faults". * getActivityStatus: - We have a container for services that can be a hosting environment of some kind, or something else. - Will model some physical resource out there. - What other kinds of things do we want to be able to do to containers. - One is, give me the activity or status of one or more named things = that have been instantiated on this thing. -- One of the arguments we've had on this is that, on the one hand, if everything is WSRF, then I should directly talk to the named input. -- This goes for a few of the operations. -- The argument is to say that having two different functions is to have two different ways to do things. -- But, sometimes you want to talk to the container to do something to a down or unresponsive object, or you want to do bulk operations. -- If we have these get status things and the terminate one in particular -- sometimes you have to kill something that isn't responsive. - Talking about the model, or the rendering, or both? One of the = problems the OGSA WG has to address very soon is the resource model for OGSA = in general (and mangement model) vs. the individual thing for individual services and containers. A lot of the things that we are going to be doing on containers are going to look like management things. You = can't just pull it away from the service -- they are inter-twined. -- We are to have a discussion of this in London. - You also have things that even a scheduler wouldn't care about that a manager may care about like changing the policy on how to throw out jobs on an overloaded (or overcommitted) resource. -- Andrew told Hiro that he would prepare an example of the kinds of places this would show up. - Karl votes in favor of this. Some discussion to separate notion of job management from aggregate job management (kill this job, kill all jobs). -- Managers didn't like the ability to get the status of all jobs. -- In reality, you end up crippling systems to satisfy requirements. -- Security strickly speaking is out of scope, but in practice you have to think about it. -- Let's make the assumption that someone above us is going to handle security, maybe with a document where they pass in there user identification or credentials. The underlying system will handle that. You have to make assumptions that the implementation will handle this stuff as long as you believe that the user's = credentials will be passed. Leave it up to the implementers to implement or some security/policy working group. - There has to be some linkage back to the original JSDL document. The schema (format) of this document TBD. -- It needs to have the activity identifier and the activity state. -- You return multiple activity states -- you may have multiple data staging -- how do I match them up. --- You need to be able to name the states and match them up with things in the JSDL document. -- Should the BES include data staging in it? --- If you are thinking about the workflow to run a job is something that could take place outside of the BES interface. --- If there is an overall job manager, it could start a small job or service that does the staging for you. That's a separate job. --- Depending on how we decide to do BES, you could make all data staging irrelevant. ---- We need to dive into this more deeply. ---- How simple can we make BES by pulling out things like staging? ---- How simple "SHOULD" we make it? * No desire to make the calls long then 1 hour. * Final discussoin briefly is about the terminate with prejudice = function. - Is returning the right thing to do? -- We shouldn't return anything. -- Boolean isn't rich enough. -- You could get something back saying it's dead, there's nothing there, it's going down, etc.....from a practical sense, there's a bunch of terminate status as well.... -- It should either be an empty output, or some kind of fault model or something. -- We should think about whether or not this is synchronous or asynrchronous. -- Decide to make output empty (we get an empty return or ack right away). -- It's asynchronous in terms of the functionallity, not the RPC. * Successful meeting - Mark to send out notes - Andrew to clean up slides (like AbstractName -> WS-Name). * Agenda for next week is to discuss the agreement document and also to = get the minutes approved. This WG is on the agenda for the next steering group = call next week. No expectations of problems. Expectation is for approval on Tuesday. ------=_NextPart_000_0012_01C54BF3.9A259EA0 Content-Type: text/plain; name="Minutes - 21 April 2005 - BES.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Minutes - 21 April 2005 - BES.txt" OGSA BES BoF Telecon (21 April 2005) Attendees --------------- Mark Morgan (Minutes) Fred Maciel Hiro Kishimoto Andrew Grimshaw Steven Newhouse Darren Pulsipher Kabushige (NAREGI) Ravi Harei Tom McGuire Chris Smith Karl Czajkowski Dave Snelling Jem Treadwell Agenda Bashing ------------------------ * Get Charter Finalized * If we get through that, the future telecon schedule and the timeline Some things we could knock off the list of future discussions Finalize Charter ----------------------- * Two modification that have been made to this document vs. the one that was sent out before GGF13 in Korea - Scoping -- Only legacy, or service instantiation too - Do we want to define what the interface is on the things that get returned from instantiation - Stronger wording for communicating and interactinvg with the OGSA WG reguarlly * Solicit a Volunteer to maintain the GridForge Site -- no volunteers. * Andrew added sentence about OGSA-WG interaction. * Need stronger language like Data and ByteIO -- like review meeting at every milestone before the document is sent out. - Will this slow us down? - Having a review meeting is OK, but the question is do we need blessing, or is this just a presentation. * Does it hurt to have a review meeting? * Will OGSA have a veto power? - No, you can publish without, but if you want to use the ogsa name, then you have to have approval. * We linked into the charter that we are going to be working along the lines of the OGSA-WG -- why do we need a second ratification? - The thing is, the charter talks about the spirit of these two WGs, but in the final analysis the two WG could have a diametrically opposed view and it would be up to the GFSG editor to sort it out. - Because of this, we're perfectly comfortable with this. - Some have said that the current language is fine as it is as long as it is understood that the language doesn't mean veto. - The GGF rules say that the OGSA WG does NOT have veto power. - If one WG starts having veto power over another, then that has to come from somewhere. * Scope - Changed one thing in the initial scope doc....should it be just for legacy job management or for also web service intsantiation management? -- A number of people said that we shouldn't limit it. -- Can view legacy job as a special case. -- A lot of systems that have been discussed are the same whether or not the thing being launched is a legacy job. -- Decision to allow for the general case. * Goals - Having a draft recommendation document by GGF14. -- This is aggressive, but think we can do that. -- Hoping we can refer to a bunch of stuff in JSDL. - Not sure how well JSDL will cover service instantiation. -- JSDL has the concept of being able to add any type of service. -- Either it will end up being that we will have to add some extensibilities on JSDL, or we will provide feedback to the JSDL group on things we need. - Intention at UVa is to do an implementation of the spec. so that we can write an experience document for Sept. -- We need that before we can push the doc. all the way through. - The next deadline is can we have fought out all the details by Nov in order to get a public document out. - We don't want to say that the doc. in June is a proposed standard, but we do want to make it publically available. -- It will be a publically available working group draft. - What about the Experience Doc. -- Not clear from the process how we should handle this. -- Assuming we do one at UVa, we will write up our experience with that, since it's info doc, we could bring it to the WG, then they could decided whether or not to make it a WG info doc. -- OMII is aiming to also have an implementation. So supposedly we'd have the real document for the GGF editor and for review in the end of October. * Management Issues - It's boiler plate for the steering committee. - Platform is agreeing to praticipate at some level. * OGSA is very focused on interoperability issues, this is why the Base Profile is so important. Not only OGSA WG but aslo GFSG wants to see ogsa prefixed wg like this is based on the basic profile or not. What does this working group think about the Basic Profile. - Andrew frames question this way: There may in the end be several basic profiles. - What he would rather have the working group focus on is the issues such as "What are the interfaces", "What are the attributes or meta data that are relevant" as opposed to the particular mechanics that are used to manipulate them. - That said, take attributes (which could be Resource Properties) -- We can define them as attributes or meta data, but then say that the way that they would be rendered in the OGSA BP would be as resource properties. That way we don't close the door on others. It's not as strong as what you want to put in. - But, if you don't define how you access informtaion and capabilities, then you don't have a complete interface. If you leave it open, then you throw interoperability out the window. - Yes, you have to describe an access mechanism, but there is no reason you can't define multiple access mechanisms. -- At least one should be based on Basic Profile. That is fine. - Everyone can agree that we might want a resource property for a container that is called "Processor Architecture" (like JSDL). -- Clearly in a WSRF based impl, this would be a resource property that you can do a get on, but not a set. But, are we going to focus on what these properties are, but not how you get them. Can't we say, one way to get them is the WSRF way. -- What we don't want to do is to proclude other ways of doing things in other ogsa profiles that may happen in the future. - When we put together the rough working group back in GGF 5. Back then we explicitly tied ourselvces to OGSI. That was a mistake. It seems very dangerous to have a technology option in the charter. But are we referencing a technology option (WSRF), or the basic profile which could change. Couldn't this change in the future. If there was a phrase about using a profile from the OGSA working group, then that's fine. - On one of the last OGSA phone calls, we clarified that WSRF is not mandidated in the profile, but it does say that if you use stateful resources, then you use WSRF. But nothing says we have to have stateful resources. As long as the use of an OGSA profile is in here (and it's important to say "a" profile, not "the" profile). * This is in the charter now, everyone agrees with this. * There are two levels of infrastructure defined - WS-I base one - WSRF on top of that. - Clearly this is going to be a debate that will swing back and forth over time -- to a large extent, it's important for interoperability. - However, to hammer stuff out here at the beginning, it's OK. Let's define things in terms of the ideas, and then later we can have a "rendering" of the model with a specific technology. - Some are skeptical of this -- seems like at the end of the day we really need to have WSDL. -- Let's do everything in IDL right up front. Later we can do the mappings afterwords. Eventually we will need WSDL. Not much agreement on this. IDL seems useful to some people, others would prefer to go straight to XML -- Ultimately we need WSDL, but why can't we use IDL in the interim. But, is this discussion really necessary wrt the charter. * We've asked to be called ogsa-bes, then if we think we are rendering the ogsa architecture, then we should reference the ogsa documents in this. - If this is uncomfortable to some people, then we should drop the ogsa brand. - What isn't clear is whether or not the ogsa brand is open or closed to alternative profiles. - Many would rather keep the ogsa brand on the working group. - The WSRF v. WS-Transfer battle will have to be fought in the OGSA WG. - Should we say that if other profiles come up, that we would try to do our best to render all available profiles? -- Not quite everyone. -- Seems like we don't need to put this in the charter. * Seems like we can say that everyone agrees and we can send this into the steering committee. * Also seems like we will be an SRM. * Would like to hold telecons every week * The WG chairs will put together an agenda before early next week to get comments. * We'll have a telecon next Thursday. * On the OGSA WG call on next Monday, Andreas will be giving a presentation of the JSDL specification * We might also want to take a look at the SAGA groups outputs. - They have an API and they might be an endpoint consumer for what we put together. * Daren, Steven and Andrew will put togheter an agenda for next week. * Charter to go in this afternoon. * Re: F2F in may. There has been a plan to have the F2F in conjunction with the OGSA F2F on May 22nd in london at Imperial College. - We'll work something out for a telecon bridge. - We'll work something out for Karl. ------=_NextPart_000_0012_01C54BF3.9A259EA0--

1 0

[ogsa-wg | Roadmap - 1398] Compliance Tests
by Sourceforge Tracker Monitor 28 Apr '05

28 Apr '05

A new artifact has been added: 1398 Submitted by: Jem Treadwell Submitted date: 2005-04-28 10:05:05 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1398&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1398&group_id…) Summary: Compliance Tests Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1398 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Jem Treadwell Last Modified: 2005-04-28 10:05:05 Submitted By: Jem Treadwell Submit Date: 2005-04-28 10:05:05 Assigned To: Jem Treadwell File(s): <None> Description: Version 6, section 2, list item 3 (OGSA Compliant Software) says: "We may also expect that a set of OGSA Compliance Tests will be developed that define the practical criteria that must be satisfied for a software system to be called OGSA-Compliant." We need to clarify whether this is intended to mean a software suite, or simply a description of what tests should be performed. Ultimately it will need to reflect GGF's position on development of compliance test suites. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1397] Better name for Basic Profile
by Sourceforge Tracker Monitor 27 Apr '05

27 Apr '05

A new artifact has been added: 1397 Submitted by: Steven Newhouse Submitted date: 2005-04-28 00:08:39 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1397&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1397&group_id…) Summary: Better name for Basic Profile Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1397 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Steven Newhouse Last Modified: 2005-04-28 00:08:39 Submitted By: Steven Newhouse Submit Date: 2005-04-28 00:08:39 Assigned To: &lt;None&gt; File(s): <None> Description: The current 'OGSA Basic Profile' should be renamed, e.g. OGSA WSRF Basic Profile, to better describe what it is about and allow other basic profiles to be developed in the future. View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[Fwd: Hotel links]
by Andreas Savva 27 Apr '05

27 Apr '05

Here's Andrew's email [F2F Hotel information] I was asked to forward. Andreas

1 0

Resource Management design team teleconference
by Fred Maciel 27 Apr '05

27 Apr '05

Hi, I want to re-start the activities of the resource management design team, and a teleconference will be a nice way to do it. We need to put everybody in sync and get the work started. The main subject of the teleconference will be the CIM-Glue-JSDL comparison, which will be useful for EM (Execution Management) as a whole, and in the short term it will be a much needed input to BES (Basic Execution Service). We need to decide the format of the comparison, get a few milestones (London F2F and GGF14), divide the work, etc. (We'll also need to think about manageability on EM, which might be the start of the profiling. But I'd start that when BES gets more concrete). Another possible subject is whether we need to think of ways to lower the bar for people to start using WBEM and related software on their projects. Say, profiles, or a GGF experimental document? Now, please cue in the Mission Impossible theme song and let's decide a time slot for the teleconference. Here are some suggestions, please e-mail me your availability. (Anybody from Japan interested in participating?). - Monday until 13:00 PDT - Tuesday 10-12 PDT - Thursday 14:00 and later, PDT Thanks in advance, Fred Maciel.

2 1