- ogsa-wg - lists.ogf.org

RE: [ogsa-wg] Joining at 6PM ET<EOM>
by Treadwell, Jem 04 Jan '06

04 Jan '06

Tom, as far as I'm aware we don't have a call tonight. If I'm wrong, someone please let me know :0) Thanks, - Jem ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Maguire, Tom Sent: Wednesday, January 04, 2006 4:51 PM To: ogsa-wg(a)ggf.org Subject: [ogsa-wg] Joining at 6PM ET<EOM> Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-508-3477 Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com <mailto:maguire_tom@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

Joining at 6PM ET<EOM>
by Maguire, Tom 04 Jan '06

04 Jan '06

Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-508-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

RE: Architecture notes (was Re: [ogsa-wg] Teleconference minutes - 7 December 2005)
by Maguire, Tom 04 Jan '06

04 Jan '06

Thanks Andreas > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Andreas Savva > Sent: Wednesday, January 04, 2006 4:58 AM > To: 'ogsa-wg' > Subject: Architecture notes (was Re: [ogsa-wg] Teleconference > minutes - 7 December 2005) > > Last year we agreed to set up an 'architecture notes' > category on gridforge. I thought that a forum would be > appropriate to hold such material and related explanations. > > The first note is on the EPR, WS-Names policy and is taken > from Tom's email to the list. > > See https://forge.gridforum.org/forum/forum.php?forum_id=587 > > From 7 December 2005 minutes: > > > > - Reviewed Tom's policy statement again. No revisions needed. > > - Agreed to put it on gridforge as a separate note (e.g., > some kind > > of architecture note). > > - Andreas will create this category; add the note and > advertise it > > on the list. > > > > Happy New Year. > -- > Andreas Savva > Fujitsu Laboratories Ltd >

1 0

Teleconference minutes - 7 December 2005
by Andreas Savva 04 Jan '06

04 Jan '06

Minutes attached. Also https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051207/en/1 -- Andreas Savva OGSA Teleconference - 7 December 2005 ===================================== * Participants Michael Behrens (R2AD, LLC) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Tom Maguire (EMC) Mark Morgan (UVa) Takuya Mori (NEC) Steven Newhouse (Univ. of Southampton) Andreas Savva (Fujitsu) Jem Treadwell (HP) Minutes: Andreas Savva * Profile definition update - Revised document is on gridforge - Tom will send out a final call email and then submit to the Editor. * 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. - Having an introductory set of slides that anyone from the group can use to present is a good idea and hopefully the MDC presentation will evolve to fill that function. * Naming review - The Naming WG has a call arranged for tomorrow - Andrew has posted the requirements document written before the OGSA-Naming WG was formed (document created by the then Naming design team). - Tentative agenda - Whether the wsa fields in question can be assumed to be IRIs - Uniqueness - On the wire issue (resolved previously?) - Hiro asked that resolution of issues should be documented. (This would be useful in general even if an issue is thought to have been already resolved.) - Next OGSA call to review Naming issues resolution planned for Dec. 19 * BES Naming discussion - Consensus reached in BES-WG: - It is in line with Tom's policy statement: - Require EPRs, don't require but recommend WS-Names - Also define some way of advertising whether a service returnes EPRs that are WS-Names or not - For WSRF will define the property to advertise this - Reviewed Tom's policy statement again. No revisions needed. - Agreed to put it on gridforge as a separate note (e.g., some kind of architecture note). - Andreas will create this category; add the note and advertise it on the list. - Informal interop next week in UK - Reviewing the OASIS interop document and planning the activity - Eventually this may become a more formal event but the focus next week is to get some initial interoperability * EMS Architecture update - Dec 21 is the planned joint call with EMS and CDDLM/GRAAP - (This is also the final call of the year) - Steven has been reviewing the WS-Agreement spec and will be arranging a separate call with GRAAP-WG - Ian's comment in the agenda - Agree that there are lots of ways of doing selection. There is no specific proposal, just a initial motivation raised on a call sometime back to look into existing work. - This is not an issue for the specific scenario that was under review since there is no selection (pre-selection assumed) - Steven will confirm with Ian that this understanding is correct. - Hiro and Andreas to share the updated deployment scenarios list. - The next EMS call is for Dec 14. - Confirmed UML tool selection: RSM is ok; waiting for the way of getting licenses to clear up. * Next call - Monday - Security profile - OGSA 1.5 and Glossary NB: Final call of the year is 12/21

1 1

Joint CFP v2: BSN'06 - SOS4CO'06
by gagnon＠soa7.com 21 Dec '05

21 Dec '05

(Apologies for cross posting) **************************************************************************** JOINT CALL FOR PAPERS BSN'06 - SoS4CO'06 2nd International Workshop on Business Service Networks 2nd International Workshop on Service oriented Solutions for Cooperative Organizations June 26, 2006, San Francisco, California, USA http://elab.njit.edu/bsnsos4co in conjunction with IEEE Joint Conference on E-Commerce Technology (CEC-06) and on Enterprise Computing, E-Commerce and E-Services (EEE-06) http://linux.ece.uci.edu/cec06/ **************************************************************************** Business Services Networks (BSN's) are business networks, that is, a group of cooperative organizations either within an enterprise or between different enterprises, which are based on services. In that context, a service represents a set of encapsulated IT components implementing specific business functions. The service interface is self-describing in order to publish, discover and dynamically bind services using an underlying Service Oriented Architecture (SOA), most often implemented using Web Services standards. However, this flexibility with regard to loose-coupling and the interoperability between cooperative organizations is being applied in current projects, especially in industrial projects. This workshop concentrates on all facets of BSN's and the architecture of service-oriented solutions supporting inter-enterprise collaboration, throughout the entire collaboration life-cycle. This includes the consideration of business strategies for the establishment of a BSN with cooperative organizations from different SOA environments and maturity, as well as the design of such cooperation and collaboration starting with the requirements until the final instantiation of the collaboration by discovering, composing, deploying, and invoking services. Based on the composed BSN, the cooperation and collaboration brings new research from the perspectives of business (e.g. provisioning) and technical (e.g. transactions), e.g. monitoring and auditing in a network of organizations. We invite papers addressing business and technical issues of BSN's from various perspectives, including development strategies of new BSNs, design of BSNs, as well as management and execution. We encourage contributions from both academia and industry. Topics of interest include, but are not limited to, the following: BSN Strategy * Business models * Integration alliances and interoperability * Value added for BSN vendors and adopters * Mobile operators, grid services, and utility computing BSN Design * Service-Oriented solutions * Requirements engineering for BSN * Ontologies, document structures, messaging formats, etc. * Match-making of choreographies of different cooperative organizations * Match-making of semantic service descriptions * Negotiating of inter-organizational business processes and workflows * Service discovery on advanced registry concepts beyond UDDI * Quality of Service (QoS) and Cost of Service (CoS) negotiation * Role of Model-Driven Architectures (MDA) for BSN BSN Management & Execution * SOA-Enablement of software vendors * Service Level Agreements (SLA) * International provisioning and adoption barriers * Pricing and marketing on BSN demand software * Monitoring and enforcement of Quality of Service (QoS) * Distributed stateless and stateful transactions * Role of security, privacy and trust in BSN * Auditing of service evolution Submissions: Authors are invited to submit original and significant research contributions in the aforementioned areas. All submissions will be peer-reviewed by the members of the international program committee. We accept papers in DOC, PDF, and PS format. Submit papers via http://elab.njit.edu/bsnsos4co/submit. It is planned to select the best papers for a journal special issue. Further details will be announced soon. Registration: Please use the CEC/EEE site to register: http://linux.ece.uci.edu/cec06. For accepted submissions, at least one author must register for the workshop in order for the paper to appear in the proceedings and to be scheduled in the workshop program. Important Dates: Paper submission: February 1, 2006 Paper notification: March 31, 2006 Camera-ready papers: April 20, 2006 Workshop: June 26, 2006 Enquiries: Please direct all enquires by email to <bsnsos4co AT njit.edu>. Co-Chairs: Stephane Gagnon, New Jersey Institute of Technology, USA Christian Huemer, University of Vienna, Austria Patrick C. K. Hung, University of Ontario Institute of Technology, Canada Andreas Wombacher, University of Twente, Netherlands Raymond Wong, University of New South Wales and Green Pea Software, Australia Program Committee: Antonia Albani, University of Augsburg, Germany Morad Benyoucef, University of Ottawa, Canada William Cheung, Hong Kong Baptist University, Hong Kong Jen-Yao Chung, IBM Watson Research Center, USA Ernesto Damiani, University of Milan, Italy Eric Dubois, Research Public Center Henri Tudor, Luxembourg Birgit Hofreiter, University of Vienna, Austria Jane Hsu, National Taiwan University, Taiwan Ottokar Kulendik, DaimlerChrysler AG, Germany Franky Lam, National ICT Australia, Australia Bendick Mahleko, Fraunhofer IPSI, Germany Angel Ortiz, Polytechnic University of Valencia, Spain Katia Passerini, New Jersey Institute of Technology, USA Pascal Pecquet, Université de Montpellier I, France Tony Shan, Wachovia Bank, USA William Shui, University of New South Wales, Australia Richard Soley, Object Management Group, USA Cheickna Sylla, New Jersey Institute of Technology, USA Kerry Taylor, CSIRO, Australia Vladimir Tosic, Lakehead University, Canada Ivana Trickovic, SAP AG, Germany Dan Zhang, University of Ontario Institute of Technology, Canada Jia Zhang, Northern Illinois University, USA Aoying Zhou, Fudan University, China Hans Dieter Zimmermann, University of Koblenz-Landau, Germany

1 0

Proposed agenda for Dec. 21st call
by Hiro Kishimoto 20 Dec '05

20 Dec '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Dec. 21st Wednesday from 4pm to 6pm (CST). This is the last call for 2005. 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: 1221 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 (if available) Agenda bashing 2) CDDLM-WG joint call (45 min) > Actions: > - Dejan to arrange for a subteam call to discuss in more detail the > provisioning/deployment issues, JSDL, CDL, etc. > - Volunteers (mainly in Boston area or same timezone): Jay, > Andrew, Stuart, Michael. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051109/en/1 3) GRAAP-WG joint call (45 min) From Dec. 7th telecon minutes: > * EMS Architecture update > > - Dec 21 is the planned joint call with EMS and CDDLM/GRAAP > - (This is also the final call of the year) > - Steven has been reviewing the WS-Agreement spec and will be > arranging a separate call with GRAAP-WG https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051207/en/1 From GGF15 F2F minutes; > Action(4): Set up a team to explore WS_Agreements issues more, > especially relating to allocation and QoS assurance. And > come back to OGSA-WG on how to use WS-Agreement (possibly > evolved) with EMS. Clarify > - How WS-Agreement possibly needs to change to fit in OGSA > EMS > - Set the first review after 30 days; check what can be > done. > - Volunteers: Steven Newhouse (to lead), Dave Berry, Chris > Smith, (Jim Pruyne; not present >GRAAP-WG to confirm) 4) Jan. F2F meeting update (20 min) Proposed agenda with attendee list: https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… Survey result: https://forge.gridforum.org/projects/ogsa-wg/document/2005Winter_F2F_survay/ If you've not yet answered the survey please take a time to answer the following on-line survey to let us know your availability for sessions and group dinner. http://www.zoomerang.com/survey.zgi?p=WEB224VCKBH9KA 4) Wrap up (10 min) AOB <NEXT CALL> Jan. 9 (Mon) F2F preparation Jan. 11 (Wed) If we can make a quorum Jan. 16-20, interim F2F meeting in Sunnyvale. Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ Happy holidays! -- Hiro Kishimoto

1 0

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

19 Dec '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Dec. 19th 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: 1219 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 (Dec. 14) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051214/en/1 Agenda bashing 2) OGSA-AuthZ joint call (30 min) - XACML 3.0 based authorization query interface status - Get buy-in from the OSG Privilege Project, the LCG Joint Security Group, and Shibboleth community - Status of OGSA-AuthZ WG's submitted specs - New OGSA-AuthZ WG charter - Jan F2F meeting session agenda (Jan. 19, 1:30-3pm) See excellent minutes by Alan Sill and Andreas Savva; https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051121/en/1 3) OGSA Basic Security Profile discussion (30 min) Takuya will send out a proposal to the list. > 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. 4) Naming requirement discussion (30 min) OGSA-naming WG has had a teleconf on Dec. 9. Mark uploaded a minutes to GridForge Andrew and Mark explain their discussion and show revised requirement document which includes issues pointed out on the list. From Nov. 16 telecon minutes; > 1. Andrew and Mark for the OGSA-Naming WG will summarize Naming > requirements and issues > - Including issues from the list discussion and also including a > separate set of OGSA-DAI Naming requirements > 5) Jan. F2F meeting and GGF 16 update (20 min) Attendees and session agenda for Jan. F2F. Hiro requested 2 sessions at GGF16 > - 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 6) Wrap up AOB <NEXT CALL> Dec. 21 (Wed) EMS Arch CDDLM/ACS/GRAAP joint call ** DEC 21 IS THE LAST CALL OF 2005 ** Jan. 9 (Mon) F2F preparation Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

3 3

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

15 Dec '05

Karl Czajkowski wrote: > Dave, I think the interesting point of collision with "candidate set > generation" and "planning", e.g. traditional scheduling, is when you > consider non-trivial QoS regimes. For example, when services do not > give best effort service to all callers, and you cannot just assume > statistical averaging to predict future service based on past, etc. I prefer to think of this in terms of resource selector services having a non-trivial dependency on the security context, and in particular upon the user's role. The key is that optimization from a user's perspective is only possible within the context of the relevant user role(s), since it is that which determines what resources are visible to those users. Trying to use information given to one role with another isn't going to be helpful at all. > Then, there is a significant difference between a scheduler or broker > who returns advisory information and one who returns authoritative > information. I don't see a major difference, or at least, not until you start having nailed-down reservations attached. Without any committed reservations, a candidate execution plan is indistinguishable in the case of it being issued by an advisory or an authoritative broker. Furthermore, it was agreed at the last GGF that neither of the RSS services would cause any reservations to be entered into. By that, I mean that no consumption of resources would start that could be charged to the user; systems are naturally free to try to pre-stage configurations in response to queries for candidates if they so choose, but they will be doing the service grid equivalent of speculative execution (and, for example, won't be able to start staging files using the user's identity) and if things fall through, it will be the provider who will have to swallow the costs. (I forsee this sort of risk being the foundation of a viable business model in some circumstances, but would not want to force anyone to adopt it.) > In the advisory case, he is essentially a discovery service helping > you locate services with nice properties observed in the usefully > recent past. However, until you act on that information by attempting > to acquire service, you have no idea whether the service is actually > nice or not for your goals. He may be suddenly congested, or have > differentiated policies which make your request impossible to > fullfill despite his overall nice status. > > In the authoritative case, the scheduler actually has some control > over those remote services, i.e. (part of) their capacity is reserved > to be used at his discretion. In this case, he can actually > determined when and how much service you should obtain, and inform you > of a stateful adjustment to his overall resource plans that includes > you. I see that as part of an advance-reservation protocol, and not as part of the CSG/EPS. The reason for this is that different applications will need different strategies for recovery from this sort of failure. Some will want to just go straight back to the user and say "it can't be done" but others will wish to try some number of execution plans first. Because of the wide variety of possibilities involved, it looks like a generalized workflow problem (not just a job workflow problem) and it is therefore outside the scope of RSS and instead inside the "Job Manager" wooly cloud^W^Wblack box. The other point is that there is no way to stop a resource from going away unexpectedly or a client from failing to consume its allocation. The resource might get hit by a disaster (natural or man-made), the client might die, etc. But this isn't a new problem; it occurs in the world of business every day and they deal with it. We should learn from them (e.g. by describing the consequences of such failures in terms of finanicial penalties) and not reinvent this particular wheel. > There might be protocol differences to support these cases, e.g. an > authoritative answer might carry some rights assertion that you can > present to the service, or the broker may have to go update remote > services behind the scenes but before you manage to contact them. > Also, the authoritative broker may demand that you "decline" > allocations he has issued you, while you can presumably walk away from > an advisory information source since no stateful allocation has been > made. What you think of as brokering is more than what I think of as brokering it seems. In my view of things, what you call brokering is what I would describe as a higher-level service built on top of brokering (i.e. brokering plus reservation). While this is an interesting topic to work on, I'm not convinced that enough of the answers exist in more than one place for it to be worth pushing forward with this wider stuff at this stage. Once we (as a community) have a bit more implementation experience, the time for standardizing this stuff will be a lot riper. > I do think you are on the right track to call a ranking function > "policy", and in non-trivial scheduling regimes I think you will > always have to present such policy rather than being able to obtain a > sufficient picture of the environment to make decisions yourself. > This is because of several things: > > 1. You will not get an atomically consistent view of the environment > to act on, while the remote manager may have such a mechanism. That's true. An atomically consistent view would require locking of databases (or equivalent) across organizations, and is therefore a total non-starter. > 2. You will most likely not get a complete picture of the future > service allocation plans, in the event of advance reservation. > It would be too much data to exchange for each request; it might > include confidential information; and it might not be clearly > separable from the scheduling algorithm that might include > statistical approximations and/or other hueristics. At the University of Manchester we're looking into these things in more detail. At the moment, it looks like the brokering world is going to be categorizable into multiple types of service depending on the quality of information available. This work is still actively ongoing though, so it is a bit too soon to report on it. > 3. You will not get a complete picture of the differentiated polcicies > that different brokers or services apply to specific individuals, > because it may be confidential and is also meaningless without a > global view of other competing activities. (I think I've covered this point already.) > Thus, I think a significant step of ANY distributed planning exercise > with non-trivial QoS will be the sort of handshake captured in > WS-Agreement: make an "offer" bearing policy expressions that describe > what you want; allow the authoritative resource manager to consider > this offer among others and its stateful policy and resource > availability models; obtain an answer of whether the manager can > arrange services according to your offer; and (optionally) introspect > to find out HOW the manager will provide you service. > > All interface "refactorings" are not equivalent across protocol > boundaries between parties with different authority and trust roles... True, but I'm not at all convinced that WS-Ag is quite in the sweet spot either. It would help a lot if it was easier to tackle the document parts of the spec separately from the service parts because at the moment, the sheer size of the overall spec and the feeling that you have to read virtually all of it to understand it[*] is scareing some people off. Donal. [* FWIW, I found I had to read not just the spec but also some of the presentations about it too to understand what was going on. To me, that indicates that the spec document itself has not yet captured all that you intend it to. ]

4 9

FINAL CALL: OGSA Profile Definition
by Maguire_Tom＠emc.com 15 Dec '05

15 Dec '05

The OGSA Profile definition has been updated to address public comments received. Please take a moment and review the FINAL CALL document (link below). Positive acknowledgement of the document would be appreciated to achieve rough consensus. The chairs would like to submit the final document to GGF Editor by 12/16. To that end we will agenda a final discussion on the OGSA Profile Definition for Wednesday 12/14. /projects/ogsa-wg/document/draft-ggf-ogsa-profile-definition/en/19 <https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-profil e-definition/en/19> Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-508-3477 Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com <mailto:maguire_tom@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

2 1

Teleconference minutes - 14 December 2005
by Andreas Savva 15 Dec '05

15 Dec '05

Minutes attached. Also https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051214/en/1 Thanks to all attending. -- Andreas Savav OGSA Teleconference - 14 December 2005 ====================================== * Participants Michael Behrens (R2AD, LLC) Fred Maciel (Hitachi) Steve McGough (Imperial College) Mark Morgan (UVa) Steven Newhouse (Univ. of Southampton) Andreas Savva (Fujitsu) Minutes: Andreas Savva * December 12 minutes approved with no changes * OGSA Profile Definition final call - No objections to submitting this document to the GGF Editor. * EMS Architecture update ** RSM license - No update yet on who is to be the IBM representative within GGF. - Andreas will follow up with Hiro and Ellen but it looks unlikely that licenses can be obtained before the F2F. - Meantime people could use the 30-day free version or use their existing tool and convert sequence diagrams later. - Andreas volunteered to help convert such sequence diagrams to RSM. ** Deployment chapter breakdown review - Reviewed draft outline sent by Andreas to the list - Proposed changes is re-ordering of the sections and the clarification that the 'level' of the container is fixed for the early scenarios. Also the addition of a time estimation scenario and the option of the selecting the 'level' of the container dynamically. - Agreed to re-organize the chapter along these lines. It will be reviewed again when it is time to produce detailed sequence diagrams. - Andreas to update the document. - Are there scenarios for containers going on and off the network; perhaps because connectivity is lost? - Not an issue discussed in detail yet. - In the sense of mobile resources, the naming abstraction may be usefully applied. - Also planning to use a resource that may be available in the future may be partly covered by the existing scenarios. (And perhaps should be made clearer in the existing list of scenarios.) - Michael volunteered to so a short write up on this issue to include as a note in the document.

1 0