- ogsa-wg - lists.ogf.org

Teleconference minutes - 27 February 2006
by Andreas Savva 28 Feb '06

28 Feb '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060227/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 27 February 2006 ====================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Ellen Stokes (IBM) Andreas Savva (Fujitsu) Takuya Mori (NEC) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Minutes: Andreas Savva * Summary of Actions Action: Hiro to do a survey for the F2F location and dates. - Simple format: date and location pairs and a yes/no choice - 3 locations: East coast, West coast, UK (London) - 2 dates: April 4-7 or April 10-11 (avoid Good Friday) * Feb 22 Minutes - approved with no changes * April F2F agenda Hiro sent out a proposed agenda for the April F2F. - (Note that the days of the week in the proposal are tentative.) Confirmed again that Information model and EMS (including CDDLM discussions) are the main topics. - CDDLM joint discussion is on the list. Dejan may not be able to participate if the meeting is in the UK but there are other CDDLM people based in the UK. OGSA-HPC: Marvin has said that he cannot make the week of April 3rd in person. Hiro is contacting Marvin to check if he can lead by phone, or whether someone else (Marty) can lead in person. Information services: no person leading this work within OGSA-WG at the moment. (It is also identified as a 'hole' in the MS paper.) Security: Frank has a clash for both the weeks of April 3rd and April 10th. Takuya can lead the session and is talking with Frank on work items. The location and dates are still unconfirmed. Agreed to a survey and to check the results at the next Monday call. Action: Hiro to do a survey for the F2F location and dates. - Simple format: date and location pairs and a yes/no choice - 3 locations: East coast, West coast, UK (London) - 2 dates: April 4-7 or April 10-11 (avoid Good Friday) * Document status ** WSRF BP 1.0 document update: - Tom is not present; postponed for Wed. ** OGSA 1.5: - Received update from Dave Berry - Waiting for Andreas' final edits - Aim for final version by Wednesday's call. ** Other - Jem has updated the Wikipedia entry for 'OGSA' - The OGSA-WG front page and the GGF information pages also need updating since some of the text is very old. * Teleconf plan review - Keep March 8 to review Information Modeling guidelines document (Fred) - Move other Information modeling documents to March 27 - Delete security from March 8 - The week before GGF is Golden week (Japan holiday) so neither Hiro nor Andreas not available. The schedule is now open. It it is necessary to have calls, Tom may chair these. - Hiro will upload the revised schedule to the list.

1 0

New OGSA-HPC design team - Call for Participation
by Hiro Kishimoto 24 Feb '06

24 Feb '06

Hi all, At the GGF16 OGSA-WG F2F meeting on Friday, we have discussed and agreed to form new OGSA-HPC design team. This design team will focus on the following; 1. Refine and analyze the HPC job submission use case (input from the existing one and other sources, including whether it covers the necessary functionality); and 2. Review existing specs; and 3a. If new specs are needed then launch activities to define the needed specifications; otherwise 3b. Try doing such a vertical profile possibly in a different WG. OGSA-HPC design team is open for everyone and will use OGSA-WG mailing list the same as the other design teams. If you are interested in this design team, please contact Marvin <theimer(a)microsoft.com> or me. From the F2F minutes. > ACTION: Marvin to start and lead a design team within OGSA-WG to > work on the HPC use case immediately. > - It should be advertised to the OGSA list > - There is an existing use case within OGSA-WG and it should be used > as input. (Ravi's use case from the OGSA UC Tier 2 document, > already sent out to the list.) Other input will also be solicited. > - Allocate time on the ogsa call periodically for a status review > - Potentially do a BOF at GGF17, if the scope is clearly defined by > then > - The design team to be named OGSA-HPC Presentation at F2F meeting (MUST READ); https://forge.gridforum.org/projects/ogsa-wg/document/GGF16-F2F-Evolutionar… Paper proposing "evolutionary vertical design efforts": https://forge.gridforum.org/projects/ogsa-wg/document/An_Evolutionary_Appro… Meeting minutes; https://forge.gridforum.org/projects/ogsa-wg/document/ggf16-f2f-minutes-200… Thanks, -- Hiro Kishimoto

3 3

Teleconference minutes - 22 February 2006
by Andreas Savva 22 Feb '06

22 Feb '06

Attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060222/en/1 ** MONDAY TELECONFERENCE DIAL-IN WILL CHANGE FROM NEXT WEEK ** -- Andreas Savva OGSA Teleconference - 22 February 2006 ====================================== * Participants Andreas Savva (Fujitsu) Jem Treadwell (HP) Takuya Mori (NEC) Fred Maciel (Hitachi) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * Summary of Actions Action: Hiro to announce the new OGSA-HPC design team to the list. Action: Hiro to confirm intentions of the other design teams for F2F time and re-confirm dates. * Minutes of February 8 - approved with no changes * Minutes of GGF16 OGSA session 1 (Round table) - approved with no changes * Minutes of GGF16 OGSA session 2 (Information model) - approved with no changes * Minutes of post-GGF16 F2F - approved with no changes Discussed who should announce the new design team. Agreed that it should be Hiro since he is the co-chair. * F2F Agenda discussion - Confirmed that Information Model design teams wants to meet at the April F2F. - The Security design team has no plans to meet. The week of April 3 also needs re-confirmation since some people have said they may not be able to make it. Action: Hiro to confirm intentions of the other design teams for F2F time and re-confirm dates. * Next calls planning - Information Model design team is working on 3 documents (Fred: 1, Ellen: 2): allocate 2 Wednesday calls - Fred's modelling guidelines tentatively for March 8 - Ellen's documents tentatively for March 22 - Security has no documents in progress. A joint call with OGSA-AuthZ is not being planned at the moment. - No time required until the F2F - Work on the next version of the OGSA Roadmap should start sometime in the near future. But no teleconf time is required until the April F2F. - Monday teleconference dial-in information will change. It will be announced on the next proposed agenda. - Next Monday (Feb 27): No clear agenda items at the moment.

1 0

Agenda for 22 February 2006 (Wednesday) call
by Andreas Savva 22 Feb '06

22 Feb '06

Following is the agenda for OGSA-WG telecon on Feb. 22nd Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: US 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: 0222 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 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060208/en/1 OGSA WSRF BP 1.0 status (Tom) OGSA 1.5 status (Andreas) Agenda bashing 2) GGF16 & F2F review (30) a) Minutes approval (session 1, 2, and F2F) https://forge.gridforum.org/projects/ogsa-wg/document/GGF16-Notes-OGSA-Roun… https://forge.gridforum.org/projects/ogsa-wg/document/GGF16_Info_Model_Sess… https://forge.gridforum.org/projects/ogsa-wg/document/ggf16-f2f-minutes-200… b) Confirm actions and decisions 3) April F2F planning (30) Decide the main topics for the April F2F agenda. Main candidates are: 1) Information Modeling 2) OGSA EMS Scenarios (Ideally the above should include JSDL-WG, BES-WG, *RSS-WG* and CDDLM-WG participants.) Do the following design teams/topics require time? - Data - Naming (WS-Name, WS-Directory etc) - Security The following teams have said they do not plan to meet at this F2F: - OGSA-HPC design team (Marvin cannot make it) Note that at the GGF16 F2F we said: > Went through a series of straw polls, not reproduced here with the > following results: > - A four day meeting > - April, Tuesday-Friday (4/4-7) are the best dates > - San Francisco preferred over London by a small difference > - And many people expressed a desire to reconsider > > - Agreed that the choice of venue should be reconsidered after > fixing the agenda and based on the availability of the people > required by the agenda > > - Agreed to make a final decision by March 6 to allow sufficient > time to book flights etc. and > Consensus (7 against 3) to NOT having a one-day F2F at GGF17. 4) Next call planning (20) ** MONDAY TELECONFERENCE DIAL-IN NUMBERS WILL CHANGE! ** a) Discuss how much teleconf time each design team needs from now to the April F2F 5) Wrap up AOB <NEXT CALL> Feb.27 (Monday): ** OPEN ** -- Andreas Savva Fujitsu Laboratories Ltd

2 1

Post-GGF16 F2F minutes (17 Feb 2006) uploaded
by Andreas Savva 22 Feb '06

22 Feb '06

I have uploaded the minutes for the one day meeting after GGF16. These include but are not limited to the discussion on the HPC Grid profile proposal. Major topics: * CDDLM joint discussion * Proposal for HPC Grid Profile * Information Services * Information model discussion https://forge.gridforum.org/projects/ogsa-wg/document/ggf16-f2f-minutes-200… (PS. F2F participants have seen and commented on an early draft. Some changes and additions have been made since.) -- Andreas Savva Fujitsu Laboratories Ltd OGSA Interim Meeting (GGF16) ============================ Location: NTUA, Athens, Greece Date: 17 February 2006 * Participants Dave Berry (NeSC) Keisuke Fukui (Fujitsu) Hiro Kishimoto (Fujitsu) Steve Loughran (HP) Fred Maciel (Hitachi) Steve McGough (IC) Dejan Milojicic (HP) Mark Morgan (UVa) Takuya Mori (NEC) Steven Newhouse (OMII) Darren Pulsipher (Ovoca) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ellen Stokes (IBM) Ravi Subramaniam (Intel) Marvin Theimer (Microsoft) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva (text also contributed by Jem Treadwell) * Summary of Actions [For more details and context see the body of the minutes] 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 ACTION: Tom and Andreas to discuss the April F2F agenda at the next call ACTION: Hiro to launch a survey (Zoomerang) for location after the agenda is set. ACTION: Marvin to start and lead a design team within OGSA-WG to work on the HPC use case immediately. - It should be advertised to the OGSA list - There is an existing use case within OGSA-WG and it should be used as input. (Ravi's use case from the OGSA UC Tier 2 document, already sent out to the list.) Other input will also be solicited. - Allocate time on the OGSA call periodically for a status review - Potentially do a BOF at GGF17, if the scope is clearly defined by then - The design team to be named OGSA-HPC ACTION: Hiro to send mail to GIN group and cc OGSA-WG. ACTION: Ellen and Fred to do a document draft that includes - JSDL-CIM mapping - resource container attribute mapping - relationship table in CIM - And to be reviewed by various people (Steven N, Darren, etc) - It would also be really useful (perhaps at a later point) to also show the correspondence of GLUE with the above. * CDDLM joint discussion A JSDL BLAST example was posted to the list prior to GGF16. Steve Loughran introduced a CDL example 'corresponding' to the JSDL one. This immediately raised a number of questions on the approach taken: - What should the correspondence or relation between a JSDL and CDL document? One could encapsulate the other; or there could be a reference relation. - What is the added value of using CDL? There is not much point in simply duplicating the functions in the JSDL document. It was agreed that the CDL document should not just reproduce the JSDL document but it should instead provide a more detailed description of what needs to be set up to make it possible to run the job described by the JSDL document. - In part this is drawing the line between the deployment and provisioning. - As a general approach it was also agreed out that we should aim for a relation such that 'moving the line' between deployment/provisioning should not affect the contents of JSDL and CDL documents. (There was also a repeat of the Sunnyvale (Jan 2006) discussion. That is whether configuration actions should be done implicitly by the container vs making them explicit. Re-affirmed the consensus that configurations actions should be made explicit.) How close is CDL to be a declarative vs procedural language? Agreed that it can probably be used either way, but with a preference towards a declarative use for OGSA purposes. Proposal to work out details in a smaller group with people from the various groups (JSDL, BES, CDDLM) before bringing it back for an architecture review. - Accepted in principle, but was put aside in favor of the following action. 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 ** Whiteboard list produced during the discussion - Duplication of JSDL in CDL? - Directory/user creation - What is the difference between [job / application / container] configuration] - Where is line between JSDL and CDL and is it policy specific - Job lifecycle including deployment and start/stop * Next Meeting discussion ** Interim Meeting at GGF17 Discussed options for a Monday, Tuesday or Saturday F2F. Or a combination of the above. Since there is an April F2F also planned it was felt that spending more time at this point would not be productive. Consensus (7 against 3) to NOT having a one-day F2F at GGF17. ** April Meeting Went through a series of straw polls, not reproduced here with the following results: - A four day meeting - April, Tuesday-Friday (4/4-7) are the best dates - San Francisco preferred over London by a small difference - And many people expressed a desire to reconsider - Agreed that the choice of venue should be reconsidered after fixing the agenda and based on the availability of the people required by the agenda - Agreed to make a final decision by March 6 to allow sufficient time to book flights etc. ** Teleconferences - No Monday call - Wednesday call to set agenda for April F2F ACTION: Tom and Andreas to discuss the April F2F agenda at the next call ACTION: Hiro to launch a survey (Zoomerang) for location after the agenda is set. * Proposal for HPC Grid Profile Proposal is for "vertical profiles" in addition to current (horizontal) work. Described in a document that was sent out to the list. - Main scenario: Remotely executing a program on a compute resource - Avoid more complex functionality such as provisioning and ... - Use non-controversial specs (defer discussion on WSRF vs WS-I; WSDM vs WS-Man) Proposal discusses 1) design principles of how to build things up 2) the contents of what should be built - This is a concrete use case. The desire is to see how things already fit but there is no urgency (and no immediate proposal) to go off and change the architecture. - What is a non-controversial spec? The basic idea is to built on what is stable. (It was pointed out that the Profile Definition goes into some detail on these definitions and should be used as a measuring rod.) - There has been a lot of horizontal work. This kind of vertical work is a way to validate the horizontal work ('close the design loop'). Probably/hopefully all the specs that are needed are available; otherwise things become much more complicated. - Doing this kind of vertical work might cause some re-design of the initial factoring. And a number of iteration are probably necessary. (In any case the vertical work should be implemented and tried out before iterating further.) - It was also pointed out that the OGSA documents 'big picture' includes this kind of iterative process. - The iteration cycle should be relatively short to keep the work current. - OGSA does not seem to have the expertise in all the various verticals mentioned to define this kind of vertical profiles. - Someone has to do it. And it is not clear if the work should be done inside OGSA or not. - How do these vertical profiles relate to the horizontal ones. For example, how do they evolve together? - The process discussion is an important one but the group should not get too bogged down by that. People are building stuff and will make decisions regardless since they have to ship products. - There is a use case for HPC job submission in the OGSA Use Case Tier 2 document. This was submitted by Ravi S. Discussed whether this should be the basis for moving forward on this topic. - Agreed on a process proposal for moving forward: 1. Refine and analyze the HPC job submission use case (input from the existing one and other sources, including whether it covers the necessary functionality); and 2. Review existing specs; and 3a. If new specs are needed then launch activities to define the needed specifications; otherwise 3b. Try doing such a vertical profile possibly in a different WG. It was re-stated that a profile has to use existing specs (mini specs can be defined on the fly). And that there is a design effort to check whether the necessary functionality is available. This design effort could start as a design team to explore what needs to be done; with the option of starting a new WG once there is a clearer understanding of what pieces exist. The alternative is to divorce completely from OGSA-WG and do this activity separately. But in the latter case there would probably be more discussion within the GFSG on whether such a clearly overlapping effort should be allowed. ACTION: Marvin to start and lead a design team within OGSA-WG to work on the HPC use case immediately. - It should be advertised to the OGSA list - There is an existing use case within OGSA-WG and it should be used as input. (Ravi's use case from the OGSA UC Tier 2 document, already sent out to the list.) Other input will also be solicited. - Allocate time on the ogsa call periodically for a status review - Potentially do a BOF at GGF17, if the scope is clearly defined by then - The design team to be named OGSA-HPC On a side note the WS-Management profile for OGSA was also discussed: - Can there be a WS-Man profile for OGSA at the same level as the WSRF BP and thereby a way to make sure that the multiple basic profiles approach actually works? And could there be Microsoft participation to this? (This work wouldn't go the distance to management (WSDM level) which is more controversial.) - If scoped to a narrow enough domain it might be worth trying; it is difficult to see what it means for doing it for the whole of OGSA. - This is a different issue from the vertical profile proposal but nevertheless an important one. - WS-Man profile: Dave S, Jay and Tom M have an open offer to assist a design team defining this - Missing some experts for individual specs * Information Services Currently no activity in info services. - Steven: There's an activity going on in GIN (Grid Interoperability Now) to identify endpoints - GIN/OMII will develop its own information service - GLUE/CIM-based - Hiro: Any chance we can get them to join our calls? - Steve: Unlikely; we would need to join theirs. - Ravi: Collect info from other documents, such as MDS. - Steven: OMII is going to be very focused on their work for the next six months, and won't have time to write documents to feed back to OGSA. - Dave S: There's an enormous amount we can learn from them - might want to ask for a summary document, one chapter per area. We need to keep Charlie Catlett & Dane Skow informed; ACTION: Hiro to send mail to GIN group and cc OGSA-WG. * RSM license update - Process kinks worked out. - Use the online form to apply. Allow for 3-5 business days for completion. * Information model discussion - A list of use cases as requested at the last GGF session is needed. - Given a data model (right or wrong) can it be mapped to the information model? - Some people agreed (and none disagreed) with the statement that "the JSDL implied model has a mapping to the information model" - A JSDL to information model (CIM) mapping and the relationships in CIM provide a way to 'select' a resource model for bes container. So that a JSDL description can be matched with a container description. ACTION: Ellen and Fred to do a document draft that includes - JSDL-CIM mapping - resource container attribute mapping - relationship table in CIM - And to be reviewed by various people (Steven N, Darren, etc.) - It would also be really useful (perhaps at a later point) to also show the correspondence of GLUE with the above. - There is going to be a GIN information model discussion at GGF17 and Fred & Ellen should plan to attend. * OGSA 1.5 & Glossary update - Documents are close to final call. The Glossary is done, the architecture document needs some minor changes; some to address issues raised during GGF16. - A final call probably sometime next week. - Andreas will put both glossary and architecture into final call - Proposal to make the glossary into a wiki to make it easier for more people to contribute. And freeze occasionally for publication. * OGSA Communication - Agreed to a presentation per capability in addition to a high level presentation. - Presentations should be against published material, not the latest state of the work, to make it easier for people to find additional information.

1 0

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Dave Berry 21 Feb '06

21 Feb '06

Steve, I don't want to have "exciting" GGFs; I just want meetings where we can get some work done. Several developments at GGF16 seemed to be pushing us along, with practical, focussed work on standards & interoperation. The Grid Interoperation Now sessions are one such. The proposal for an OGSA-HPC design is another. I like focussed, incremental steps like these that start from where people are now. Best wishes, Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Steve Loughran Sent: 20 February 2006 15:09 To: Marvin Theimer Cc: ogsa-wg(a)ggf.org; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" 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. > Marv -could you also send out the slides that we saw at the F2F; not everyone on the mail list will have seen them. > > > 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 profiles" that 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 loop" > by 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 efforts" and then focuses on a specific > vertical design effort, namely a minimal HPC design. > > > > The paper derives a specific HPC design in a "first principles" manner > 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. > I don't know whether it was good or bad that the paper didnt surface till after the main GGF was over; I think it could have been a more exciting conference if we had this paper to talk about all week. Regarding the contents, pragmatic and evolutionary are a good way of learning what works, though hill-climbing solutions are always a risk. I do worry about the use of "non-contentious" technologies, because I'd like to see a mention of "stable and broadly implemented" in there too. There are many specs beginning with WS- that, while non contentious, are too unstable to make the underpinnings of anything 'strategic'. I will not name the guilty here; there are too many to choose from. One thing that worries me as someone in a downstream group is this new trend for parallel profiles, the WSDM and the other one. This is not sustainable. Not only does it double the engineering costs of the standards group (double the profiles, tests, docs...), if you split the set of possible interoperable nodes in two, the value of each partition network is reduced to a quarter of that possible, as Metcalfe's law kicks in on the fractions. That was the Corba mistake: not caring enough about interop on the wire. -Steve

1 0

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Maguire_Tom＠emc.com 21 Feb '06

21 Feb '06

Savas, Good to hear from you! What I meant was that 'at the current time' a profile would be classified as informational because of the status of some of the specifications. I expect that most of those specifications will be at Committee Draft before the profile is published. The one sticky point would be WS-Policy. Currently some of the specs reference WS-Policy. Near as I can tell it is not 'yet' in any standards body. Do you know what the plans are there? Thanks, Tom Mobile: +1-845-729-4806 > -----Original Message----- > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > Sent: Tuesday, February 21, 2006 12:47 AM > To: Savas Parastatidis > Cc: Maguire, Tom; Marvin Theimer; ogsa-wg(a)ggf.org; Tony Hey; > humphrey(a)cs.virginia.edu; gcf(a)grids.ucs.indiana.edu > Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design > efforts" > > Hi Savas, > > GFD.59 "OGSA profile definition" prescribes not only "OASIS standard" > but also "OASIS TC Committee Drafts" can be referenced from > Recommended Profile at the Proposed Recommendation stage of > publication. > > However, OGSA-WG agreed to wait for WSRF specs become "OASIS standards" > since it is expected to happen at latest end of March. > > Thanks, > ---- > Hiro Kishimoto > > Savas Parastatidis wrote: > > I am not familiar with GFD-I.59. From your description, is it right to > > assume that even the WS-RF-based profile is going to be informational > > given that WS-RF and related specs were not standards at the time the > > work on the profile started? > > > > -- > > Savas Parastatidis > > http://savas.parastatidis.name > > > > > > > >>-----Original Message----- > >>From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > >>Sent: Monday, February 20, 2006 6:11 PM > >>To: Maguire_Tom(a)emc.com > >>Cc: Marvin Theimer; ogsa-wg(a)ggf.org; Savas Parastatidis; Tony Hey; > >>humphrey(a)cs.virginia.edu; gcf(a)grids.ucs.indiana.edu > >>Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design > >>efforts" > >> > >>Hi Tom, > >> > >>You are absolutely right. If the upcoming HPC profile refers to non- > >>standard spec(s), it should be categorized as "informational." > >>---- > >>Hiro Kishimoto > >> > >>Maguire_Tom(a)emc.com wrote: > >> > >>>I appreciate and agree with the perspective that suggests that OGSA > >>>functionality be profiled using existing agreed upon specifications. > >>>Are you suggesting WS-Security, WS-Trust, WS-SecureConversation, and > >>>WS-ReliableMessaging as those common, agreed upon, non-controversial > >>>specifications? Some of these are at Standard (WS-Security), some > > > > are > > > >>>at committee draft (WS-ReliableMessaging) and some of them are at > >>>editor drafts (WS-Trust, WS-SecureConversation). The GGF guidelines > >>>for OGSA Profile Definition (GFD-I.59) would require that a profile > >>>based on these specifications be classified as an Informational > >>>Profile (given the current state of the specifications). Further I > >>>would like to point out that the normative thorn in the side here > >> > >>continues to be WS-Policy. > >> > >>> > >>>Thanks, > >>>Tom > >>> > >>>Mobile: +1-845-729-4806 > >>> > >>> > >>> > >>> > >>> > >>>________________________________ > >>> > >>> From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > > > > Behalf > > > >>>Of Marvin Theimer > >>> Sent: Thursday, February 16, 2006 8:45 AM > >>> To: ogsa-wg(a)ggf.org > >>> Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty > > > > Humphrey; > > > >>>gcf(a)grids.ucs.indiana.edu > >>> Subject: [ogsa-wg] Paper proposing "evolutionary vertical design > >>>efforts" > >>> > >>> > >>> > >>> 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 profiles" that 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 > > > > loop" > > > >>>by 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 efforts" and then focuses on a specific vertical design > >>>effort, namely a minimal HPC design. > >>> > >>> > >>> > >>> The paper derives a specific HPC design in a "first principles" > >>>manner 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 > >>> > >>> > >>> > >>> > >> > > > > > >

1 0

Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Hiro Kishimoto 21 Feb '06

21 Feb '06

Hi Savas, GFD.59 "OGSA profile definition" prescribes not only "OASIS standard" but also "OASIS TC Committee Drafts" can be referenced from Recommended Profile at the Proposed Recommendation stage of publication. However, OGSA-WG agreed to wait for WSRF specs become "OASIS standards" since it is expected to happen at latest end of March. Thanks, ---- Hiro Kishimoto Savas Parastatidis wrote: > I am not familiar with GFD-I.59. From your description, is it right to > assume that even the WS-RF-based profile is going to be informational > given that WS-RF and related specs were not standards at the time the > work on the profile started? > > -- > Savas Parastatidis > http://savas.parastatidis.name > > > >>-----Original Message----- >>From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] >>Sent: Monday, February 20, 2006 6:11 PM >>To: Maguire_Tom(a)emc.com >>Cc: Marvin Theimer; ogsa-wg(a)ggf.org; Savas Parastatidis; Tony Hey; >>humphrey(a)cs.virginia.edu; gcf(a)grids.ucs.indiana.edu >>Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design >>efforts" >> >>Hi Tom, >> >>You are absolutely right. If the upcoming HPC profile refers to non- >>standard spec(s), it should be categorized as "informational." >>---- >>Hiro Kishimoto >> >>Maguire_Tom(a)emc.com wrote: >> >>>I appreciate and agree with the perspective that suggests that OGSA >>>functionality be profiled using existing agreed upon specifications. >>>Are you suggesting WS-Security, WS-Trust, WS-SecureConversation, and >>>WS-ReliableMessaging as those common, agreed upon, non-controversial >>>specifications? Some of these are at Standard (WS-Security), some > > are > >>>at committee draft (WS-ReliableMessaging) and some of them are at >>>editor drafts (WS-Trust, WS-SecureConversation). The GGF guidelines >>>for OGSA Profile Definition (GFD-I.59) would require that a profile >>>based on these specifications be classified as an Informational >>>Profile (given the current state of the specifications). Further I >>>would like to point out that the normative thorn in the side here >> >>continues to be WS-Policy. >> >>> >>>Thanks, >>>Tom >>> >>>Mobile: +1-845-729-4806 >>> >>> >>> >>> >>> >>>________________________________ >>> >>> From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > > Behalf > >>>Of Marvin Theimer >>> Sent: Thursday, February 16, 2006 8:45 AM >>> To: ogsa-wg(a)ggf.org >>> Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty > > Humphrey; > >>>gcf(a)grids.ucs.indiana.edu >>> Subject: [ogsa-wg] Paper proposing "evolutionary vertical design >>>efforts" >>> >>> >>> >>> 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 profiles" that 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 > > loop" > >>>by 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 efforts" and then focuses on a specific vertical design >>>effort, namely a minimal HPC design. >>> >>> >>> >>> The paper derives a specific HPC design in a "first principles" >>>manner 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 >>> >>> >>> >>> >> > > >

1 0

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Hiro Kishimoto 21 Feb '06

21 Feb '06

Savas' email bounced. -- Hiro Kishimoto Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Date: Mon, 20 Feb 2006 20:52:03 -0800 From: "Savas Parastatidis" <Savas.Parastatidis(a)microsoft.com> I am not familiar with GFD-I.59. From your description, is it right to assume that even the WS-RF-based profile is going to be informational given that WS-RF and related specs were not standards at the time the work on the profile started? -- Savas Parastatidis http://savas.parastatidis.name >> -----Original Message----- >> From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] >> Sent: Monday, February 20, 2006 6:11 PM >> To: Maguire_Tom(a)emc.com >> Cc: Marvin Theimer; ogsa-wg(a)ggf.org; Savas Parastatidis; Tony Hey; >> humphrey(a)cs.virginia.edu; gcf(a)grids.ucs.indiana.edu >> Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design >> efforts" >> >> Hi Tom, >> >> You are absolutely right. If the upcoming HPC profile refers to non- >> standard spec(s), it should be categorized as "informational." >> ---- >> Hiro Kishimoto >> >> Maguire_Tom(a)emc.com wrote: > >>> > I appreciate and agree with the perspective that suggests that OGSA >>> > functionality be profiled using existing agreed upon specifications. >>> > Are you suggesting WS-Security, WS-Trust, WS-SecureConversation, and >>> > WS-ReliableMessaging as those common, agreed upon, non-controversial >>> > specifications? Some of these are at Standard (WS-Security), some are >>> > at committee draft (WS-ReliableMessaging) and some of them are at >>> > editor drafts (WS-Trust, WS-SecureConversation). The GGF guidelines >>> > for OGSA Profile Definition (GFD-I.59) would require that a profile >>> > based on these specifications be classified as an Informational >>> > Profile (given the current state of the specifications). Further I >>> > would like to point out that the normative thorn in the side here > >> continues to be WS-Policy. > >>> > >>> > >>> > Thanks, >>> > Tom >>> > >>> > Mobile: +1-845-729-4806 >>> > >>> > >>> > >>> > > >>=20

1 0

Re: [ogsa-wg] HPC Use Case ....
by Subramaniam, Ravi 21 Feb '06

21 Feb '06

Thanks Hiro! We may need to elborate on or modify the use case as will be needed for this excercise. Fyi: My original intention was to create a list of related use case situations; I have only the first two here (which explains the advanced topics you have mentioned below). As our focus on use cases changed I did not pursue that further. Ravi -----Original Message----- From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] Sent: Mon Feb 20 18:16:49 2006 To: Subramaniam, Ravi Cc: ogsa-wg(a)ggf.org Subject: Re: [ogsa-wg] HPC Use Case .... Hi Ravi, Thanks for your usecase submission. I agree that most of this usecase can be viewed as HPC scenario. Although some of its requirements, e.g. optimization, self-healing, and self-descriptive, may be advanced topics, but they should be discussed by the new OGSA-HPC design team. Also, I've double checked our tier 2 usecase and found that yor usecase is incorporated as its chapter 2. But sections in the chapter are re-ordered to meet usecase template. Thanks, ---- Hiro Kishimoto Subramaniam, Ravi wrote: > Hi, > > > > Based on the discussion on the F2F today, I have an action item to > resend the use case that I submitted to cover the HPC space. This was > first sent Feb, 2003 to OGSA. I had called it infrastructure management > but the first example is a HPC scenario. > > > > We may need to flesh this out and separate the relevant portions into a > new use case definition for the HPC focus activities. > > > > Thanks! > > > > Ravi > >

1 0

HPC Use Case ....
by Subramaniam, Ravi 21 Feb '06

21 Feb '06

Hi, Based on the discussion on the F2F today, I have an action item to resend the use case that I submitted to cover the HPC space. This was first sent Feb, 2003 to OGSA. I had called it infrastructure management but the first example is a HPC scenario. We may need to flesh this out and separate the relevant portions into a new use case definition for the HPC focus activities. Thanks! Ravi

2 1

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Maguire_Tom＠emc.com 21 Feb '06

21 Feb '06

I appreciate and agree with the perspective that suggests that OGSA functionality be profiled using existing agreed upon specifications. Are you suggesting WS-Security, WS-Trust, WS-SecureConversation, and WS-ReliableMessaging as those common, agreed upon, non-controversial specifications? Some of these are at Standard (WS-Security), some are at committee draft (WS-ReliableMessaging) and some of them are at editor drafts (WS-Trust, WS-SecureConversation). The GGF guidelines for OGSA Profile Definition (GFD-I.59) would require that a profile based on these specifications be classified as an Informational Profile (given the current state of the specifications). Further I would like to point out that the normative thorn in the side here continues to be WS-Policy. Thanks, Tom Mobile: +1-845-729-4806 ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Thursday, February 16, 2006 8:45 AM To: ogsa-wg(a)ggf.org Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" 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 profiles" that 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 loop" by 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 efforts" and then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a "first principles" manner 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

3 2

FW: UFCG Demo
by Milojicic, Dejan S (HP Labs) 21 Feb '06

21 Feb '06

Hi Hiro, You asked what was the percentage of the new functionality in the UFCG demo compared to Boston. Please find Ayla's answer. I cc OGSA because of some other participants in the meeting. Thanks, Dejan. ________________________________ From: Ayla Débora [mailto:ayladebora@gmail.com] Sent: Monday, February 13, 2006 6:52 PM To: Milojicic, Dejan S (HP Labs) Cc: Rafaeli, Sandro; Saikoski, Katia (HP Brazil) Subject: Re: UFCG Demo Hi Dejan, Regarding the demo questions, in this demo we have explored notifications, which was not explored in the other one. Besides that, we have also explored deployment in more than a single node, using hostname hints. We have also included in CDDLM Web some other functionalities from CDDLM like the WSRF ones, but I did not include in the demo to avoid making it take more time than that. The version from the demo is also more stable than the previous one and has incorporated adjustments due to CDL changes and new tests that have pointed out misunderstandings. Thanks, Ayla PS: As we are having problems with the UFCG mailing server since Friday, please use this email address to contact me when necessary. On 2/13/06, Milojicic, Dejan S (HP Labs) <dejan.milojicic(a)hp.com> wrote: Thanks Ayla, Demo went well, people liked it (some, in a positive manner suggested that you could have added voice; we did try to fill in the gap by talking to it, but we also did not want to take focus away from the demo itself). Hiro asked, percentage-wise, how much was the demo different from the one you gave in Boston. I answered that it was not much different functionality-wise, but that it was much different wrt stability and completeness. Do you have any different answer that I can provide to him? Thank, Dejan. ________________________________ From: Ayla Débora [mailto:ayladebora@gmail.com] Sent: Sunday, February 12, 2006 4:16 PM To: Milojicic, Dejan S (HP Labs) Subject: Re: UFCG Demo Hi Dejan, I'm glad you liked it. We are still planning the OVUA submission, but maybe I'll only be able to send you a version probably on Wednesday because we took more time than expected to make the architectural changes in our implementation to make paralelism work as expected and to prepare the demo. Thanks and have a nice time in Athens, Ayla On 2/12/06, Milojicic, Dejan S (HP Labs) <dejan.milojicic(a)hp.com> wrote: Hi Ayla, G ot it and ran it. It is excellent. Thanks, Dejan. PS Are you still planning the OVUA submission. If so, and if interested, you can send to me the version of the paper for review, although I might be busy with the conference. However, I would do my best to provide some feedback at minimum. ________________________________ From: Ayla Débora [mailto:ayladebora@gmail.com] Sent: Saturday, February 11, 2006 4:13 PM To: Milojicic, Dejan S (HP Labs) Subject: UFCG Demo Hi Dejan, sorry for the delay. I just finished now the presentation. Please let me know if you want me to make any changes to the text or if you have any doubts or suggestions. I've generated a flash presentation that can be downloaded from: http://www.lsd.ufcg.edu.br/~ayla/cddlm/ufcg_demo.zip <http://www.lsd.ufcg.edu.br/%7Eayla/cddlm/ufcg_demo.zip> . For the presentation, you will need a browser with a Flash plugin. Please confirm when you download the file. Thanks, Ayla

2 1

Paper proposing "evolutionary vertical design efforts"
by Marvin Theimer 20 Feb '06

20 Feb '06

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 profiles" that 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 loop" by 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 efforts" and then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a "first principles" manner 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

3 3

Re: [ogsa-wg] INFO a hole???
by Hiro Kishimoto 20 Feb '06

20 Feb '06

Dieter's email bounced. -- Hiro Kishimoto Subject: Re: [ogsa-wg] INFO a hole??? Date: Mon, 20 Feb 2006 01:38:03 -0800 From: Dieter Gawlick <dieter.gawlick(a)oracle.com> Andreas, Please go to the INFOD website and look at the GGF16 folder.There you will find specifications and use cases which include patterns. When you look at the INFOD presentation at GGF16 you we see that the group plans a major cleanup of the interfaces in two months time. I think that OGSA has to look much more closely into the implications moving towards a /push world/. Some of the basics are well understood, e.g., those aspects captured in WS-Notification. But there is much, much more. For starters, I would highly recommend to look closely into the INFOD mechanism of matching publishers and consumers. It is quite sophisticated and seems to capture some difficult tasks that we tend to leave to developer as an implementation exercise. The current specifications reflect only step one of INFOD; OGSA members should also try to become familiar with what we intend to add later. Doing so, could provide significant guidance for some areas, i.e., data movement and transactions. Dieter Andreas Savva wrote: >>>>The INFOD spec has been simplified significantly - or rather we have >>>>decided to concentrate on a base specification before moving on to >>>>more advanced features. We plan to have the base spec going for public >>>> >>>> > >> >>Could you also post the reference to the INFOD specification(s)? Also >>references to any other material describing the more advanced features >>you expect to work on in the future would be nice. >> >>Abdeslem in his revision to the information services section for OGSA >>1.5 added mentions of INFOD and I would like to have a reference to a >>specification, even if an early working group draft. I would also like >>to understand better the potential role of INFOD. >> >>-- >>Andreas Savva >> >>Steve Fisher wrote: >> >> > >>>>Hi, >>>> >>>>I have heard a number of people complaining this week, at GGF, that >>>>"Information is a hole". It was also on the slides shown by Dave >>>>Snelling on Thursday morning. >>>> >>>>Previously Abdeslem Djaoui liaised between the INFOD-WG and OGSA-WG >>>>but now we have no direct means of communication and I suspect that >>>>some people in OGSA have not completely understood the potential role >>>>of INFOD, nor is INFOD sure of the size or shape of the hole it might >>>>fill within OGSA. >>>> >>>>The INFOD spec has been simplified significantly - or rather we have >>>>decided to concentrate on a base specification before moving on to >>>>more advanced features. We plan to have the base spec going for public >>>>comment in June, but it would obviously be better to understand very >>>>soon how it fits in to the big picture - to avoid having a >>>>specification which does not meet the perceived OGSA needs. How do you >>>>suggest we move forward? >>>> >>>>Steve >>>> >>>> >>>>

1 0

INFO a hole???
by Steve Fisher 20 Feb '06

20 Feb '06

Hi, I have heard a number of people complaining this week, at GGF, that "Information is a hole". It was also on the slides shown by Dave Snelling on Thursday morning. Previously Abdeslem Djaoui liaised between the INFOD-WG and OGSA-WG but now we have no direct means of communication and I suspect that some people in OGSA have not completely understood the potential role of INFOD, nor is INFOD sure of the size or shape of the hole it might fill within OGSA. The INFOD spec has been simplified significantly - or rather we have decided to concentrate on a base specification before moving on to more advanced features. We plan to have the base spec going for public comment in June, but it would obviously be better to understand very soon how it fits in to the big picture - to avoid having a specification which does not meet the perceived OGSA needs. How do you suggest we move forward? Steve

3 2

No monday call on Feb. 20th
by Hiro Kishimoto 19 Feb '06

19 Feb '06

Hi all, Thank you very much for all of you who came to GGF16 and our F2F meeting in Achenes. We have had very lively and productive meetings. Since this Monday is US national holiday, we won't have conf call on Feb. 20th. We will have Wednesday call and Tom and Andreas will chair this call. Thanks again, -- Hiro Kishimoto

1 0

RE: [ogsa-wg] INFO a hole???
by Fred Maciel 17 Feb '06

17 Feb '06

Hi All, > > I have heard a number of people complaining this week, at GGF, that > > "Information is a hole". It was also on the slides shown by Dave > > Snelling on Thursday morning. Hmm, I think that the total "number of people complaining" was me, Dr. Maciel, Frederico, and Mr. Buchholz. (Read the signature in the end of this e-mail or else you won't get the joke :-). I have used the strong expression "black hole" to say that the information services part of OGSA is very important, concrete work on it is more and more needed, but there is nobody working on it. I was not complaining (sorry if I sent the wrong nuance), but I've been quite vocal about it since the lack of work on this important area of OGSA is making me uneasy. >From Hiro: > We believe we do not underestimate role and importance of INFOD. > However, from our OGSA architecture point of view, information > service should also cover higher level services, e.g. discovery, > directory, and registory which will use INFOD for their > transport means. Yes, all this with a *lot* of scalability -- think 10 thousand nodes. I remember Abdeslem saying that there are a number of existing systems and a lot of experience on this area, and the OGSA-WG needs somebody to bring us this experience. (I have tried to follow the INFOD work, but clashes in GGF sessions and lack of bandwidth have prevented me from doing it.) > We are more than happy to talk with INFOD folks on how to fit > your work > in OGSA architecture. We would very much appreciate if you or your > colleage could take care of these higher level information services in > addtion to INFOD? Ditto. Regards, Dr. Frederico Buchholz Maciel Hitachi America R&D

1 0

Friday F2F logistics
by Hiro Kishimoto 16 Feb '06

16 Feb '06

Hi all, The following is the logistics information for OGSA-WG F2F meeting. Location: National Technical University of Athens Zografou Campus, Iroon Polytexneiou 9, 15780 Zografou Multimedia Ampitheatre, the library building ground floor February 17, Friday 9am-5pm Direction from Divani Caravel Hotel: We will meet at hotel lobby 8:30am and take taxi to NTUA. It will take 20-25 minutes depending on traffic. In case you prefer to use public transportation (it will take 30-45 minutes): From “Evangelismos” station near by hotel, take line 3 metro to “Katehaki” station (4th stop). From “Katehaki” station, take bus number 242 to NTUA Administration Building. Bus departs 15 and 45 every hour from Metro station. Library building is the next to the Administration Building. The campus map and information on getting there. http://www.ntua.gr/en_ntua/campus.htm This is an external view of the building where the room is. http://www.ntua.gr/en_ntua/pages/empn02_jpg.htm Proposed meeting agenda is uploaded to the GridForge: https://forge.gridforum.org/projects/ogsa-wg/document/GGF16-B2B-F2F-schedul… Thanks, -- Hiro Kishimoto

1 1

Dial in information change
by Hiro Kishimoto 15 Feb '06

15 Feb '06

Hi all, Since GGF17 meeting room needs special set-up for conference call, we need to change dial-in info for Wednesday call. Time and date are the same, but please use the following dial-in: Toll number: +1 718 3541071 (New York) +1 408 9616509 (San Jose) +81 (0)3 3570 8225 (Tokyo) +44 (0)207 3655269 (London) The pass code: 4371991 Thanks and talk to you soon, ----- Hiro Kishimoto

2 1

Information model presentation
by Fred Maciel 15 Feb '06

15 Feb '06

Hi, This is the presentation on information models being done in GGF16 (attached file). Regards, Fred Maciel

1 0

URLs for OGSA info model session: BES profile and container model
by Ellen Stokes 15 Feb '06

15 Feb '06

https://forge.gridforum.org/projects/ogsa-wg/document/GGF16_OGSA_container_… https://forge.gridforum.org/projects/ogsa-wg/document/GGF16_BES_Profile_-_I… Ellen Stokes STSM, Grid Computing TC Member, IBM Academy of Technology Austin, Texas tl 678 0552 outside +1 512 838 0552 stokese(a)us.ibm.com

1 0

OGSA-WG Information Modeling session -- dial-in number
by Fred Maciel 14 Feb '06

14 Feb '06

Hi again, > As the second session of the OGSA-WG in GGF16 we will be > continuing > our discussion on information modeling. It's on Wednesday the 15th, at > 1:30 pm, on the Mycenae room. Here is the dial-in number for the session. It's an US number (sorry). Dial-in: Toll Free: +1 (888) 422-7120 International Access: +1 (608) 250-0194 Participant code: 693305 See you there, Fred Maciel Hitachi America R&D

1 0

OGSA round table panel "Working with OGSA"
by Hiro Kishimoto 13 Feb '06

13 Feb '06

Hi all, OGSA-WG will hold "Working with OGSA" round table panel this afternoon. Please stop by Olympia A Room and join to this panel. Date: Monday 13th February Time: 1:30 - 3:00pm Venue: Olympia A Room "OGSA is the flagship architecture of GGF and one of its most active WGs. It has published a number of documents and more are in the pipeline. A number of fellow WGs are also busy refining parts of the architecture. But perhaps in some ways the group, its activities, and aims are a black box to many people in GGF. To bridge this communication gap this panel will explore the experiences of people working with OGSA; the expectations of people wishing to work with OGSA; as well as attempt to shed more light on the group's activities and objectives." Modelator: Malcolm Atkinson (University of Edinburgh) Panelist: JSDL (Steve McGough/Ali Anjomshoaa) OMII/BES (Steven Newhouse) Microsoft (Marvin Theimer) Nortel (Franco Travostino) OGSA-WG (Andrew Grimshaw) Agenda: 1:30 - 1:40 Welcome and OGSA update - Hiro Kishimoto 1:40 - 2:30 Position statement by Panelists (5-10 minutes each) 2:30 - 3:00 Open questions and discussions led by Malcolm Thanks, ---- Hiro Kishimoto

1 0

Please come to the OGSA-WG Information Modeling session
by Fred Maciel 12 Feb '06

12 Feb '06

Hi all, As the second session of the OGSA-WG in GGF16 we will be continuing our discussion on information modeling. It's on Wednesday the 15th, at 1:30 pm, on the Mycenae room. We will review the information model for the container, so I'd like to ask the participation of people who are interested in this activity on the execution management design team and on the OGSA-BES-WG. Also, we will be discussing future steps and what information models we will be developing after the one for the container. We could target data or resource selection, so I'd like to ask also the participation people on the OGSA-D-WG and OGSA-RSS-WG who are interested in this activity. Information models are not part of the charter of your WGs and do not affect your specs, but the development of information models in the OGSA-WG's resource management design team needs the requirements and feedback of the area experts of the GGF, that is, people who participate in your WGs. BTW, I'm not cross-posting since I think that all interested people are in the OGSA-WG mailing list, but feel free to coss-post to other mailing lists if you find appropriate. By the way, I'll be talking about the modeling guidelines document, which describes the process by which we develop the models. The latest version can always be found at the URL above, and I'm looking for your feedback: http://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guidelines /en/ See you there, Fred Maciel

1 0

IBM RSM academic/SDO license
by Hiro Kishimoto 11 Feb '06

11 Feb '06

Hi all, I am very happy to announce that Ellen Stokes and Mike Baskey did a GREAT job and closed the loop on licensing procedure. Many thanks Ellen and Mike! GGF is now on the list of standards organizations for the IBM RSM academic/SDO license (so folks can have access to the applications such as the Rational tools OGSA decided to use for info modeling and EMS sequence diagrams). Ellen has her name added to the approver list to shorten the approval time. For people to request access, this is what they need to do.... 1. go to www.ibm.com/university 2. On the right side of the web page under the membership box there is a link called 'apply now' 3. Click that link. 4. To be able to request access, you first need a userid and password....so if you don't have a universal IBM userid and password click on the link labeled 'register' and follow the instructions. 5. Once you have userid and password (or if you already have one), then you need to click on the link labeled 'step 2' to create an academic initiative membership by completing the membership application....follow the instructions after you click on that link. In the application form make sure you indicate that you are requesting this for GGF usage. 6. Once you submit the application, Ellen will be notified shortly thereafter to approve (and there is a backup to approve if she is not around), and once approved, you will receive approval notice and instructions on how to obtain the Rational tools. Thanks again, ---- Hiro Kishimoto

1 0

JSDL Workshop at GGF16
by Ali Anjomshoaa 10 Feb '06

10 Feb '06

Dear colleagues, [My apologies for cross-posting] Just a quick announcement of the JSDL-WG Workshop at GGF16. Date: Wed. 15th Feb. Time: 08:30 - 12:00 Room: Mycenae The talks are in the schedule below. We all look forward to seeing you there and to your feedback and contributions towards our ongoing work in the JSDL-WG. Kind regards, Ali (on behalf of the JSDL-WG) JSDL-WG: https://forge.gridforum.org/projects/jsdl-wg/ JSDL-Spec: http://www.gridforum.org/documents/GFD.56.pdf -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali(a)epcc.ed.ac.uk Edinburgh, EH9 3JZ Phone: + 44 (0) 131 650 5818 United Kingdom Fax: + 44 (0) 131 650 6555 ------------------------------------------------------------- ---- GGF16, JSDL Workshop Schedule ---- 08:30 - Welcome and Introductions 08:35 - JSDL Tutorial Andreas Savva (Fujitsu Laboratories Ltd, Japan) Steve McGough (LeSC, Imperial College London, UK) William Lee (Lesc, Imperial College London, UK) 09:20 - GridSAM presentation William Lee, (LeSC, Imperial College London, UK) 09:40 - NAREGI presentation Kazushige Saga (National Institute of Informatics, Japan) 10:00 - *** BREAK *** 10:30 - HPCEuropa presentation Ariel Oleksiak (Poznan Supercomputing and Networking Centre, Poland) 10:50 - Japan Business Grid presentation Andreas Savva (Fujitsu Laboratories Ltd, Japan) 11:10 - UniGrids presentation Michel Drescher (Fujitsu Laboratories of Europe, UK) 11:30 - Platform Computing presentation Christopher Smith (Platform Computing, USA) 11:50 - Conclusions and closing remarks 12:00 - END ----------

1 0

Teleconference minutes - 1 February 2006
by Andreas Savva 10 Feb '06

10 Feb '06

Attached. Also https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060201/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 1 February 2006 ===================================== * Participants Mike Behrens (R2AD) Hiro Kishimoto (FJ) Allen Luniewski (IBM) Fred Maciel (Hitachi) Steve McGough (IC) Dejan Milojicic (HP) Takuya Mori (NEC) Andreas Savva (FJ) Chuck Spitz (CA) Jun Tatemura (NEC) Jem Treadwell (HP) Minutes: Andreas Savva * Summary of Actions Action: Andreas will check Greg's email again and followup with Hiro. Action: - Dejan(CDDLM) to provide a CDL for deploying and configuring BLAST - Steve/Andreas(JSDL) to provide a JSDL document for submitting a BLAST job Action: GGF16 panel followup (see detailed list below) * January F2F (01/19) ByteIO minutes approved with no changes * January 25 minutes approved with no changes * January 30 minutes approved with no changes * Basic security profile - Core and Secure channel - Takuya has issued a final call on the list. - Review and comment by next Monday ** "Status of memo" question to Greg No problem with changing the text, but it is not clear if the title could be changed also. Action: Andreas will check Greg's email again and followup with Hiro. ** WSRF BP 1.0 status - WSRF is entering the process towards becoming an OASIS standard - Tom proposed that the WSRF BP should be re-submitted once the WSRF specs become OASIS standards. - There is another document in the GGF pipeline (ByteIO spec) that uses the WSRF BP normatively. The desire is to publish the WSRF BP some time in advance of the end of the public comment of dependent documents. - Hiro proposed waiting until GGF16 or end of February before re-submission but not longer. (No decisions made.) ** RSM License: no update ** CDDLM discussion Jun sent out slides on CDL before the call and the group reviewed them. ** (2) Example 1: Application Server - 'Component provider' defines the components - And in this case also provides the instance of the component (component in the 'running' state) - 'Component user' in this case might also take on the role of a system provider. In other words, the 'component user' may be composing the system for himself or to provide a service to other users - There are some issues with terminology (but perhaps it is unavoidable). - Boundaries here are the components and the roles relative to components ** (3) Component description - CDL does not define how to relate configuration and resource parameters - There is also no requirement that such information be present. The interaction or combination is not defined and is probably an open issue that should be addressed by this group. - Some such information may be present as properties for reference purposes - The semantics of configurable parameters are not defined. It is possible to include semantic description in a separate document or as annotations, etc. - Since this level of description is still too abstract, it was proposed to show a concrete example of JSDL and CDL and how the two relate to each other. - Dejan also suggested doing an implementation fest: - Bring together people developing various components and do a 'reality check' by trying to combine the various components of the EMS architecture. (Different from an interoperability test which brings together people developing the same component.) - And do it as a regular event, e.g., at each GGF. - It was pointed out that the purpose of the 'EMS Scenarios' document is to drill down to that level. Doing a real example, e.g., BLAST, for CDL and JSDL could be useful as a next step. - Agreed to work through such an example at the next GGF. Action: - Dejan(CDDLM) to provide a CDL for deploying and configuring BLAST - Steve/Andreas(JSDL) to provide a JSDL document for submitting a BLAST job ** (4) System composition - Text in red are the results of a refinement of the CDL document - The deployment API expects that all the values in a CDL are instantiated by the time the CDL is submitted. There is no statement on how that refinement is done. ** (5) System template The document on the left is a user 'template' (in contrast, in this presentation component provider templates are yellow). This template is an intermediate description of the system and further refinement is shown on the right side. ** (6)-(8) - There was confusion on the objective of this second example, some of it stemming from the introduction of the term 'job'. The example may be seen as setting up a cluster with a DRM. - It is a more complex example, and it was agreed to concentrate first on the simple case described earlier. ** (9) Further Examples - Clarified that the server/machine/linux boxes essentially represent the same things in the slide. * OGSA(tm) EMS Architecture Scenarios - No objections to the proposal to change the name of the document. - Question about meaning of 'policy' appearing in some of the sequence diagrams (Section 2.5 and some of the Appendices). - 'Policy' is a placeholder for now. - The document is still changing and contains internal inconsistencies. * GGF16 Planning ** Panel: Monday 1:30 - 3:00 Discussed possible candidates for the panel: - JSDL: Steve or one of the other JSDL-WG chairs (ok) - EGEE: Steve will make initial contact with people in EGEE (and cc Hiro) - DAIS: Hiro to ask Malcom - Other possible candidates: - Hiro to ask someone from NAREGI (Japan), Globus (Ian) - Steven Newhouse (OMII) - Vendors: who? - Panel Moderator: Hiro to consult Dave S on candidates. - The panel should be at most 5 people, excluding the moderator. - Send proposal to Hiro on how to publicize the panel ** Information model session - Use the teleconf next Wednesday to prepare for the GGF session. ** GGF16 F2F meeting Agenda proposals: - CDDLM and EMS joint session - Other EMS scenarios (including RSS-WG etc) - Information Model - General session - In particular finalize dates/locations for April F2F and GGF17 F2F meeting * GGF17 F2F - Hiro has speculatively reserved a room both Monday and Saturday at the NAREGI office. * April F2F - April 3-7 seems to be the more popular choice at this moment - SF or London are equally popular

1 1

Teleconference minutes - 8 February 2006
by Andreas Savva 09 Feb '06

09 Feb '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060208/en/1 Have a good trip and see you at GGF16. -- Andreas Savva OSGA Teleconference minutes - 8 February 2006 ============================================= * Participants Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Mark Morgan (UVa) Takuya Mori (NEC) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Ravi Subramaniam (Intel) Jem Treadwell (HP) Minutes: Andreas Savva * Summary of Actions Action: Hiro to upload the Profiles to the GGF Editor tracker Action: Hiro will post the panel proposal text to the list and followup with the identified candidates to confirm the final selection. * February 6 minutes approved with no changes * Monday teleconference information (dial-in numbers) will change after GGF16. - Many thanks to HP (Jeffrin) for providing the facilities so far. * Basic security profiles update - Final call finished last Monday - Some minor revisions from Hiro and Jem - Agreed that the profiles can be submitted to the GGF Editor Action: Hiro to upload the Profiles to the GGF Editor tracker * WSRF Basic Profile update - no update * RSM license - Ellen is following up. * Glossary - Data Federation: Accepted 'logical' and added "In OGSA," since this is an OGSA specific definition. - Re-worked definitions for "use case" and "scenarios" merging the two proposals. Jem will upload the document but will not issue a final call. There will be a combined OGSA 1.5 final call (Architecture and Glossary) when Andreas uploads the final version late this week, early next week. * Wikipedia - OGSA entry - Jem has updated the entry (OGSA). The motivation is just to make sure that the correct information is provided in that public forum. More detailed information will be maintained on the GGF site. * GGF16 planning ** Panel discussion - Reviewed Andreas' draft panel description, proposed balance and identified candidates for participants and moderator. - One proposal is to have two moderators, one from industry the other from academia. It is interesting but there was some uncertainty on how well the format would work. - Candidates so far are mostly from academia. Looking for more commercial/industry representatives. Possible candidates: - Tony Hey (MS) - Franco Travostino (Nortel) - David Martin (IBM) - /Someone from Univa/ Action: Hiro will post the panel proposal text to the list and followup with the identified candidates to confirm the final selection. ** Information model session agenda The session will be a working session focusing on the Modeling guidelines (Fred) and the container documents (Ellen) Proposed and accepted that it should be a bottom-up session, starting with the BES container to motivate the more general guidelines discussion---make it clear that the 'guidelines' is based off the process that came up with the container. It should be made very clear that the guidelines are formulated based on work actually done and are not a blue-sky description of an untried process. Expected audience for this session: EMS (mainly) and possibly Data - BES was initially chosen as a candidate since it is a simple(r) component in EMS. Along the same lines of thoughts a likely first candidate in data is the BYTEIO-WG---it deals with files. - It should also be emphasized that the RM design team is not trying to make more work for other WGs. The main work will be done in OGSA; but domain expert collaboration is needed. - A grid view of storage is another candidate (ref. SNIA) * Modeling Guidelines document review There was not sufficient time to review the document in detail. Some comments were to add - information on how to get access to tools (RSM license); - that the process has been used to come up with the BES container model (and is not a blue-sky approach); and - in the introduction that basing the work on CIM is a *proposal* (it is mentioned in the Status section but some people might not look at that section). ** F2F agenda review - Hiro is working to fill in logistical info (location and how to get there) - Agreed to put 'Next F2F' discussion earlier in the agenda. Sometime in the morning is better to make sure that most interested parties are present.

2 1

Proposed agenda for Feb. 8th call
by Hiro Kishimoto 08 Feb '06

08 Feb '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Feb. 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: 0208 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 (Feb. 6th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060206/en/1 OGSA Basic Security Profile final call status (Takuya) IBM RSM academic/SDOs license program update (Jay) Agenda bashing 2) OGSA glossary 1.5 final review (20 min) Jem will lead the last three term definitions. - scenarios, usecase, data federation 3) 2) GGF16 prep (30 min) OGSA round table panel @ Monday > - Panel preparation: no update yet. > - Hiro is looking for participants. > - Proposals for candidates, etc, should be sent to Hiro before the > next call. OGSA back-to-back F2F meeting on Friday - Hiro will send out proposed agenda before the call. Updated attendees list https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-GGF16-GGF17-A… 4) Information model discussion (60 min) > Fred updated the modeling guidelines document. It's starting to take > shape. The latest version can 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. BTW, Ellen will post updates of her documents too. 5) Wrap up AOB <NEXT CALL> GGF16 (Athens): Feb. 13-16 OGSA-WG F2F meeting (NTUA @ Athens): Feb. 17 -- Hiro Kishimoto

1 1

RE: [ogsa-wg] Trackers
by Treadwell, Jem 08 Feb '06

08 Feb '06

Hi Mark, Near the bottom of the left-hand index panel there's an Administration menu, which has a Tracker Admin item. From there you can select your tracker and delete it. - Jem > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Mark Morgan > Sent: Wednesday, February 08, 2006 9:06 AM > To: ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org > Subject: [ogsa-wg] Trackers > > While attempting to learn how to use trackers in Gridforge, I > created one which I wish to delete. How do I do this? I > can't seem to find a delete button anywhere. > > -Mark > > -- > Mark Morgan > Research Scientist > Department of Computer Science > University of Virginia > http://www.cs.virginia.edu > mmm2a(a)virginia.edu > (434) 982-2047 > >

1 0

Trackers
by Mark Morgan 08 Feb '06

08 Feb '06

While attempting to learn how to use trackers in Gridforge, I created one which I wish to delete. How do I do this? I can't seem to find a delete button anywhere. -Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a(a)virginia.edu (434) 982-2047

1 0

RE: [ogsa-wg] Glossary definitions for discussion on Wednesday's telecon
by Subramaniam, Ravi 07 Feb '06

07 Feb '06

Hi Jem, I have added my suggestions for modifications to proposed definitions. Would you be able to include the mods as one input for the Wed discussion? For data federation, I added 'logical integration' I think the word 'contract' for a use case sounds rather too severe :-). My experience seem to suggest that a use case also has environment, goals etc. Please see below for modifications/additions. Ravi a. Data Federation: The logical integration of multiple services or data resources so that they can be accessed as if they were a single service. b. Use case: A use case captures all interactions of an agent or entity with a system and/or its constituents and the expected behavior of the parties as a consequence where such interactions are directed towards and relevant to achieving/meeting a specific explicit goal. Such a capture could also include the environment, context and modes salient to that interaction. c. Scenario: A scenario is a specific sequence or path of interactions from initiation to goal occurring within a particular environment and/or context and defined by a particular mode of usage. A use case may contain multiple scenarios. d. Mode: is a particular functioning condition or arrangement. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Treadwell, Jem Sent: Tuesday, February 07, 2006 8:28 AM To: ogsa-wg Subject: [ogsa-wg] Glossary definitions for discussion on Wednesday's telecon Hi, the three definitions below are the last that are planned for the OGSA Glossary v1.5, and will be discussed on Wednesday's call. Thanks to Andreas for providing the use case and scenario definitions, and to the OGSA-D team for data federation. Please let me know if you have any comments. Thanks, - Jem Data federation: The integration of multiple services or data resources so that they can be accessed as if they were a single service. Use case: A use case captures a contract between the stakeholders of a system about its behavior. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios. OGSA use cases are high-level and described in a casual style. They are not at the level of detail required for a formal requirements analysis but are meant to provide sufficient detail to inform the architectural definition process. Source: "Writing Effective Use Cases," Alistair Cockburn, Addison-Wesley Professional; 1st edition (January 15, 2000) Scenario: A use case scenario contains a sequence of steps showing how their actions and interactions unfold. OGSA scenarios are high-level and described in a casual style. See also use case. Source: "Writing Effective Use Cases," Alistair Cockburn, Addison-Wesley Professional; 1st edition (January 15, 2000) ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com

1 0

Glossary definitions for discussion on Wednesday's telecon
by Treadwell, Jem 07 Feb '06

07 Feb '06

Hi, the three definitions below are the last that are planned for the OGSA Glossary v1.5, and will be discussed on Wednesday's call. Thanks to Andreas for providing the use case and scenario definitions, and to the OGSA-D team for data federation. Please let me know if you have any comments. Thanks, - Jem Data federation: The integration of multiple services or data resources so that they can be accessed as if they were a single service. Use case: A use case captures a contract between the stakeholders of a system about its behavior. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios. OGSA use cases are high-level and described in a casual style. They are not at the level of detail required for a formal requirements analysis but are meant to provide sufficient detail to inform the architectural definition process. Source: "Writing Effective Use Cases," Alistair Cockburn, Addison-Wesley Professional; 1st edition (January 15, 2000) Scenario: A use case scenario contains a sequence of steps showing how their actions and interactions unfold. OGSA scenarios are high-level and described in a casual style. See also use case. Source: "Writing Effective Use Cases," Alistair Cockburn, Addison-Wesley Professional; 1st edition (January 15, 2000) ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com

1 0

Teleconference minutes - 6 February 2006
by Andreas Savva 07 Feb '06

07 Feb '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060206/en/1 -- Andreas Savva OGSA Teleconference Minutes - 6 February 2006 ============================================= * Participants Mike Behrens (R2AD LLC) Dave Berry (NeSC) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (EMC) Takuya Mori (NEC) Andreas Savva (Fujitsu) Jem Treadwell (HP) Minutes: Andreas Savva * Summary of Actions Action: Tom will update the WSRF BP draft and do final call with next Monday as the deadline. Action: Hiro to confirm the consensus on the definition of the AbstractName (unique in space and time) Action: Dave Berry to propose additional (or other) references for Data or DAIS. Action: Andreas to prepare a new draft and issue a final call. The call will probably overlap GGF16 and to be concurrent with the Glossary final call. * February 1 minutes approved with no changes * Basic security profile - final call - Hiro sent out a few minor comments to the list - Jem is planning to read the documents this week * WSRF BP 1.0 status - New draft with some minor edits posted to gridforge. - As discussed briefly on the last call there is a proposal to delay the submission, or at least the publication of this profile, until WSRF becomes an OASIS standard. This is to avoid having to change the profile soon after it is published. - Tom and Hiro conferred with the WSRF TC chair (Dave Snelling) and clarified that when the WSRF specs become OASIS stanards there will be no namespace changes. The only change is in the location where the documents are kept. [So presumably only the references section needs to be updated.] - Proposed and agreed that the WSRF BP should be prepared and submitted for publication; and ask that the GGF Editor not publish it until the WSRF documents are published by OASIS. - In this way the WSRF BP will be assigned a GFD number and other documents now making their way through the GGF pipeline can refer to it in a stable manner. Action: Tom will update the WSRF BP draft and do final call with next Monday as the deadline. * RSM license - no update * GGF16 preparation - Unfortunately Tom cannot attend GGF16 due to work commitments. He will try to call in during the OGSA sessions. - Panel preparation: no update yet. - Hiro is looking for participants. - Proposals for candidates, etc, should be sent to Hiro before the next call. * OGSA 1.5 review Reviewed draft 5 uploaded to gridforge before the call. - Infrastructure: Approved text for Naming (also needs Andrew's review); transactions (with minor changes to references); and workflow. - For the references: In the case of unpublished drafts that have been submitted to a standards body then refer to the WG or TC home page. For example refer to the OASIS WS-TX TC in the case of WS-BusinessActivity. Action: Hiro to confirm the consensus on the definition of the AbstractName (unique in space and time is best effort?) - EMS: Approved deletion of Figure 4 and associated text; changes in terminology to use EPRs; confirmed that 'resource handle' is no longer used and deleted it from the Glossary; change of figure for BLAST job scenario; deletion of PSHS; change in sections in interactions with OGSA (logging). Minor comments: - "WSDM managed resource" and other mentions of WSDM should be cast as examples. - Figure 4: 'configuration' is truncated; check fonts - Data: Approved new text and figures. - Information services: Minor revision to Logging section to highlight persistency. - log aggregation is a topic that some people expected to see discussed in this section. Agreed to leave as future work. - INFOD: requires a document reference - References: Confirmed new style for references for GGF published documents. Yellow highlighted entries need to be double checked using the rule described earlier. - DAIS reference might need update. Action: Dave Berry to propose additional (or other) references for Data or DAIS. Action: Andreas to prepare a new draft and issue a final call. The call will probably overlap GGF16 and to be concurrent with the Glossary final call. * Other business The Data architecture document is nearly ready for an initial full review by the OGSA-WG. Plan to put it on the agenda of a call after GGF.

1 0

Modeling guidelines document -- please review for teleconference on Wednesday
by Fred Maciel 07 Feb '06

07 Feb '06

Hi, I updated the modeling guidelines document. It's starting to take shape. The latest version can 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. BTW, Ellen will post updates of her documents too. Regards, Fred Maciel Hitachi America R&D

1 0

FINAL CALL Document: OGSA Basic Security Profile 1.0 - Core v005 (resend)
by Takuya Mori 06 Feb '06

06 Feb '06

I'm resending the final call message. Please ignore my previous final call message, because there is no voting procedure for GGF documents. (And we don't use the daylight saving time right now.) ---- The final call document for the OGSA Basic Security Profile 1.0 - Core is available for download at the link below. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Please review and positive acknowledge with an email to the mailing list with your comment for submission from the workgroup to the GGF Editor. Please send your comment on the mailing list by Monday, February 6 COB (EST). If your have a negative comment on the profile, please include precise reasons so that we may address any substantive issues you may have prior to submission. Thanks, Takuya

2 1

FINAL CALL Document: OGSA Basic Security Profile 1.0 - Secure Channel v017 (resend)
by Takuya Mori 06 Feb '06

06 Feb '06

I'm resending the final call message. Please ignore my previous final call message, because there is no voting procedure for GGF documents. (And we don't use the daylight saving time right now.) ---- The final call document for the OGSA Basic Security Profile 1.0 - Secure Channel is available for download at the link below. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Please review and positive acknowledge with an email to the mailing list with your comment for submission from the workgroup to the GGF Editor. Please send your comment on the mailing list by Monday, February 6 COB (EST). If your have a negative comment on the profile, please include precise reasons so that we may address any substantive issues you may have prior to submission. Thanks, Takuya

2 1

Proposed agenda for Feb. 6th call
by Hiro Kishimoto 06 Feb '06

06 Feb '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Feb. 6th 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: 0206 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 (Feb. 1st) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060201/en/1 OGSA Basic Security Profile final call status (Takuya) OGSA WSRF BP 1.0 final call status (Tom) IBM RSM academic/SDOs license program update (Jay) Agenda bashing 2) GGF16 prep (30 min) From Feb. 1st minutes: > * GGF16 Planning > ** Panel: Monday 1:30 - 3:00 > > Discussed possible candidates for the panel: > - JSDL: Steve or one of the other JSDL-WG chairs (ok) > - EGEE: Steve will make initial contact with people in EGEE (and cc > Hiro) > - DAIS: Hiro to ask Malcom > - Other possible candidates: > - Hiro to ask someone from NAREGI (Japan), Globus (Ian) > - Steven Newhouse (OMII) > - Vendors: who? > > - Panel Moderator: Hiro to consult Dave S on candidates. > - The panel should be at most 5 people, excluding the moderator. > - Send proposal to Hiro on how to publicize the panel 3) Arch 1.5 final text review (60 min) Andreas uploaded new draft to GridForge. > So here's a new draft (draft 5). It includes changes in Infrastructure, > EMS, Data, among other sections. Thanks, in particular, to Dave Berry > for pointing out a number of places that needed update. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec-1… 4) Wrap up (10 min) AOB <NEXT CALL> Feb. 8 (Wed): Info model, EMS design team GGF16 prep GGF16 (Athens): Feb. 13-16 OGSA-WG F2F meeting (NTUA @ Athens): Feb. 17 -- Hiro Kishimoto

1 0

OGSA 1.5 draft 5
by Andreas Savva 06 Feb '06

06 Feb '06

I don't recall Hiro sending out a proposed agenda for Monday's call but I think "OGSA and Glossary 1.5" review should be on the agenda. So here's a new draft (draft 5). It includes changes in Infrastructure, EMS, Data, among other sections. Thanks, in particular, to Dave Berry for pointing out a number of places that needed update. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec-1… -- Andreas Savva Fujitsu Laboratories Ltd

1 0

DAIS Specifications in Public Comment
by Norman Paton 01 Feb '06

01 Feb '06

The DAIS Specifications have now completed their initial GFSG Review, and have just entered their public comment period; these specifications are a component of the OGSA data architecture, hence this posting. This message is to encourage comments on the specifications. In this context we would welcome (for example): 1. Technical comments on any aspects of the specifications, in terms of their scope, clarity and correctness. 2. Comments from application developers on the suitability of the specifications for their use cases. 3. Comments from organisations that may be interested in implementing the specifications, for evaluation, for use for a specific purpose, or as part of a wider platform. 4. Comments from organisations or communities that might be interested in developing designs, either internally or as part of a standards activity, that extend the WS-DAI specification. 5. Comments on relationships with other OGSA activities. The specifications are available at the following URLs, where comments can be posted. WS-DAI: http://forge.gridforum.org/tracker/index.php?aid=1711 WS-DAIR http://forge.gridforum.org/tracker/index.php?aid=1712 WS-DAIX http://forge.gridforum.org/tracker/index.php?aid=1713 Regards, Norman

1 0

CDDLM CDL examples
by Hiro Kishimoto 01 Feb '06

01 Feb '06

Jun's email bounced. This material is for today's call. ---- Hiro Kishimoto Dear All, Please find the attached PowerPoint slides for today's discussion on CDDLM CDL examples. Best Regards, Jun Tatemura NEC Laboratories America

1 0

Joint CFP - BSN'06 - SOS4CO'06 (Final Circulation)
by gagnon＠soa7.com 01 Feb '06

01 Feb '06

Joint CFP: BSN'06 & SoS4CO'06 Please accept our 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 organizations * Match-making of semantic service descriptions * Negotiating of inter-organizational business processes * 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: Please submit paper via http://elab.njit.edu/bsnsos4co/submit. Workshop proceedings will be published by the IEEE Computer Society, please use the IEEE double-column paper format at ftp://pubftp.computer.org/Press/Outgoing/proceedings/FORMAT.DOC. Papers can be at most 8 pages. 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. 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 -- Extended >> February 12, 2006 Notification to Authors -- February 28, 2006 Response from Authors -- March 3, 2006 Organizers Confirm Program -- March 10, 2006 Author Kit Posted Online -- March 17, 2006 Camera-Ready Papers Due -- March 31, 2006 Organizers Finalize Proceedings -- April 5, 2006 Workshop Day -- June 26, 2006 Enquiries: Please direct all enquires by email to <bsnsos4co AT njit.edu>. Co-Chairs: Stéphane 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 Feb. 1st call
by Hiro Kishimoto 01 Feb '06

01 Feb '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Feb. 1st 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: 0201 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 Byte IO WG F2F minutes approval (Jan. 19am) https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… Telecon minutes approval (if available) OGSA Basic Security Profile final call status (Takuya) OGSA WSRF BP 1.0 final call status (Tom) IBM RSM academic/SDOs license program update (Jay) Agenda bashing 2) CDDLM-WG joint call (40 min) From F2F meeting minutes: > * Summary of CDDLM/ACS joint session > > - Discussed the role of CDL and JSDL, and where they overlap (data > staging). > - Agreed that more information is needed on how to use CDL. Some > examples (simple to complex) would help. > - Proposed action for Dejan: Take a real use case (e.g., gaussian) > and walk through it, highlighting CDL usage. > > - No major change to the overall EMS picture. An initial proposal to > make the BES container responsible for driving the deployment of > new capabilities on itself was rejected. > - JM still orchestrates the deployment (defined by CDL) and > startup of a job (defined by JSDL). > > - More work is needed on Discovery, what properties are advertised > by BES and how those are used by RSS. > - In particular how are already deployed capabilities discovered, > how they are updated after deployment, their lifetime and how > that affects how or when they are advertised. > - Tentative agreement on Jay's statement: > - Deployment is driven by Job management > - Provisioning is driven by policy https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… See also Andrew's notes on gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/cddlm-acs-joint-sessi… 3) EMS discussion (30 min) Continuing discussion on EMS composite roadmap document. Darren has uploaded updated composite roadmap draft (v0.7) https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… 4) GGF16, GGF17, April F2F meeting plan (30 min) OGSA-WG is planning to have F2F meetings back-to-back with GGF16 (Athens) and GGF17 (Tokyo). We are also planning to have interim F2F meeting in April (venue TBD). Please answer the following on-line survey. http://www.zoomerang.com/survey.zgi?p=WEB224YEN4D5Z3 Prep for GGF16 outreach session > - OGSA outreach session; lower attendance last time; considering > options like > - Town hall (asked not to call it that) > - Presentation from projects on what they'd like to see in OGSA > - Or other groups on how their spec combines or not with ogsa > - A panel <CHOICE FORMAT> > - applications? > - ogsa adoption > - working with ogsa <CHOSEN TOPIC> > - JSDL, EGEE, DAIS as initial candidates > - Or ask people to come and ask questions. > > - Need to also have updated presentation material (and keep them up > to date) 5) Wrap up AOB <NEXT CALL> Feb. 6 (Mon): Arch 1.5 final text review, GGF16 prep Feb. 8 (Wed): Info model, EMS design team GGF16 prep GGF16 (Athens): Feb. 13-16 OGSA-WG F2F meeting (NTUA @ Athens): Feb. 17 -- Hiro Kishimoto

2 2

Survey for GGF16, GGF17, and interim F2F in April
by Hiro Kishimoto 01 Feb '06

01 Feb '06

Hi all, and sorry for the cross-posting. As you already know, OGSA-WG is planning to have F2F meetings back-to-back with GGF16 (Athens) and GGF17 (Tokyo). We are also planning to have interim F2F meeting in April (venue TBD). Please let us know your plan for attendance and preference by answering the following on-line survey. http://www.zoomerang.com/survey.zgi?p=WEB224YECBCXZY OGSA-WG will discuss meeting plans at the upcoming weekly call on Monday, Jan. 30th, 4-6pm CST. And hard deadline for this survey is Sunday, Feb. 5th. Thanks, -- Hiro Kishimoto

1 2

FINAL CALL Document: OGSA Basic Security Profile 1.0 - Secure Channel v017
by Takuya Mori 31 Jan '06

31 Jan '06

The final call document for the OGSA Basic Security Profile 1.0 - Secure Channel is available for download at the link below. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Please review and positive acknowledge with an email to the mailing list with your vote (yes or no) for submission from the workgroup to the GGF Editor. Please vote (email) by Monday, February 6 COB (EDT). If your vote is 'no' please include precise comments so that we may address any substantive issues you may have prior to submission. Thanks, Takuya

1 0

FINAL CALL Document: OGSA Basic Security Profile 1.0 - Core v005
by Takuya Mori 31 Jan '06

31 Jan '06

The final call document for the OGSA Basic Security Profile 1.0 - Core is available for download at the link below. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Please review and positive acknowledge with an email to the mailing list with your vote (yes or no) for submission from the workgroup to the GGF Editor. Please vote (email) by Monday, February 6 COB (EDT). If your vote is 'no' please include precise comments so that we may address any substantive issues you may have prior to submission. Thanks, Takuya

1 0

Non-normative text update for section 1.2 of the OGSA WSRF Basic Profile
by Hiro Kishimoto 30 Jan '06

30 Jan '06

Hi all, We've agreed on this revised text at today's call. ---- Hiro Kishimoto 1.2 Relationships to Other Profiles This Profile extends the WS-I Basic Profile 1.1 [WS-I BP 1.1]. As mentioned in section 1.1 of the WS-I Basic Profile 1.1, there are several profiled bindings which should be used in combination with a profile. It is expected that combined claims of conformance with binding-specific profiles will be the norm. All requirements of WS-I BP 1.1 except for section 5 "Service Publication and Discovery" pertain to this Profile. There may be additional profiles in the future that will include discovery functions. This Profile mandates composition with an OGSA Basic Security profile as described in section 8. 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

Non-normative text update for section 1.2 of the OGSA WSRF Basic Profile
by Maguire_Tom＠emc.com 30 Jan '06

30 Jan '06

1.2 Relationships to Other Profiles This Profile extends the WS-I Basic Profile 1.1 [WS-I BP 1.1]. All requirements except for section 5 "Service Publication and Discovery" specified in WS-I BP 1.1 pertain to this Profile. There may be additional profiles in the future that will include discovery functions. This Profile mandates composition with an OGSA Basic Security profile as described in Section 8. Additionally, as mentioned in section 1.1 of the WS-I Basic Profile 1.1, there are several profiled bindings which should be used in combination with a profile. It is expected that combined claims of conformance with binding specific profiles will be the norm. 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

Proposed agenda for Jan. 30th call
by Hiro Kishimoto 30 Jan '06

30 Jan '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Jan. 30th 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: 0130 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) OGSA WSRF BP 1.0 status (Tom) IBM RSM academic/SDOs license program update (Jay) Agenda bashing 2) Basic Security Profiles status review (20 min) Takuya has uploaded revised "secure channel" draft to GridForge https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… He will also upload revised "core" draft before the call. Please read these drafts before the call and discuss if they are ready for final call. 3) F2F meeting minutes approval and action item review (30 min) Andreas has uploaded almost all materials and minutes: https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… aka http://tinyurl.com/cyrvk 4) GGF16, GGF17, April F2F meeting plan (30 min) Hiro will lunch zoomerang survey of these meetings. Update for GGF16 OGSA-WG sessions and B2B F2F meeting. 5) EMS discussion (30 min) Continuing discussion on EMS composite roadmap document. Darren has uploaded updated composite roadmap draft (v0.7) https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… CDDLM-WG joint-call (Feb. 1) prep 6) Wrap up (10 min) AOB <NEXT CALL> Feb. 1 (Wed): CDDLM joint call Feb. 6 (Mon): Arch 1.5 final text review, GGF16 prep Feb. 8 (Wed): Info model, EMS design team GGF16 prep GGF16 (Athens): Feb. 13-16 -- Hiro Kishimoto

2 2

RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Subramaniam, Ravi 30 Jan '06

30 Jan '06

Hi Charles, Thanks for the clarification on the decision. I am not sure why one would have to have policy in the domain of EPS only. As far as I know, policy can be in multiple domains and partitioned at multiple levels and/or hierarchically. This suggests to me that one may partition policy in the CSG domain, EPS domain or any such domain as one chooses. One would expect that these policy frameworks be consistent but I don't see why they need to be concentrated in one place. Second, I don't understand the motivation behind the "redo much of the work". I don't see why this would be the case. It has less to do with the types of services rather than the limitations of implementation. In the case one cannot determine an algorithm that can have distributed decision/processing or if there is some sticky performance metric then one can design a software component that provides both services but leverages the "tight implementation composition" in realizing that algorithm. This again brings me back to the point of software component versus services. Thanks! Ravi -----Original Message----- From: Spitz, Charles F [mailto:Charles.Spitz@ca.com] Sent: Friday, January 27, 2006 1:26 PM To: Subramaniam, Ravi Cc: Andreas Savva; Donal K. Fellows; ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Hi Ravi, The discussion at the F2F regarding the CSG and EPS was along the lines that the EPS needed more information than just a list of handles from the CSG, and would most likely redo much of the work that the CSG had done in putting together the candidate list. In your example below, you're suggesting that the CSG could use "policy, requirements and resource properties and profiles" to generate candidate sets. The sense of the F2F discussion was that policy, etc. is thought to be more in the domain of the EPS. Hence the question about why CSG needs to be a separate service. Thanks, -chuck spitz -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Subramaniam, Ravi Sent: Friday, January 27, 2006 1:56 PM To: Donal K. Fellows; ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Hi, Unfortunately, I missed most if not all of the EMS sessions at the F2F because of alternate commitments that I could not reschedule. This is the first I have seen on the suggestion to remove CSG. I would strongly suggest against dropping the requirement for CSG. When view from the narrow view of HPC the function of EPS and CSG has been traditionally been the scheduler. There is value in this service beyond the execution of jobs when we consider the larger picture of systems management. There are opportunities to build candidate sets using combinations of policy, requirements and resource properties and profiles that go beyond the need for scheduling jobs. Such candidate sets. I also agree with Donal and, based on his reference to Dave, with Dave that this is an important concept and, therefore, by extrapolation a service. This brings me to the larger topics (I don't often speak up in email so please permit me to use my soap box): 1. What is OGSA defining: standard software components or services? The granularity and the separation of concerns that is represented in the concept of SOA does not preclude that services may be combined into a single software component as part of implementation decisions. I see an increased march in OGSA towards the implementation (i.e. software components) view rather than a services view since we had the GFSG direction on being more normative. 2. We are increasing driving toward siloed "implementation" rather than using this opportunity of such a WG to build an architecture that unifies concepts that are more horizontal and integrated. EMS is becoming more HPC, we have little discussion with data. We don't seem to be asking questions like why should BES be worried about data staging when the data team can provide more general schemes for data management whether in a execution container context or otherwise. There are issues that are better and much more simply handled with benefits like late binding by workflows but we seem to ignore that in our current activity. I am *not* finding fault but trying to raise the discussion to finding the "compositional" nature of services and not biasing our thinking with fitting a particular notion of an implementation. 3. Taking too many shortcuts (in the name of progress) will fritter away the unique opportunity that is OGSA and we will be walking the path towards failure like CORBA and DCE before us (both of which had noble goals but focused, from my understanding, more on the software components as defined should interact as opposed to what are the key functional elements and how should these interact/interoperate and be composed). Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Friday, January 27, 2006 4:26 AM To: ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Thanks to Andreas for the notification. Andreas Savva wrote: > Even though there were no RSS-WG representatives at the F2F the EMS > design team also discussed EPS and CSG as part of the EMS Roadmap > session. Two *suggestions* came out of that session and should be > discussed at a future joint call or perhaps during a joint session at > GGF16. I think they fit in the agenda that Donal proposed below. > >>From the minutes: > - Separation of EPS and CSG is not clearly required - suggest to RSS to > remove CSG and let them make the call. And clearly define the added > value of CSG. > - EPS returns an ordered (by policy) list of (Activity Execution > Candidates: <JSDL doc; EPR or path of BES container; rank (optional, > numeric, extensible), CDL, EPR to deployment service, ...>. > > Folder url: > https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&categor y_id=1149&filtertype=basic I think I favour keeping the CSG as an abstract concept; it looks like it will be useful for places in the Data architecture (e.g. it's possibly an abstraction of other things like replica catalogs. Many thanks to Dave Berry for starting me thinking about these things; it helped a lot with understanding the difference between a CSG and an EPS.) It will also be the level at which we describe how to map things down to stuff like WSRF or WS-Transfer, since it stops us from worrying about how to actually splat things over the wire in a portable way (i.e. there are multiple ways of doing it, but writing connectors from one to another isn't hard). Looking at the other issue, that of the Activity Execution Candidates, I rather like much of what is suggested. I'd modify it a bit though: AEC < JSDL BES-EPR QoS Terms < Price Start Time Range[*] End Time Range etc. (extensible) > CDL (I don't know what this will look like, but having it is not a problem at all; probably easier to not require though, since as long as we have extensibility it can go in trivially anyway.) etc. (extensible) > Just putting the score in isn't so helpful (there's no reasonable possibility of examining the provenance of the value) especially since different parties that see the AEC might want to apply different objective functions. In a reverse to things I've said in the past, I don't think we should require the AEC to be implemented as a WS-Agreement template (though one could be contained within it via extensibility) since that imposes some very strong restrictions on how the job is subsequently handled. There probably ought to be provision for the signing of the AEC, since that enables the receiving party to know the identity of the party legally responsible for honouring what will be the basis for a contract. Pricing model must itself be extensible, but lots of useful cases are easily handled through "fixed amount plus <consumption level>*rate". Looking more at https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/ en/1 I see that there are some thoughts on EPS and things more complex than an atomic job. That would require some kind of composite activity description language, the definition of which is outside the scope of the RSS WG. (In many respects, it doesn't alter all that much anyway. It's just a more complex replacement for the JSDL chunk.) Similarly for scheduling parameters or parametric things (well, certainly for sched parms; I don't understand the parametric world quite so well). Anything else I've missed? Donal. [* Or should this be an expression of estimated delay from submission to execution commencement? Sometimes things are best one way, sometimes another. StartTime is good for reservation, StartDelay is good for immediate-execution or conventional batch queues. ]

4 6

Material from F2F meeting (1/16-20) now on gridforge
by Andreas Savva 27 Jan '06

27 Jan '06

All the material I collected during last week's F2F as well as draft minutes are now on gridforge in folder https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… aka http://tinyurl.com/cyrvk If there is anything missing please upload it to this folder or send it to me. Thanks to all volunteer minute takers. -- Andreas Savva Fujitsu Laboratories Ltd

2 1

RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Spitz, Charles F 27 Jan '06

27 Jan '06

Hi Ravi, The discussion at the F2F regarding the CSG and EPS was along the lines that the EPS needed more information than just a list of handles from the CSG, and would most likely redo much of the work that the CSG had done in putting together the candidate list. In your example below, you're suggesting that the CSG could use "policy, requirements and resource properties and profiles" to generate candidate sets. The sense of the F2F discussion was that policy, etc. is thought to be more in the domain of the EPS. Hence the question about why CSG needs to be a separate service. Thanks, -chuck spitz -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Subramaniam, Ravi Sent: Friday, January 27, 2006 1:56 PM To: Donal K. Fellows; ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Hi, Unfortunately, I missed most if not all of the EMS sessions at the F2F because of alternate commitments that I could not reschedule. This is the first I have seen on the suggestion to remove CSG. I would strongly suggest against dropping the requirement for CSG. When view from the narrow view of HPC the function of EPS and CSG has been traditionally been the scheduler. There is value in this service beyond the execution of jobs when we consider the larger picture of systems management. There are opportunities to build candidate sets using combinations of policy, requirements and resource properties and profiles that go beyond the need for scheduling jobs. Such candidate sets. I also agree with Donal and, based on his reference to Dave, with Dave that this is an important concept and, therefore, by extrapolation a service. This brings me to the larger topics (I don't often speak up in email so please permit me to use my soap box): 1. What is OGSA defining: standard software components or services? The granularity and the separation of concerns that is represented in the concept of SOA does not preclude that services may be combined into a single software component as part of implementation decisions. I see an increased march in OGSA towards the implementation (i.e. software components) view rather than a services view since we had the GFSG direction on being more normative. 2. We are increasing driving toward siloed "implementation" rather than using this opportunity of such a WG to build an architecture that unifies concepts that are more horizontal and integrated. EMS is becoming more HPC, we have little discussion with data. We don't seem to be asking questions like why should BES be worried about data staging when the data team can provide more general schemes for data management whether in a execution container context or otherwise. There are issues that are better and much more simply handled with benefits like late binding by workflows but we seem to ignore that in our current activity. I am *not* finding fault but trying to raise the discussion to finding the "compositional" nature of services and not biasing our thinking with fitting a particular notion of an implementation. 3. Taking too many shortcuts (in the name of progress) will fritter away the unique opportunity that is OGSA and we will be walking the path towards failure like CORBA and DCE before us (both of which had noble goals but focused, from my understanding, more on the software components as defined should interact as opposed to what are the key functional elements and how should these interact/interoperate and be composed). Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Friday, January 27, 2006 4:26 AM To: ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Thanks to Andreas for the notification. Andreas Savva wrote: > Even though there were no RSS-WG representatives at the F2F the EMS > design team also discussed EPS and CSG as part of the EMS Roadmap > session. Two *suggestions* came out of that session and should be > discussed at a future joint call or perhaps during a joint session at > GGF16. I think they fit in the agenda that Donal proposed below. > >>From the minutes: > - Separation of EPS and CSG is not clearly required - suggest to RSS to > remove CSG and let them make the call. And clearly define the added > value of CSG. > - EPS returns an ordered (by policy) list of (Activity Execution > Candidates: <JSDL doc; EPR or path of BES container; rank (optional, > numeric, extensible), CDL, EPR to deployment service, ...>. > > Folder url: > https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&categor y_id=1149&filtertype=basic I think I favour keeping the CSG as an abstract concept; it looks like it will be useful for places in the Data architecture (e.g. it's possibly an abstraction of other things like replica catalogs. Many thanks to Dave Berry for starting me thinking about these things; it helped a lot with understanding the difference between a CSG and an EPS.) It will also be the level at which we describe how to map things down to stuff like WSRF or WS-Transfer, since it stops us from worrying about how to actually splat things over the wire in a portable way (i.e. there are multiple ways of doing it, but writing connectors from one to another isn't hard). Looking at the other issue, that of the Activity Execution Candidates, I rather like much of what is suggested. I'd modify it a bit though: AEC < JSDL BES-EPR QoS Terms < Price Start Time Range[*] End Time Range etc. (extensible) > CDL (I don't know what this will look like, but having it is not a problem at all; probably easier to not require though, since as long as we have extensibility it can go in trivially anyway.) etc. (extensible) > Just putting the score in isn't so helpful (there's no reasonable possibility of examining the provenance of the value) especially since different parties that see the AEC might want to apply different objective functions. In a reverse to things I've said in the past, I don't think we should require the AEC to be implemented as a WS-Agreement template (though one could be contained within it via extensibility) since that imposes some very strong restrictions on how the job is subsequently handled. There probably ought to be provision for the signing of the AEC, since that enables the receiving party to know the identity of the party legally responsible for honouring what will be the basis for a contract. Pricing model must itself be extensible, but lots of useful cases are easily handled through "fixed amount plus <consumption level>*rate". Looking more at https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/ en/1 I see that there are some thoughts on EPS and things more complex than an atomic job. That would require some kind of composite activity description language, the definition of which is outside the scope of the RSS WG. (In many respects, it doesn't alter all that much anyway. It's just a more complex replacement for the JSDL chunk.) Similarly for scheduling parameters or parametric things (well, certainly for sched parms; I don't understand the parametric world quite so well). Anything else I've missed? Donal. [* Or should this be an expression of estimated delay from submission to execution commencement? Sometimes things are best one way, sometimes another. StartTime is good for reservation, StartDelay is good for immediate-execution or conventional batch queues. ]

1 0

RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Subramaniam, Ravi 27 Jan '06

27 Jan '06

Hi, Unfortunately, I missed most if not all of the EMS sessions at the F2F because of alternate commitments that I could not reschedule. This is the first I have seen on the suggestion to remove CSG. I would strongly suggest against dropping the requirement for CSG. When view from the narrow view of HPC the function of EPS and CSG has been traditionally been the scheduler. There is value in this service beyond the execution of jobs when we consider the larger picture of systems management. There are opportunities to build candidate sets using combinations of policy, requirements and resource properties and profiles that go beyond the need for scheduling jobs. Such candidate sets. I also agree with Donal and, based on his reference to Dave, with Dave that this is an important concept and, therefore, by extrapolation a service. This brings me to the larger topics (I don't often speak up in email so please permit me to use my soap box): 1. What is OGSA defining: standard software components or services? The granularity and the separation of concerns that is represented in the concept of SOA does not preclude that services may be combined into a single software component as part of implementation decisions. I see an increased march in OGSA towards the implementation (i.e. software components) view rather than a services view since we had the GFSG direction on being more normative. 2. We are increasing driving toward siloed "implementation" rather than using this opportunity of such a WG to build an architecture that unifies concepts that are more horizontal and integrated. EMS is becoming more HPC, we have little discussion with data. We don't seem to be asking questions like why should BES be worried about data staging when the data team can provide more general schemes for data management whether in a execution container context or otherwise. There are issues that are better and much more simply handled with benefits like late binding by workflows but we seem to ignore that in our current activity. I am *not* finding fault but trying to raise the discussion to finding the "compositional" nature of services and not biasing our thinking with fitting a particular notion of an implementation. 3. Taking too many shortcuts (in the name of progress) will fritter away the unique opportunity that is OGSA and we will be walking the path towards failure like CORBA and DCE before us (both of which had noble goals but focused, from my understanding, more on the software components as defined should interact as opposed to what are the key functional elements and how should these interact/interoperate and be composed). Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Friday, January 27, 2006 4:26 AM To: ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Thanks to Andreas for the notification. Andreas Savva wrote: > Even though there were no RSS-WG representatives at the F2F the EMS > design team also discussed EPS and CSG as part of the EMS Roadmap > session. Two *suggestions* came out of that session and should be > discussed at a future joint call or perhaps during a joint session at > GGF16. I think they fit in the agenda that Donal proposed below. > >>From the minutes: > - Separation of EPS and CSG is not clearly required - suggest to RSS to > remove CSG and let them make the call. And clearly define the added > value of CSG. > - EPS returns an ordered (by policy) list of (Activity Execution > Candidates: <JSDL doc; EPR or path of BES container; rank (optional, > numeric, extensible), CDL, EPR to deployment service, ...>. > > Folder url: > https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&categor y_id=1149&filtertype=basic I think I favour keeping the CSG as an abstract concept; it looks like it will be useful for places in the Data architecture (e.g. it's possibly an abstraction of other things like replica catalogs. Many thanks to Dave Berry for starting me thinking about these things; it helped a lot with understanding the difference between a CSG and an EPS.) It will also be the level at which we describe how to map things down to stuff like WSRF or WS-Transfer, since it stops us from worrying about how to actually splat things over the wire in a portable way (i.e. there are multiple ways of doing it, but writing connectors from one to another isn't hard). Looking at the other issue, that of the Activity Execution Candidates, I rather like much of what is suggested. I'd modify it a bit though: AEC < JSDL BES-EPR QoS Terms < Price Start Time Range[*] End Time Range etc. (extensible) > CDL (I don't know what this will look like, but having it is not a problem at all; probably easier to not require though, since as long as we have extensibility it can go in trivially anyway.) etc. (extensible) > Just putting the score in isn't so helpful (there's no reasonable possibility of examining the provenance of the value) especially since different parties that see the AEC might want to apply different objective functions. In a reverse to things I've said in the past, I don't think we should require the AEC to be implemented as a WS-Agreement template (though one could be contained within it via extensibility) since that imposes some very strong restrictions on how the job is subsequently handled. There probably ought to be provision for the signing of the AEC, since that enables the receiving party to know the identity of the party legally responsible for honouring what will be the basis for a contract. Pricing model must itself be extensible, but lots of useful cases are easily handled through "fixed amount plus <consumption level>*rate". Looking more at https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/ en/1 I see that there are some thoughts on EPS and things more complex than an atomic job. That would require some kind of composite activity description language, the definition of which is outside the scope of the RSS WG. (In many respects, it doesn't alter all that much anyway. It's just a more complex replacement for the JSDL chunk.) Similarly for scheduling parameters or parametric things (well, certainly for sched parms; I don't understand the parametric world quite so well). Anything else I've missed? Donal. [* Or should this be an expression of estimated delay from submission to execution commencement? Sometimes things are best one way, sometimes another. StartTime is good for reservation, StartDelay is good for immediate-execution or conventional batch queues. ]

1 0

Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Donal K. Fellows 27 Jan '06

27 Jan '06

Thanks to Andreas for the notification. Andreas Savva wrote: > Even though there were no RSS-WG representatives at the F2F the EMS > design team also discussed EPS and CSG as part of the EMS Roadmap > session. Two *suggestions* came out of that session and should be > discussed at a future joint call or perhaps during a joint session at > GGF16. I think they fit in the agenda that Donal proposed below. > >>From the minutes: > - Separation of EPS and CSG is not clearly required – suggest to RSS to > remove CSG and let them make the call. And clearly define the added > value of CSG. > - EPS returns an ordered (by policy) list of (Activity Execution > Candidates: <JSDL doc; EPR or path of BES container; rank (optional, > numeric, extensible), CDL, EPR to deployment service, ...>. > > Folder url: > https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… I think I favour keeping the CSG as an abstract concept; it looks like it will be useful for places in the Data architecture (e.g. it's possibly an abstraction of other things like replica catalogs. Many thanks to Dave Berry for starting me thinking about these things; it helped a lot with understanding the difference between a CSG and an EPS.) It will also be the level at which we describe how to map things down to stuff like WSRF or WS-Transfer, since it stops us from worrying about how to actually splat things over the wire in a portable way (i.e. there are multiple ways of doing it, but writing connectors from one to another isn't hard). Looking at the other issue, that of the Activity Execution Candidates, I rather like much of what is suggested. I'd modify it a bit though: AEC < JSDL BES-EPR QoS Terms < Price Start Time Range[*] End Time Range etc. (extensible) > CDL (I don't know what this will look like, but having it is not a problem at all; probably easier to not require though, since as long as we have extensibility it can go in trivially anyway.) etc. (extensible) > Just putting the score in isn't so helpful (there's no reasonable possibility of examining the provenance of the value) especially since different parties that see the AEC might want to apply different objective functions. In a reverse to things I've said in the past, I don't think we should require the AEC to be implemented as a WS-Agreement template (though one could be contained within it via extensibility) since that imposes some very strong restrictions on how the job is subsequently handled. There probably ought to be provision for the signing of the AEC, since that enables the receiving party to know the identity of the party legally responsible for honouring what will be the basis for a contract. Pricing model must itself be extensible, but lots of useful cases are easily handled through "fixed amount plus <consumption level>*rate". Looking more at https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/en/1 I see that there are some thoughts on EPS and things more complex than an atomic job. That would require some kind of composite activity description language, the definition of which is outside the scope of the RSS WG. (In many respects, it doesn't alter all that much anyway. It's just a more complex replacement for the JSDL chunk.) Similarly for scheduling parameters or parametric things (well, certainly for sched parms; I don't understand the parametric world quite so well). Anything else I've missed? Donal. [* Or should this be an expression of estimated delay from submission to execution commencement? Sometimes things are best one way, sometimes another. StartTime is good for reservation, StartDelay is good for immediate-execution or conventional batch queues. ]

1 0

security profiles
by Takuya Mori 26 Jan '06

26 Jan '06

Hi All, I have uploaded the sercurity profiles to the grid forge - BSP 1.0 Core https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… - BSP 1.0 Secure Channel https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… And I also updated the referenced standards sheet. https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-referenced-stand… I'd like to review the documents on the teleconference. Thanks, Takuya

2 2

Proposed agenda for Jan. 25 call
by Hiro Kishimoto 25 Jan '06

25 Jan '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Jan. 25th 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: 0125 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. 14 & Jan. 12) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051214/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060112/en/1 Agenda bashing 2) Basic Security Profiles final text review (60 min) Takuya has uploaded final BSPs to GridForge > - BSP 1.0 Core > https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… > > - BSP 1.0 Secure Channel > https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… > > And I also updated the referenced standards sheet. > https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-referenced-stand… > > I'd like to review the documents on the teleconference. If there is no major issue, Takuya will make final call for these profile by January 28 and will submit to GGF Editor February 4th. 3) OGSA WSRF Basic Profile Public Comment review (30 min) Review Toshinori's comment "Use of WS-I Basic Profile 1.1" > In the draft OGSA WSRF Basic Profile, the WS-I Basic Profile 1.1 [WS-I BP 1.1] > is referred to as a base specification of the profile. I have a comment on > it. > > Because the WS-I BP 1.1 does not have protocol binding specification, when using > the WS-I BP 1.1, one of the companion profiles, Simple SOAP Binding Proifle > 1.0 [WS-I SSBP 1.0] (for SOAP over HTTP binding) or Attachments Profile 1.0 > [WS-I AP 1.0] (for MIME binding) should be used. To claim conformance, conformance > claim for either WS-I SSBP 1.0 or WS-I AP 1.0 should be made in addition to > the conformance claim for WS-I BP 1.1. > > It would be helpful for users if such fact is mentioned as a guide at somewhere > in the OGSA WSRF Basic Profile 1.0. https://forge.gridforum.org/forum/forum.php?thread_id=1051&forum_id=575 4) EMS design team discussion (30 min) Continuing discussion on EMS composite roadmap document. 5) Wrap up AOB <NEXT CALL> Jan. 30 (Mon): Review of F2F minutes and action items, GGF16, GGF17, April F2F meeting plan Feb. 1 (Wed): CDDLM joint call Feb. 6 (Mon): Info model & Arch 1.5 final text review Feb. 8 (Wed): EMS design team GGF16 prep GGF16 (Athens): Feb. 13-16 -- Hiro Kishimoto

1 0

NO CALL on Monday
by Hiro Kishimoto 22 Jan '06

22 Jan '06

Hi all, Thank you very much for all of you who came to F2F meeting. We had very lively and productive meetings in Sunnyvale. As we've agreed at F2F meeting, we have NO call on Monday. Our next call is on Wednesday 25th January. Thanks, ---- Hiro Kishimoto

1 0

F2F materials
by Hiro Kishimoto 20 Jan '06

20 Jan '06

Hi Chuck, and et al, Materials for the F2F meeting should be uploaded to the following folder in GridForge. OGSA : Document Manager : Meeting Materials and Minutes : Interim Meetings : 2006 Jan interim https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… At this moment, only four materials are there. The others will be uploaded shortly. Next time, we will upload before meeting. Thanks, -- Hiro Kishimoto

1 0

REFEDS
by Hiro Kishimoto 20 Jan '06

20 Jan '06

Alan's email bounced. -- Hiro Kishimoto From: Alan Sill <Alan.Sill(a)ttu.edu> Subject: REFEDS Date: Thu, 19 Jan 2006 17:02:31 -0600 To: David Chadwick <d.w.chadwick(a)kent.ac.uk> Hi David et al., In response to your question, with no endorsement or criticism implied, see http://www.terena.nl/tech/refeds/ for information regarding the REFEDS initiative. I'm just learning about it myself. (It does include a reference however to eduroam, as we discussed.) I believe there will be further discussion of this topic among others at the next EUGrid PMA meeting (see http://eugridpma.org ). As I mentioned, I believe we need to get buy-in into the AuthZ recharter and goals process as quickly as possible, including formal representation, from such projects as Open Science Grid, the LHC Computing Grid and/or EGEE, PRAGMA, NAREGI, and other communities with an active interest in the authorization area, such as Internet2 and EDUCAUSE. I do not speak for such projects but would like to see them included... and I am excited about this prospect. Best, Alan Alan Sill TIGRE Senior Scientist High Performance Computing Center TTU URL: http://hipcat.net/Projects/tigre ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

Final proposed schedule for OGSA F2F meeting
by Hiro Kishimoto 16 Jan '06

16 Jan '06

Please accept my apologies for cross posting. Attached is the (hopefully) final proposed schedule for upcoming OGSA-WG and fellow WGs F2F meeting in Sunnyvale. The last minutes changes include; - Swap GRAAP and OGSA 1.5 on Tuesday. - Move WS-Management profile to Wed 1:30-2:30pm - Move Information to Monday afternoon, swapping with the EMS roadmap. It is also uploaded to GridForge; https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… See you in Sunnyvale! -- Hiro Kishimoto

2 3

BES container model files for Jan 16 F2F
by Ellen Stokes 16 Jan '06

16 Jan '06

Here's the files for the info model discussion on BES Container / profile. I'll post to the web site later. Ellen

1 0

Modeling guidelines doc uploaded
by Fred Maciel 14 Jan '06

14 Jan '06

Hi, I uploaded the first version of the modeling guidelines document to GridForge. It's still very preliminary. Sorry for the short notice. http://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guidelines /en/ We will review it in the face-to-face, however the objective is to have a high-level discussion if the contents (including tone, section structure, etc.) are progressing in the right direction, and what are the main pieces missing. BTW, most of the contents have already been presented and/or discussed in GGFs or OGSA face-to-face meetings and teleconferences. In the face-to-face we will also review the newer version of the information model for the container and activities, based on what was presented in a recent teleconference. See you soon, Fred Maciel

1 0

RE: [ogsa-wg] Final proposed schedule for OGSA F2F meeting
by Maguire, Tom 13 Jan '06

13 Jan '06

I have had my travel plans changed for me :-(. I will now be attending M-W. I would prefer WS-Man discussion be on Wednesday but I understand if that cannot be.... Tom > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Hiro Kishimoto > Sent: Friday, January 13, 2006 10:44 AM > To: ogsa-wg(a)ggf.org; ogsa-authz(a)ggf.org; Marty Humphrey; > Glenn S. Wasson > Subject: Re: [ogsa-wg] Final proposed schedule for OGSA F2F meeting > > Hi all, > > Ellen Stokes wants to participate WS-management discussion > and asks me to move it from Wed 1:30-2:30pm to Thursday or Friday. > Since Friday does not work for Marty, Thursday is our only option. > > Marty and Glenn: Does Thur 4-5pm still work for both of you? > Alan, Frank, and Takuya: Could you start security session 30 min > earlier on Thur (from 1pm)? > Andrew: You can start naming session from 1:30pm Wed, right? > All: Does anyone object to move WS-management session from > Wed 1:30-2:30pm to Thur 4-5pm? > > If this change is ok for everyone, Thurs schedule will be the > following: > > 8-9am: Byte-IO > 9am-noon: OGSA-data > 1-2pm: OGSA-AuthZ joint > 2-4pm: security > 4-5pm: WS-management > 5-6pm: security (if overflow) > > Please let me know your availability ASAP, thanks, > ---- > Hiro Kishimoto > > Hiro Kishimoto wrote: > > Please accept my apologies for cross posting. > > > > Attached is the (hopefully) final proposed schedule for upcoming > > OGSA-WG and fellow WGs F2F meeting in Sunnyvale. > > > > The last minutes changes include; > > - Swap GRAAP and OGSA 1.5 on Tuesday. > > - Move WS-Management profile to Wed 1:30-2:30pm > > - Move Information to Monday afternoon, swapping with the EMS > > roadmap. > > > > It is also uploaded to GridForge; > > > https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F > > -agenda > > > > > > See you in Sunnyvale! >

3 2

Re: [ogsa-wg] Final proposed schedule for OGSA F2F meeting
by Hiro Kishimoto 13 Jan '06

13 Jan '06

Hi Tom and Ellen, I made a horrible mistake, my bad. Marty can make Tuesday, not Thursday. Let's me try one more time. Is it possible to move WS-management discussion into Tuesday afternoon 1:30-2:30pm? Marty and Glenn: Does Tues 1:30-2:30pm still work for both of you? Andreas and Jem: You can start Arch 1.5 session 1 hour later on Tuesday (from 2:30pm), right? Jim: You can make GRAAP joint session from 3:30pm Tues, right? All: Does anyone object to move WS-management session from Wed 1:30-2:30pm to Tues 1:30-2:30pm? If this change is ok for everyone, Tuesday schedule will be the following: 9am-12:30pm: CDDLM-WG joint call 1:30-2:30pm: WS-management 2:30-3:30pm: Arch & glossary 1.5 3:30-5:30pm: GRAAP-WG joint call Please let me know your availability ASAP, thanks, ---- Hiro Kishimoto Maguire, Tom wrote: > I have had my travel plans changed for me :-( . I will now be attending > M-W. I would prefer WS-Man discussion be on Wednesday but I understand > if that cannot be.... > > Tom > >> -----Original Message----- >> From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto >> Sent: Friday, January 13, 2006 10:44 AM >> To: ogsa-wg(a)ggf.org; ogsa-authz(a)ggf.org; Marty Humphrey; Glenn S. Wasson >> Subject: Re: [ogsa-wg] Final proposed schedule for OGSA F2F meeting >> >> Hi all, >> >> Ellen Stokes wants to participate WS-management discussion and asks me to move it from Wed 1:30-2:30pm to Thursday or Friday. >> Since Friday does not work for Marty, Thursday is our only option. >> >> Marty and Glenn: Does Thur 4-5pm still work for both of you? >> Alan, Frank, and Takuya: Could you start security session 30 min >> earlier on Thur (from 1pm)? >> Andrew: You can start naming session from 1:30pm Wed, right? >> All: Does anyone object to move WS-management session from >> Wed 1:30-2:30pm to Thur 4-5pm? >> >> If this change is ok for everyone, Thurs schedule will be the following: >> >> 8-9am: Byte-IO >> 9am-noon: OGSA-data >> 1-2pm: OGSA-AuthZ joint >> 2-4pm: security >> 4-5pm: WS-management >> 5-6pm: security (if overflow) >> >> Please let me know your availability ASAP, thanks, >> ---- >> Hiro Kishimoto >> >> Hiro Kishimoto wrote: >> >>> Please accept my apologies for cross posting. >>> >>> Attached is the (hopefully) final proposed schedule for upcoming OGSA-WG and fellow WGs F2F meeting in Sunnyvale. >>> >>> The last minutes changes include; >>> - Swap GRAAP and OGSA 1.5 on Tuesday. >>> - Move WS-Management profile to Wed 1:30-2:30pm >>> - Move Information to Monday afternoon, swapping with the EMS >>> roadmap. >>> >>> It is also uploaded to GridForge; >>> >> >> https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F >> >>> -agenda >>> >>> >>> See you in Sunnyvale! >> >> > >

1 0

Last CFP (Submission deadline: 15-01-2006): International Workshop "Dependability Aspects on Data WArehousing and Mining applications" DAWAM 2006 - Vienna, Austria
by Nguyen Manh Tho 13 Jan '06

13 Jan '06

(Apologies for multiple copies due to cross postings. Please send to interested colleagues and students) CALL FOR PAPERS: International Workshop Dependability Aspects on Data WArehousing and Mining applications DAWAM 2006 <http://www.ares-conf.org/?q=dawam> in conjunction with The First International Conference on Availability, Reliability and Security (ARES 2006 <http://www.ifs.tuwien.ac.at/ares2006> ) Overview Nowadays, the rapid growth of information technologies has brought tremendous opportunities for data sharing, integration, and analysis across multiple distributed, heterogeneous data sources. In the past decade, data warehousing and mining are the well-known technologies used for data analysis and knowledge discovery in vast domain of applications. Data mining technology has emerged as a means of identifying patterns and trends from large quantities of data. Data mining has used a data warehousing model of gathering all data into a central site, then running an algorithm against that data. A growing attention has been paid to the study, development and application of data warehousing and mining. Nevertheless, dependability aspects in these applications such as availability, reliability, integrity, privacy, and security issues are still being investigated. For example, in data warehousing applications, privacy considerations may prevent the approach of collecting data into the centralized warehouse because each data source has different privacy policy. Furthermore, the complexity of security increases as different sources of information are combined. Reliable, consistent and trustworthy of information are also significant requirements in data warehousing applications. Data mining has been shown to be beneficial in confronting various types of attacks to computer systems such as fraud detection, intrusion prevention. In some applications, e.g. clinic information system, government management, business competitive information, it is required to apply the mining algorithms without observing the confidential data values thus demands the privacy preservation. There are also many challenging issues that need further investigation in the context of data mining from both privacy and security perspectives such as mining of imbalanced data, bioinformatics data, streaming data, ubiquitous computing data, grid computing data etc. The goals of this workshop are to bring together users, engineers and researchers (from industry and academy) alike to present their recent work, discuss and identify problems, synergize different views of techniques and policies, and brainstorm future research directions on various dependability aspects of data warehousing and data mining applications. We strongly encourage researchers and practitioners with interest in the areas of reliability, availability, privacy and security, databases, data warehousing, data mining, and statistics to submit their experience, and/or research results. Topics related to any of dependability aspects in data warehousing and mining, theory, systems and applications are of interest. These include, but are not limited to the following areas: * Dependability and fault tolerance * High Availability and Disaster Recovery * Survivability of evaluative systems * Reliability and Robustness Issues * Accuracy and reliability of responses * Reliable and Failure Tolerant Business Process Integration * Reliable Event Management and Data Stream Processing * Failure Tolerant and trustworthy Sensor Networks * Highly available data warehouses for business processes integration * Handling different or incompatible formats, and erroneous data * Privacy and security policies and social impact of data mining * Privacy preserving data integration * Access control techniques and secure data models * Encryption & Authentication * Pseudonymization and Encryption * Anonymization and pseudonymization * Trust management, and security * Security in Aggregation and Generalization * User Profile Based Security * Secure multi-party computation * Secondary use of personal data, clinic data, credit record * Fraud and misuse detection * Intrusion detection and tolerance * Data mining applications for terrorist detection * Private queries by a (semi-trusted) third party * Query authentication, logging, auditing, access control and authorization policies The program of the workshop will be a combination of invited talks, paper/poster presentations and discussions. 1. Important Dates Submission Deadline: January, 15th 2006 (Extension !!!) Author Notification: January, 23th 2006 Author Registration: February, 1st 2006 Proceedings Version: February, 1st 2006 2. Submission Guidelines Authors are invited to submit research and application papers in IEEE Computer Society Proceedings Manuscripts style (two columns, single-spaced, including figures and references, using 10 fonts, and number each page). You can confirm the IEEE Computer Society Proceedings Author Guidelines at the following web page: URL: <http://computer.org/cspress/instruct.htm> http://computer.org/cspress/instruct.htm or <http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm> http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm Submission are classified into 3 categories (1) full paper (8 pages), (2) short paper (5 pages), and (3) poster (2 pages) representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Contact author must provide the following information: paper title, authors' names, affiliations, postal address, phone, fax, and e-mail address of the author(s), about 200-250 word abstract, and about five keywords and register at our ARES website: <http://www.ares-conf.org/?q=submission> http://www.ares-conf.org/?q=submission. Prepare your paper in PDF or MS Word file and submit it to our site or send it to the workshop co-chair: Dr. Nguyen Manh Tho, Institute of Software Technology, Vienna University of Technology, via email: tho(a)ifs.tuwien.ac.at Submission of a paper implies that should the paper be accepted, at least one of the authors will register and present the paper in the conference. Accepted papers will be given guidelines in preparing and submitting the final manuscript(s) together with the notification of acceptance. 3. Publication All accepted papers (full and short papers) will be published as ISBN proceedings published by IEEE Computer Society. Based on quality and referee reviews, some papers not suitable for acceptance as full paper will be accepted for presentation at DAWAM 2006 in Poster category and will be also included in the IEEE Proceedings. A selected number of papers will be nominated to be published as special issues in appropriate journals such as Journal of automatic and trusted computing (JoATC). 4. Workshop Organizer Co-chairs Jimmy Huang, Prof. School of Information Technology, York University, Toronto, Ontario Canada M3J 1P3 jhuang(a)yorku.ca Josef Schiefer, Ph.D. Senactive IT-Dienstleistungs GmbH , Phorusgasse 8 A1040 Vienna, Austria josef.schiefer(a)senactive.com Nguyen Manh Tho, Ph.D. (main contact) Institute of Software Technique and Interactive System, Vienna University of Technology , Favoriten strasse 9-11/188 A1040 Vienna, Austria tho(a)ifs.tuwien.ac.at 5. Program Committee Aijun An, York University, Canada Pawan Chowdhary, IBM T J Watson Research Center, USA LiWu Chang, Naval Research Laboratory, USA Josep Domingo-Ferrer, Rovira i Virgili University of Tarragona, Spain Elena Ferrari, University of Insubria at Como, Italy Ulrich Flegel, University of Dortmund, Germany Tyrone Grandison, IBM Almaden Research, USA Jun-Jang (JJ) Jeng, IBM T.J. Watson Research Center, USA Hillol Kargupta, University of Maryland, Baltimore County, USA and Agnik, LLC Zongwei Luo, University of Hong Kong, Hong Kong Taneli Mielikäinen, University of Helsinki, Finland Daniel E. O'Leary, University of Southern California, USA Stanley Oliveira, Embrapa Information Technology, Brazil Arnon Rosenthal, MITRE Corporation, USA Ben Soh, La Trobe University, Australia David Taniar, Monash University, Australia Juan Trujillo, University of Alicante, Spain Vassilios S. Verykios, University of Thessaly, Greece Justin Zhan, University of Ottawa, Canada Sheng Zhong, State University of New York at Buffalo, USA

1 0

Teleconference minutes - 12 January 2006 (ad hoc)
by Andreas Savva 13 Jan '06

13 Jan '06

Minutes of Jan 12 attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060112/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 12 January 2006 ===================================== * Participants Steven Newhouse Jay Unger Hiro Kishimoto Fred Maciel Dejan Milojicic Takuya Mori Andrew Grimshaw (Andreas Savva) 1. Agenda Bashing for F2F * CCDLM & ACS Review deploy and related scenarios (use cases) from the draft EMS Composition Roadmap document. Dejan will only be there for the CCDLM session. Stuart may also be attending. Dejan to confirm. Current work (an informational document) will be based on current specification documents. This will form a basis for a profile document later on in the year. * Provisioning vs. deployment Is there input we should consider from the EGA Reference Model work? Probably. Past discussion raised the requirement of calculating the deployment cost ('walking' the CDL tree). The current CDDLM specs do not support this functionality directly but it is certainly a conceptual possibility. For example, the needed information could be added as 'decorations'. Is it necessary to try and formulate how to calculate the deployment cost? ( E.g., a framework on how to describe costs, etc.) No, it should be sufficient to define interfaces and the format of the returned estimate, possibly including other information such as the confidence in the estimate. Aiming for something simple initially is good to aid adoption. What is the relation between CDL and JSDL? There is some overlap in the functionality of the two specifications (e.g., both can do data staging, JSDL includes some functionality that may look like configuration values, etc) but the motivation and purpose of the two specifications is different. For example, CDL could be used for staging input and output data but that is not the primary intention. Also CDL does not aim to describe the resource constraints of the job; rather specific resource information would be filled in as a result of scheduler/broker/... decisions. (It was restated that CDDLM does *not decide where* to deploy; it is given that information.) So a useful interaction between these specs would be to think of a JSDL description being used, possibly by CSG or EPS, to fill in a CDL description that would then drive the deployment and configuration of the selected resources to prepare the environment for the job to execute. Agreed that more work is needed at the F2F and that there should be a summary presented and the understanding confirmed with the group. In particular it may be worth discussing the CDL and JSDL topic first since it sets the overall nature of the interactions between the various components. Dejan proposed to think of relations between pairs of actors first before trying to generalize and include multiple actors. 2. Adjust F2F schedule Accepted Hiro's proposed agenda changes: - Swap GRAAP and OGSA 1.5 on Tuesday. - Move WS-Management profile to Wed - Move Information to Monday afternoon, swapping with the EMS roadmap.

1 0

[Fwd: [cddlm] meeting schedule update (Re: [ogsa-wg] Ad hoc calls on Jan. 12th)]
by Andreas Savva 12 Jan '06

12 Jan '06

Forwarding since I think Hiro missed sending this to the ogsa-wg ml. Also I think 'Thursday afternoon' should read 'Tuesday afternoon'. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Ad hoc calls on Jan. 12th
by Hiro Kishimoto 11 Jan '06

11 Jan '06

Hi all, We will have an ad hoc call for F2F meeting preparation on Thursday. The following is a proposed agenda. ATTENTION: day of week, time, dial-in number are all different. Date: Jan. 12th Thursday Time: 8-10pm (CST) = 6-8pm (PST) = 11am-1pm JST = 2-4am UK The dial-in number: US Toll number: +1 408-961-6509 (San Jose) and +1 718-354-1071 (New York) UK Toll number: +44 (0)207 365-5269 JP Toll number: +81 (0)3 3570 8183 The pass code: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0112 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. 19) https://forge.gridforum.org/projects/ogsa-wg/document/minutes20051219/en/1 Agenda bashing 2) CDDLM-WG joint call (60 min) Jem has uploaded the revised version to the GridForge. - http://tinyurl.com/aez86 Look forward to proofread and tracker verification. (1) Deployment and configuration section break-down > == Proposed list of sections == > > 3.1 Provision (Deploy) an application on an existing BES container > (The application can then be used to instantiate a BES activity. > Mostly what is now 3.2 in EMS Architecture composition.) > > 3.2 Provision a BES container > (What is now 3.1 in EMS Architecture composition) > > [Both 3.1 and 3.2 assume that the 'level' of the BES container is > pre-determined and fixed. See below.] > > 3.3 Using ACS do 3.1 > > 3.4 Using ACS do 3.2 > > [Both 3.3 and 3.4 assume that the 'level' of the BES container is > pre-determined and fixed. See below.] > > 3.5 Add time predictions to provision 3.1 and 3.2 by a deadline > Using a deployment estimation service (perhaps based on > historical data, etc, but how the estimation is done is > out-of-scope.) Possibly requiring reservations. > > [3.5 assumes that the 'level' of the BES container is pre-determined > and fixed. See below.] > > 3.x Determine dynamically the optimal level of 'BES container' in the > system and provision containers appropriately depending on > workload etc > may depend on analysis of the entire application CDL (down to > hardware) for the entire workload of the system; use > deployment time predictions; etc > > <<Version 1 of the document could just cover scenarios 3.1-3.5 and > discuss 3.x as future work. Otherwise need to breakdown 3.x further.>> > == (2) - Deployment versus provisioning requirements > (Or, where to 'cut' the CDL tree. Above the 'cut' point is > deployment---assumed to be a relatively 'light' operation---and > below is provisioning---assumed to be more heavy-weight.) > - Deciding the cut point is orthogonal to CDDLM---it is policy or > best practices and is therefore a system choice > - Information (metadata) to help in making the choice could be > added to the CDL as mark up > - CDDLM implementations have walked the tree fairly far down (to > the hardware) for deployment > - CDL may be sufficient to express both deployment and > provisioning. But it is an open issue if these two activities > can, or should be unified in this way in OGSA. In particular CDL > may not be going to the full extent of supporting costing, etc., > that maybe needed to address all requirements > - Resources beneath the cut point can be considered as > pre-provisioned: they either exist or they don't. They are not > going to be deployed themselves; but they can be used to > deploy on. > - Which resource to choose for deployment? It is the choice of > the EMS architecture (EPS, CSG) and not of CDDLM. > - Discussion on how CDL may be viewed as a hierarchy of scripts; > and that one could have a history of costs associated with > each node. In other words the tree could be decorated with > other information (cost, etc, as metadata) (3) - JSDL and CDL relation and can one cover the requirements for the > other > - A JSDL submission may be associated with a deployment > description or request, and the deployment portion could be > described in CDL. [I.e., CDL could be a more specific > application > sub-type in a JSDL document.] > - JSDL is not intended to describe the configuration of the > software that will be used by the job. The aim is to describe > things at a higher level. There may be similarities between the > languages (perhaps around resource description) but it does not > mean that one language can, or should, replace the other because > they serve different purposes. > - Jay wants to pursue the issue further among a smaller group of > people. 3) OGSA F2F meeting update (30 min) Session leaders: Please provide your goals and detailed agenda. https://forge.gridforum.org/projects/ogsa-wg/document/2005Winter_F2F_survay https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… 4) Wrap up (10 min) AOB <NEXT CALL> OGSA-WG F2F Jan. 16-20. -- Hiro Kishimoto

1 0

OGSA WSRF Basic Profile 1.0 is returned to us
by Hiro Kishimoto 11 Jan '06

11 Jan '06

Hi all, Public comments period for OGSA WSRF BP 1.0 has end and the document is returned to our position with comment. Let's review and discuss how to solve this during upcoming F2F meeting next week. See you soon, ---- Hiro Kishimoto > Summary: OGSA WSRF Basic Profile 1.0 > Project: EDITOR > Category: Recommendations Track > Group: Architecture > Status: Returned to Author(s) > ---------------------------------------------------------------------- > Comment By: Greg Newby (2006-01-09 13:30:26) > Authors, please review public comments here: > https://forge.gridforum.org/forum/forum.php?forum_id=575 > > Respond in that tracker, or this one. If needed, upload a new > revision of the document to this tracker. > > When the document is ready for the next step (GFSG review), > please indicate it in this tracker, or via email.

1 0

RE: No quorum for Jan 9 call -- CANCELLED (was Re: [ogsa-wg] Jan. 9th call -- new number)
by Milojicic, Dejan S (HP Labs) 11 Jan '06

11 Jan '06

Hi, I am available Friday pm PST, Thu until 9am PST and then again 10:30am-2pm PST, Wed 11:30am-2:30pm PST, etc. I'd also be glad to talk even to 1:1 if this is the only way it will work. There is some spell on this meetings, this is the third or fourth time we are not able to make it :-(. Dejan. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Maguire, Tom > Sent: Monday, January 09, 2006 3:50 PM > To: Andreas Savva; ogsa-wg(a)ggf.org > Subject: RE: No quorum for Jan 9 call -- CANCELLED (was Re: > [ogsa-wg] Jan. 9th call -- new number) > > I will be available Wed AM PT, and Friday anytime PT. > > Tom > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] > On Behalf > > Of Andreas Savva > > Sent: Monday, January 09, 2006 6:16 PM > > To: ogsa-wg(a)ggf.org > > Subject: No quorum for Jan 9 call -- CANCELLED (was Re: > > [ogsa-wg] Jan. 9th call -- new number) > > > > [This is in place of minutes.] > > > > The call today was eventually cancelled after migrating to the new > > number. We discussed whether to try again with the same agenda on > > Wednesday but it is not clear if enough people can make it > due to the > > conflict with the GFSG meeting. Hiro will check people's > availability > > and post an agenda. > > > > Note that the Wednesday call day and/or time MAY CHANGE and > there will > > be NO CALL unless an agenda is posted in advance. > > > > Andreas Savva > > > > Fred Maciel wrote: > > > Hi, > > > > > > People are having problems to join the call -- Hiro > included. > > > Let's use my number today: > > > > > > Dial-in: > > > Toll Free: (888) 422-7120 > > > International Access: (608) 250-0194 > > > Participant code: 693305 > > > > > > See ya, > > > > > > Fred Maciel > > > > > > > > >

2 1

CFP: Workshop "Dependability Aspects in DWH and MiningApplications" (DAWAM), Submission Deadline: 15-01-2006
by Nguyen Manh Tho 10 Jan '06

10 Jan '06

(Apologies for multiple copies due to cross postings. Please send to interested colleagues and students) CALL FOR PAPERS: International Workshop Dependability Aspects on Data WArehousing and Mining applications DAWAM 2006 <http://www.ares-conf.org/?q=dawam> in conjunction with The First International Conference on Availability, Reliability and Security (ARES <http://www.ifs.tuwien.ac.at/ares2006> 2006) Overview Nowadays, the rapid growth of information technologies has brought tremendous opportunities for data sharing, integration, and analysis across multiple distributed, heterogeneous data sources. In the past decade, data warehousing and mining are the well-known technologies used for data analysis and knowledge discovery in vast domain of applications. Data mining technology has emerged as a means of identifying patterns and trends from large quantities of data. Data mining has used a data warehousing model of gathering all data into a central site, then running an algorithm against that data. A growing attention has been paid to the study, development and application of data warehousing and mining. Nevertheless, dependability aspects in these applications such as availability, reliability, integrity, privacy, and security issues are still being investigated. For example, in data warehousing applications, privacy considerations may prevent the approach of collecting data into the centralized warehouse because each data source has different privacy policy. Furthermore, the complexity of security increases as different sources of information are combined. Reliable, consistent and trustworthy of information are also significant requirements in data warehousing applications. Data mining has been shown to be beneficial in confronting various types of attacks to computer systems such as fraud detection, intrusion prevention. In some applications, e.g. clinic information system, government management, business competitive information, it is required to apply the mining algorithms without observing the confidential data values thus demands the privacy preservation. There are also many challenging issues that need further investigation in the context of data mining from both privacy and security perspectives such as mining of imbalanced data, bioinformatics data, streaming data, ubiquitous computing data, grid computing data etc. The goals of this workshop are to bring together users, engineers and researchers (from industry and academy) alike to present their recent work, discuss and identify problems, synergize different views of techniques and policies, and brainstorm future research directions on various dependability aspects of data warehousing and data mining applications. We strongly encourage researchers and practitioners with interest in the areas of reliability, availability, privacy and security, databases, data warehousing, data mining, and statistics to submit their experience, and/or research results. Topics related to any of dependability aspects in data warehousing and mining, theory, systems and applications are of interest. These include, but are not limited to the following areas: * Dependability and fault tolerance * High Availability and Disaster Recovery * Survivability of evaluative systems * Reliability and Robustness Issues * Accuracy and reliability of responses * Reliable and Failure Tolerant Business Process Integration * Reliable Event Management and Data Stream Processing * Failure Tolerant and trustworthy Sensor Networks * Highly available data warehouses for business processes integration * Handling different or incompatible formats, and erroneous data * Privacy and security policies and social impact of data mining * Privacy preserving data integration * Access control techniques and secure data models * Encryption & Authentication * Pseudonymization and Encryption * Anonymization and pseudonymization * Trust management, and security * Security in Aggregation and Generalization * User Profile Based Security * Secure multi-party computation * Secondary use of personal data, clinic data, credit record * Fraud and misuse detection * Intrusion detection and tolerance * Data mining applications for terrorist detection * Private queries by a (semi-trusted) third party * Query authentication, logging, auditing, access control and authorization policies The program of the workshop will be a combination of invited talks, paper/poster presentations and discussions. 1. Important Dates Submission Deadline: December, 15th 2006 (Extension !!!) Author Notification: January, 23th 2006 Author Registration: February, 1st 2006 Proceedings Version: February, 1st 2006 2. Submission Guidelines Authors are invited to submit research and application papers in IEEE Computer Society Proceedings Manuscripts style (two columns, single-spaced, including figures and references, using 10 fonts, and number each page). You can confirm the IEEE Computer Society Proceedings Author Guidelines at the following web page: URL: http://computer.org/cspress/instruct.htm or http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm Submission are classified into 3 categories (1) full paper (8 pages), (2) short paper (5 pages), and (3) poster (2 pages) representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Contact author must provide the following information: paper title, authors' names, affiliations, postal address, phone, fax, and e-mail address of the author(s), about 200-250 word abstract, and about five keywords and register at our ARES website: http://www.ares-conf.org/?q=submission. Prepare your paper in PDF or MS Word file and submit it to our site or send it to the workshop co-chair: Dr. Nguyen Manh Tho, Institute of Software Technology, Vienna University of Technology, via email: tho(a)ifs.tuwien.ac.at not later than 15-01-2006 Submission of a paper implies that should the paper be accepted, at least one of the authors will register and present the paper in the conference. Accepted papers will be given guidelines in preparing and submitting the final manuscript(s) together with the notification of acceptance. 3. Publication All accepted papers (full and short papers) will be published as ISBN proceedings published by IEEE Computer Society. Based on quality and referee reviews, some papers not suitable for acceptance as full paper will be accepted for presentation at DAWAM 2006 in Poster category and will be also included in the IEEE Proceedings. A selected number of papers will be nominated to be published as special issues in appropriate journals such as Journal of automatic and trusted computing (JoATC). 4. Workshop Organizer Co-chairs Jimmy Huang, Prof. School of Information Technology, York University, Toronto, Ontario Canada M3J 1P3 jhuang(a)yorku.ca Josef Schiefer, Ph.D. Senactive IT-Dienstleistungs GmbH , Phorusgasse 8 A1040 Vienna, Austria josef.schiefer(a)senactive.com Nguyen Manh Tho, Ph.D. (main contact) Institute of Software Technique and Interactive System, Vienna University of Technology , Favoriten strasse 9-11/188 A1040 Vienna, Austria tho(a)ifs.tuwien.ac.at 5. Program Committee Aijun An, York University, Canada Pawan Chowdhary, IBM T J Watson Research Center, USA LiWu Chang, Naval Research Laboratory, USA Josep Domingo-Ferrer, Rovira i Virgili University of Tarragona, Spain Elena Ferrari, University of Insubria at Como, Italy Ulrich Flegel, University of Dortmund, Germany Tyrone Grandison, IBM Almaden Research, USA Jun-Jang (JJ) Jeng, IBM T.J. Watson Research Center, USA Hillol Kargupta, University of Maryland, Baltimore County, USA and Agnik, LLC Zongwei Luo, University of Hong Kong, Hong Kong Taneli Mielikäinen, University of Helsinki, Finland Daniel E. O'Leary, University of Southern California, USA Stanley Oliveira, Embrapa Information Technology, Brazil Arnon Rosenthal, MITRE Corporation, USA Ben Soh, La Trobe University, Australia David Taniar, Monash University, Australia Juan Trujillo, University of Alicante, Spain Vassilios S. Verykios, University of Thessaly, Greece Justin Zhan, University of Ottawa, Canada Sheng Zhong, State University of New York at Buffalo, USA

1 0

CFP: Workshop Dependability and Security in e-Government(DeSeGov 2006) - Submission Deadline 20-01-2006
by Nguyen Manh Tho 10 Jan '06

10 Jan '06

Workshop "Dependability and Security in e-Government" (DeSeGov 2006) <http://www.ares-conf.org/www.ares-conf-org/?q=DeSeGov> www.ares-conf-org/?q=DeSeGov Vienna, April 20th -22nd 2006 in conjunction with The First International Conference on Availability, Reliability and Security ( <http://www.ares-conf.org/www.ares-conf.org> ARES 2006 ) Call for Papers Many governments have now significant e-government applications that offer more and more the day-to-day services to the citizen. ICT infrastructure has become as important as government offices and its officials: crucial for the functioning of the state. Modern government is today dependent on its functioning ICT: the systems must be available, reliable, safe, confidential, integer and secure. The aim of this workshop is to foster a forum for discussing and presenting recent research results on dependability and security in e-Government applications. Scientific rigor and discussions of state of the art of dependability and security in e-Government are strongly encouraged. Besides, innovative research work in progress and studies of dependability aspects of practical e-Government projects and systems implementation are also welcome. Topics of interest include, although not limited to, the following: . Trust and security: provisions and instruments . Online availability of public services . Service survivability and maintainability . Interoperability of services . Security in e-democracy (including e-participation and e-voting) . E-justice (administration and workflow security for legal processes) . Secure federating information access (from different government and third party agencies) . Security and reliability in media integration . Secure e-government and Identity Management . Security and reliability of Smart Card System . Availability and reliability of mobile services . Data protection and data privacy (e.g. e-health and e-education) . Intrusion detection and prevention . Anti-spam legislation and solution . Public-private- partnerships management . Role-based management and usage restriction Important Dates Submission Deadline: January, 20th 2006 Author Notification: February, 1st 2006 Author Registration: February, 7th 2006 Proceedings Version: February, 7th 2006 Submission Guidelines The proceedings of this workshop will be published by IEEE. Authors are invited to submit their papers in the IEEE Computer Society Proceedings Manuscripts format (two columns, single-spaced, including figures and references, using 10 fonts, and number each page). The IEEE Computer Society Proceedings Author Guidelines are available at the following web page: URL: <http://computer.org/cspress/instruct.htm> http://computer.org/cspress/instruct.htm or <http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm> http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm Submission are classified into 3 categories (1) full paper (8 pages), (2) short paper (5 pages), and (3) poster (2 pages) representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Contact author must provide the following information: paper title, authors' names, affiliations, postal address, phone, fax, and e-mail address of the author(s), about 200-250 word abstract, and about five keywords and register at our ARES website: <http://www.ares-conf.org/?q=submission> http://www.ares-conf.org/?q=submission. Prepare your paper in PDF or MS Word file and submit it to our site at <http://www.ares-conf.org/?q=submission> http://www.ares-conf.org/?q=submission Submission of a paper implies that should the paper be accepted, at least one of the authors will register and present the paper in the conference. Accepted papers will be given guidelines in preparing and submitting the final manuscript(s) together with the notification of acceptance. Publication All accepted papers (full and short papers) will be published by IEEE Computer Society. Workshop Chairpersons A Min Tjoa, Vienna University of Technology, Austria Erich Schweighofer, University of Vienna, Austria Programme Committee * Peggy Agouris, University of Maine, USA * Yigal Arens, USC/Columbia University Digital Government Research Center, USA * Jon Bing, University of Oslo, Norway * Fernando Galindo, University of Zaragoza, Spain * Dieter Klumpp, Alcatel SEL Foundation, Germany * Robert Krimmer, Vienna University of Economics and Business Administration, Austria * Scott F. Midkiff, Virginia Polytechnic Institute and State University,USA * Enrico Nardelli, University of Rome TorVergata, Italy * Tho Manh Nguyen, Vienna University of Technology, Austria * Erich Schweighofer, University of Vienna, Austria * Efthimios Tambouris, CERTH/ITI, Greece * A Min Tjoa, Vienna University of Technology, Austria * Greg B. White, The University of Texas at San Antonio, USA ** Maria A. Wimmer, University of Koblenz, Germany

1 0

CFP: Workshop on Bioinformatics and and Security (BIOS06) (Vienna, Austria) - Deadline: 15-01-2006
by Nguyen Manh Tho 10 Jan '06

10 Jan '06

1st International Workshop on Bioinformatics and Security (BIOS 06) In Conjunction with ARES 2006 <http://128.131.167.54/ares/> Vienna, Austria 20-22 April, 2006 <http://web.engr.oregonstate.edu/~stumpf/TAKMA2005prelimprog.html> Call for Papers Technological advances in high-throughput techniques and efficient data gathering methods coupled with a world wide effort in computational biology have resulted in a vast amount of life science data often available in distributed and heterogeneous repositories. These repositories contain interesting information such as sequence and structure data, annotations for biological data, results of complex and expensive computations, bio-medical publications, and so on. Newer and more sophisticated computational techniques to analyze such data are also being developed and made available for public use at a rapid pace. Nonetheless, the multiplicity in the objectives, methods, representation, and platforms of these data sources and analysis tools have created an urgent and immediate need for research in resource integration and platform independent processing of investigative queries involving heterogeneous data sources and analysis tools. It is now universally recognized that a database approach to analysis and management of biological data offers a convenient, high level, and efficient alternative to high volume biological data processing and management. Advances in database integration, query processing, web technology, work flow systems, and object-orientation can be leveraged to develop novel high-performance data management systems for biological applications. But also security is very important in this area and therefore this workshop has these two focuses. Topics of interest lie at the intersection of general bioinformatics and security research. Following is a nonexclusive list of topics of interest for this year. * Security for grid computing in the field of bioinformatics * Information security development processes for sensitive (medical) data * Securing medical data (Information, Data and System Integrity) * Digital Rights Management for medical stored data * Complex relational database management system, with object-oriented extensions and numerous application driven enhancements * Web and Wireless Security Bioinformatics and Medical Diagnosis * Usability and security needs of complex systems * Innovative approaches for securing medical data (access management, authentication, data protection, etc.) * Information Security Management Important Dates Submission of papers: 15 January 2006 Notification of acceptance: 23 January 2006 Camera-ready copies: 1 February 2006 Submission Details Your contributions should be formatted acoording to the IEEE Computer Society Press Proceedings Author Guidelines: 10-point Times, single-spaced, two-column format (see <http://computer.org/cspress/instruct.htm> here for detail; if the link does not work, see <http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm> here for approximation). Each of your contributions should not exceed 8 pages. Organisational Committee Workshop Chair Küng Josef, University of Linz, FAW Austria Mazuran Petra, FAW, Austria Wagner Roland, University of Linz, FAW Ausstria Program Committee Eisenacher Martin, University of Münster, Germany Hochreiter Sepp, TU Berlin, Germany Hof Sonja, (DWS) AG,Switzerland Kramer Stefan, TUM, Germany Marik Vladimir, Technical University Prag, Czech Mazuran Petra, FAW, Austria Palkoska Jürgen, FAW Austria Retschitzegger Werner, University of Linz, Austria Revell Norman, Middlesex University, UK Tjoa A Min, Technical University of Vienna, Austria

1 0

RE: No quorum for Jan 9 call -- CANCELLED (was Re: [ogsa-wg] Jan. 9th call -- new number)
by Maguire, Tom 09 Jan '06

09 Jan '06

I will be available Wed AM PT, and Friday anytime PT. Tom > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Andreas Savva > Sent: Monday, January 09, 2006 6:16 PM > To: ogsa-wg(a)ggf.org > Subject: No quorum for Jan 9 call -- CANCELLED (was Re: > [ogsa-wg] Jan. 9th call -- new number) > > [This is in place of minutes.] > > The call today was eventually cancelled after migrating to > the new number. We discussed whether to try again with the > same agenda on Wednesday but it is not clear if enough people > can make it due to the conflict with the GFSG meeting. Hiro > will check people's availability and post an agenda. > > Note that the Wednesday call day and/or time MAY CHANGE and > there will be NO CALL unless an agenda is posted in advance. > > Andreas Savva > > Fred Maciel wrote: > > Hi, > > > > People are having problems to join the call -- Hiro included. > > Let's use my number today: > > > > Dial-in: > > Toll Free: (888) 422-7120 > > International Access: (608) 250-0194 > > Participant code: 693305 > > > > See ya, > > > > Fred Maciel > > > >

1 0

Jan. 9th call -- new number
by Fred Maciel 09 Jan '06

09 Jan '06

Hi, People are having problems to join the call -- Hiro included. Let's use my number today: Dial-in: Toll Free: (888) 422-7120 International Access: (608) 250-0194 Participant code: 693305 See ya, Fred Maciel

2 1

Proposed agenda for Jan. 9th call
by Hiro Kishimoto 09 Jan '06

09 Jan '06

Hi all, I hope you and your family had a good holiday break and are looking forward to the new year. The following is a proposed agenda for OGSA-WG telecon on Jan. 9th 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: 0109 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. 19) https://forge.gridforum.org/projects/ogsa-wg/document/minutes20051219/en/1 Do we have Jan. 11th telecon, since several people will be at GFSG F2F meeting? Agenda bashing 2) CDDLM-WG joint call (60 min) Jem has uploaded the revised version to the GridForge. - http://tinyurl.com/aez86 Look forward to proofread and tracker verification. (1) Deployment and configuration section break-down > == Proposed list of sections == > > 3.1 Provision (Deploy) an application on an existing BES container > (The application can then be used to instantiate a BES activity. > Mostly what is now 3.2 in EMS Architecture composition.) > > 3.2 Provision a BES container > (What is now 3.1 in EMS Architecture composition) > > [Both 3.1 and 3.2 assume that the 'level' of the BES container is > pre-determined and fixed. See below.] > > 3.3 Using ACS do 3.1 > > 3.4 Using ACS do 3.2 > > [Both 3.3 and 3.4 assume that the 'level' of the BES container is > pre-determined and fixed. See below.] > > 3.5 Add time predictions to provision 3.1 and 3.2 by a deadline > Using a deployment estimation service (perhaps based on > historical data, etc, but how the estimation is done is > out-of-scope.) Possibly requiring reservations. > > [3.5 assumes that the 'level' of the BES container is pre-determined > and fixed. See below.] > > 3.x Determine dynamically the optimal level of 'BES container' in the > system and provision containers appropriately depending on > workload etc > may depend on analysis of the entire application CDL (down to > hardware) for the entire workload of the system; use > deployment time predictions; etc > > <<Version 1 of the document could just cover scenarios 3.1-3.5 and > discuss 3.x as future work. Otherwise need to breakdown 3.x further.>> > == (2) - Deployment versus provisioning requirements > (Or, where to 'cut' the CDL tree. Above the 'cut' point is > deployment---assumed to be a relatively 'light' operation---and > below is provisioning---assumed to be more heavy-weight.) > - Deciding the cut point is orthogonal to CDDLM---it is policy or > best practices and is therefore a system choice > - Information (metadata) to help in making the choice could be > added to the CDL as mark up > - CDDLM implementations have walked the tree fairly far down (to > the hardware) for deployment > - CDL may be sufficient to express both deployment and > provisioning. But it is an open issue if these two activities > can, or should be unified in this way in OGSA. In particular CDL > may not be going to the full extent of supporting costing, etc., > that maybe needed to address all requirements > - Resources beneath the cut point can be considered as > pre-provisioned: they either exist or they don't. They are not > going to be deployed themselves; but they can be used to > deploy on. > - Which resource to choose for deployment? It is the choice of > the EMS architecture (EPS, CSG) and not of CDDLM. > - Discussion on how CDL may be viewed as a hierarchy of scripts; > and that one could have a history of costs associated with > each node. In other words the tree could be decorated with > other information (cost, etc, as metadata) (3) - JSDL and CDL relation and can one cover the requirements for the > other > - A JSDL submission may be associated with a deployment > description or request, and the deployment portion could be > described in CDL. [I.e., CDL could be a more specific > application > sub-type in a JSDL document.] > - JSDL is not intended to describe the configuration of the > software that will be used by the job. The aim is to describe > things at a higher level. There may be similarities between the > languages (perhaps around resource description) but it does not > mean that one language can, or should, replace the other because > they serve different purposes. > - Jay wants to pursue the issue further among a smaller group of > people. 3) OGSA F2F meeting update (30 min) Session leaders: Please provide your goals and detailed agenda. https://forge.gridforum.org/projects/ogsa-wg/document/2005Winter_F2F_survay https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… 4) Wrap up (10 min) AOB <NEXT CALL> OGSA-WG F2F Jan. 16-20. -- Hiro Kishimoto

3 4

Joint CFP: BSN'06 & SoS4CO'06
by gagnon＠soa7.com 09 Jan '06

09 Jan '06

Please accept our 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 organizations * Match-making of semantic service descriptions * Negotiating of inter-organizational business processes * 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: Please submit papers via http://elab.njit.edu/bsnsos4co/submit. 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. 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: Stéphane 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

CFP: Global Integration Summit 2006 (GIS'06)
by gagnon＠soa7.com 09 Jan '06

09 Jan '06

Please accept our apologies for cross-posting. ********************************************************************** CALL FOR PAPERS Global Integration Summit 2006 (GIS'06) "Integration For Everyone" Annual Meeting of the Integration Consortium Fairmont Copley Plaza Boston, May 22-24, 2006 http://www.globalintegrationsummit.com http://www.integrationconsortium.org ********************************************************************** --- OVERVIEW --- The Global Integration Summit (GIS) is the annual meeting of the Integration Consortium (IC), the non-profit, user-driven association of IT professionals focused on application, information, process, service, and system integration technologies. The GIS differs from other industry events as it is truly user-driven and vendor-neutral. With an attendance hovering above 200 every year, and involving senior integration executives from leading Global 2000 corporations, the event offers a personal atmosphere for networking. --- THEME --- For our 3rd edition, the theme "Integration For Everyone" seeks to build a unified view of the Integration Discipline. One outcome of the Summit should be to develop a new Integration Body of Knowledge (I- BOK) As such, we welcome IT thought leaders from industry, vendors, analysts, and academia to expose the "State of the Art" in integration solutions. --- TOPICS --- Topics can range from business drivers for integration such as Governance and Regulatory Compliance, to integration approaches and platforms such as the Service Oriented Architecture (SOA) and Business Process Management (BPM), to technical infrastructure issues such as Enterprise Service Bus (ESB) and Open Source Middleware. Papers can take the form of conceptual frameworks, research in progress, best practice reports, case studies, and executive viewpoints. We welcome papers that contribute to enriching the I-BOK. Please see below for an outline, with a detailed list of 50 topics available at: http://www.integrationconsortium.org/docs/ibok-v1.pdf Part A - Business Perspective 1. Business Trends and Integration Drivers 2. Industry-Specific Integration Drivers Part B - Application Requirements 3. Application-Specific Integration Solutions 4. User-Centric Integration Solutions Part C - Development Capabilities 5. Strategic Management of the Integration Function 6. Integration Development Methods and Standards 7. Integration Development Tools and Best Practices Part D - Technologies and Standards 8. Integration Platforms and System Architecture 9. Core Integration Technologies and Standards 10. Integration Runtime Infrastructure --- IMPORTANT DATES --- * Papers Submission Deadline >>> January 31, 2006 * Notification of Paper Selection >>> February 20, 2006 * Confirmation by Author to present at GIS 2006 >>> February 28, 2006 * Early Bird Registration Deadline >>> April 1, 2006 * Upload Final Paper and Presentation >>> May 1, 2006 * Global Integration Summit >>> May 22-24, 2006 --- SUBMISSION --- * Instructions: http://www.globalintegrationsummit.com/callforpapers.htm * Paper Template: http://www.globalintegrationsummit.com/docs/template.doc * Submission System: http://www.globalintegrationsummit.com/submit --- CO-CHAIRS --- John Schmidt President, Integration Consortium Senior Vice President, Integration, Bank of America Peter Anadranistakis Board of Directors Member, Integration Consortium Chief Partnership Officer, Online Business Systems Dr. Stephane Gagnon VP Research and Standards, Integration Consortium Assistant Professor, New Jersey Institute of Technology --- CONTACT --- Please send all enquiries by email to: info(a)globalintegrationsummit.com

1 0

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

06 Jan '06

yeah figured that out.... ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Treadwell, Jem Sent: Wednesday, January 04, 2006 4:58 PM To: ogsa-wg(a)ggf.org Subject: RE: [ogsa-wg] Joining at 6PM ET<EOM> 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

3 2

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

Proposed agenda for Dec. 12th call
by Andreas Savva 14 Dec '05

14 Dec '05

[Tom and Hiro are unavailable but that should not stop us from having a teleconference. I'll be chairing this call.] Proposed agenda for OGSA-WG telecon, Dec. 14th Wednesday, 4-6pm (CST). Dial-in numbers: US Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service: URL: http://ogsa.glance.net Session key: 1214 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. 12) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051212/en/1 Agenda bashing ## If there are updates and time allows, consider: 1. Basic Security Profile (re)-factoring 2. OGSA Arch and Glossary 1.5 2) OGSA Profile Definition final call (10 min) > 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. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-profil… 2) EMS architecture (45 min) (1) Review sequence diagrams from composite roadmap (Steven N to send out) 2.4 Job Termination 2.5 Dynamic Job Selection (3) Deployment and configuration section break-down (Andreas S to send out) EMS Architecture Composition Roadmap draft: https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… (Now also linked under the Root Folder) 4) Wrap up (10 min) AOB <NEXT CALL> Dec. 19 (Mon) OGSA-AuthZ joint call Naming requirement discussion Jan F2F preparation Dec. 21 (Wed) EMS Arch CDDLM/ACS/GRAAP joint call ** DEC 21 IS THE LAST CALL OF 2005 ** Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Andreas Savva Fujitsu Laboratories Ltd

1 1

IPsphere and OGSA-WG joint call (Dec. 8th)
by Hiro Kishimoto 14 Dec '05

14 Dec '05

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/en/1 -- Hiro Kishimoto

2 3

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

Naming Requirements Document
by Mark Morgan 07 Dec '05

07 Dec '05

Andrew asked me to mail this out to the ogsa working group. This is a document which was produced early on in the naming design team before the working group was formed. -Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.mark-morgan.net mark(a)mark-morgan.net

1 0

CFP: Global Integration Summit 2006 (GIS'06)
by gagnon＠soa7.com 07 Dec '05

07 Dec '05

********************************************************************** CALL FOR PAPERS Global Integration Summit 2006 (GIS'06) "Integration For Everyone" Annual Meeting of the Integration Consortium Fairmont Copley Plaza Boston, May 22-24, 2006 http://www.globalintegrationsummit.com http://www.integrationconsortium.org ********************************************************************** --- OVERVIEW --- The Global Integration Summit (GIS) is the annual meeting of the Integration Consortium (IC), the non-profit, user-driven association of IT professionals focused on application, information, process, service, and system integration technologies. The GIS differs from other industry events as it is truly user-driven and vendor-neutral. With an attendance hovering above 200 every year, and involving senior integration executives from leading Global 2000 corporations, the event offers a personal atmosphere for networking. --- THEME --- For our 3rd edition, the theme "Integration For Everyone" seeks to build a unified view of the Integration Discipline. One outcome of the Summit should be to develop a new Integration Body of Knowledge (I-BOK) As such, we welcome IT thought leaders from industry, vendors, analysts, and academia to expose the "State of the Art" in integration solutions. --- TOPICS --- Topics can range from business drivers for integration such as Governance and Regulatory Compliance, to integration approaches and platforms such as the Service Oriented Architecture (SOA) and Business Process Management (BPM), to technical infrastructure issues such as Enterprise Service Bus (ESB) and Open Source Middleware. Papers can take the form of conceptual frameworks, research in progress, best practice reports, case studies, and executive viewpoints. We welcome papers that contribute to enriching the I-BOK. Please see below for an outline, with a detailed list of 50 topics available at: http://www.integrationconsortium.org/docs/ibok-v1.pdf Part A - Business Perspective 1. Business Trends and Integration Drivers 2. Industry-Specific Integration Drivers Part B - Application Requirements 3. Application-Specific Integration Solutions 4. User-Centric Integration Solutions Part C - Development Capabilities 5. Strategic Management of the Integration Function 6. Integration Development Methods and Standards 7. Integration Development Tools and Best Practices Part D - Technologies and Standards 8. Integration Platforms and System Architecture 9. Core Integration Technologies and Standards 10. Integration Runtime Infrastructure --- IMPORTANT DATES --- * Papers Submission Deadline >>> January 31, 2006 * Notification of Paper Selection >>> February 20, 2006 * Confirmation by Author to present at GIS 2006 >>> February 28, 2006 * Early Bird Registration Deadline >>> April 1, 2006 * Upload Final Paper and Presentation >>> May 1, 2006 * Global Integration Summit >>> May 22-24, 2006 --- SUBMISSION --- * Instructions: http://www.globalintegrationsummit.com/callforpapers.htm * Paper Template: http://www.globalintegrationsummit.com/docs/template.doc * Submission System: http://www.globalintegrationsummit.com/submit --- CO-CHAIRS --- John Schmidt President, Integration Consortium Senior Vice President, Integration, Bank of America Peter Anadranistakis IC Board Member, Integration Consortium Chief Partnership Officer, Online Business Systems Dr. Stephane Gagnon VP Research and Standards, Integration Consortium Assistant Professor, New Jersey Institute of Technology --- CONTACT --- Please send all enquiries by email to: info(a)globalintegrationsummit.com

1 0

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

07 Dec '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Dec. 7th 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: 1207 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) OGSA presentation request from IPsphere (20 min) > IPsphere (http://www.ipsphereforum.org/home ) is a consortium of > network vendors and providers that recently began to work on a SOA > layer for inter-carrier negotiations (the "business layer" > augmentation to the OSI stack). They would like to hear about OGSA, identity federation/security/ discovery, WS-agreement and the other. They ask us to present OGSA at IPsphere tele conference on Thu Dec 8th, 5-7pm EST. I think we can use Ravi's MDC slide deck. Any volunteers for this Thursday? 3) OGSA naming policy discussion (45 min) From Nov. 16 minutes; > Agreed that it will likely take about 3 weeks to reach a decision > due to the various schedule issues, and given that some people > prefer to discuss the issues on teleconfs rather than using e-mail. > > ** Next steps > > - Accepted Hiro's proposal to create a document (two in fact) on the > requirements and issues and use it to drive the consensus process > - Get a shared understanding of issues, requirements and people's > positions. > > 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 Since OGSA-Naming WG will have their teleconf this Friday (10am EST), we should postpone #1 till next time. (Dec. 19?) > 2. Tom will add issues from the list discussion to the policy > document, including BES related issues. OGSA-BES WG has discussed WS-Name issue on Dec. 1st. > WS-Name issue (Properties/Meta-Data) > - MUST be a EPR with meta-data that describes queue names to determine > WS-Name or EPR or what ever is coming later. SHOULD be an WS-Name. Make > sure that the meta-data is only on the container attribute. And as such > all Activities are referenced by EPR or WS-Name not a mix of the two. > - Change IsAcceptingActivities should be changed to meta-data on the > container. > > There needs to be a last call out on the EPR/WS-Name isssue. Let's make OGSA-WG's policy and OGSA-BES's decision consistent. 4) EMS architecture (45 min) (1) review sequence diagrams from composite roadmap 2.4 Job Termination 2.5 Dynamic Job Selection (2) Review Ian's comments on 2.3 Selected Job Execution > I need to see more details on what is being proposed in terms of a > selector interface, but I would be concerned if there was an attempt > to incorporate this as a primitive. As the brief and > far-from-comprehensive list above shows, there are many different > resource selection strategies that may be applied, and these > strategies may be applied in many different ways and in different > places. (3) Deployment and configuration scenarios break down Based on the discussion at the last CDDLM/ACS joint call, I think we need more fine grain scenarios breakdown for chapter 3. EMS Architecture Composition Roadmap (incorporate Nov. 9th CDDLM/ACS joint discussion) https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… 5) Wrap up AOB <NEXT CALL> Dec. 12 (Mon) Basic Security Profile open issue discussion Architecture & Glossary 1.5 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

1 0

Glossary updated
by Treadwell, Jem 06 Dec '05

06 Dec '05

Hi, FYI that I've uploaded a new version of the OGSA Glossary v1.5, per discussion on the 12/5 telecon. It's available at http://tinyurl.com/aoalk. - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

BES/ByteIO/Naming Interop Meetings in the UK
by Mark Morgan 06 Dec '05

06 Dec '05

All, Hiro asked Andrew and I to post information about an upcoming meeting that will take place at Imperial College in London next week (12 December 2005 through 14 December 2005). I apologize to those of you on this list who already have this information. Uva has implemented prototype "proof-of-concept" versions of BES, ByteIO and an "RNS-lite" using WSRF.NET. Next week we will be meeting with a number of individuals to discuss/analyze/test interoperability of these implementations (in particular we are hoping to interop test with an implementation of BES being developed by William Lee at Imperial College. This meeting will also likely include discussions of implementation experiences in the hopes of improving the involved specifications. -Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.mark-morgan.net mark(a)mark-morgan.net

1 0

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

05 Dec '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Dec. 5th 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: 1205 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 (if available) Agenda bashing 2) Jan. F2F and GGF16 update (20 min) Hiro will send out revised schedule proposals. 3) Basic Security Profile - secure channel review (40 min) Takuya uploaded revised draft to gridForge https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… > The changes are: > * abstract > revised it > - to remove dependency to security token stuffs > - to add a clarification that this profile only focuses on mutual authn, > integirity and confidentiality of WS communication > - to add a reference to ogsa basic profile > * 3 dots in section 1.1 > revised it to make it clearer what the profile is doing > * section 1.2 > a reference to ogsa basic security profile is added. > it is mentioned that the secure channel profile should be used in > conjunction with one of ogsa basic profiles and ogsa basic security > profile. > the ogsa basic security profile is mentioned that it addresses security > issues which are common to all the ogsa services, such as security > token format. > * section 1.3 > the reference to WSSE is removeed from the Table > * section 2.1 > targets related to WSSE are revoed from the list > * chapter 3 > statements related to keyinfo exchange and security token are removed 4) Architecture and Glossary 1.5 review (30 min) Takuya uploaded revised draft to gridForge 5) Wrap up (10 min) AOB <NEXT CALL> Dec. 7 (Wed) Two naming requirement docs review EMS architecture Information model & CIM profile Dec. 12 (Mon) Architecture & Glossary 1.5 Basic Security Profile review Dec. 14 (Wed) EMS architecture Information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 2

Teleconference minutes - 30 November 2005
by Andreas Savva 05 Dec '05

05 Dec '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051130/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 30 November 2005 ====================================== * Participants Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (EMC) Steve McGough (IC) Mark Morgan (UVa) Takuya Mori (NEC) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Ravi Subramaniam (Intel) Jem Treadwell (HP) Apologies: Steven Newhouse Minutes: Andreas Savva * November 28 minutes approved with no changes * UML tool update - RSM was chosen; no objections so far. - Ellen is following up on how to get licenses. - (It is used by DMTF already so it is possible.) * Meeting planning ** GGF16 - Proposal to organize just the default 2 sessions. - It worked well last time and also allowed WG members to attend other sessions as well. The separate one day F2F should allow enough time for more detailed discussions. - One session could be 'Outreach'. But 'Outreach' last time was not well attended. There are two possibilities: - Andrew G's proposal to have a 'Town Hall' style meeting instead. Talk with Andrew to get more details - An outreach session as a 'deep-dive' for a specific capability to introduce the group's work in more detail. - The second session was a joint-wg discussion. Last time it was EMS-CDDLM. Having a similar joint discussion with another group might be a good idea. - The deadline for session requests is Dec. 14. - Groups requesting sessions after Dec 2 must have an up-to-date charter; not a problem since OGSA's new charter was approved recently. ** GGF16 B2B F2F - OGSA-WG has been asked not to overlap its B2B F2F with GGF sessions. So this time the back-to-back meeting will be on Friday only. - A room at IBM Athens has been reserved. But it may not have internet access. - Hiro is also looking for a room at a University in Athens and if it offers internet access the meeting may be moved there instead. - In any case a final decision for the venue should be made by the end of December. ** GGF16/F2F Actions - Hiro will send out a topic request to the list - For both the GGF16 joint session and for the one day F2F. The choice for the joint session to be based on people's availability (and whether they can attend the Friday F2F) and how big the topic is (fits in 90 minutes). - Review choices next week ** Jan. 2006 interim meeting - Agenda reviewed once on a call. Hiro is updating it and will review it once more. - Hiro will also do a zoomerang survey to confirm people's availability. * BES Information model review - Ellen sent out a ppt before the call. Only slide 4 was reviewed on the call. (Slides 1-3 are carried over from an earlier presentation and slide 5 is redundant and will be deleted.) - Slide 4 is based on work between Ellen, Andrew and Mark and is a first step in working out the minimal set of required and optional information for a BES container. - At this point, this work does not consider activities that may be started within the container. ** Operating System: - It seems to be accurate for a server box but does it cover other possibilities such as 'Java VM' or batch system (e.g., PBS)? - This is probably covered by the value of OSType. - Is this the best way to map to CIM? - There are probably some missing bits. The motivation is for this to describe an operating environment - The attributes are constrained to be specific to a BES container but it is expected that there will be a new class in CIM (Service Container) and that the BES container will be the constrained profile version of this Service Container (and not a subclass). - The classes are not shown yet - Other attributes: These are attributes that need to be explored further. E.g., libraries/packages are actually part of the application model in CIM and it is not clear how best to fit them in yet. ** Processor: - What is the difference between the '# of processes' here and the 'number of processes' in the Operating System? - It is not clear and needs to be reviewed again. - 'Load for computer systems', '# of processes': They don't seem so specific to Processor. - (Have to also think of virtualization: What is real or virtual in CIM. This is an ongoing discussion within CIM.) ** Networking - This is just an initial attempt. Current scheduling systems do not require this kind of information. - Still it seems strange that even simple descriptions such as the number of cards or their bandwidth are not part of the Optional list. ** Disk - Not discussed yet. To revisit later. ** Filesystem - Why is 'casesensitive' or 'filesystemtype' optional? - Most systems do not use these for scheduling ** ServiceContainer - The attributes listed after the first two items in the list should be optional not required. ** Management interfaces - Which of these are functional vs management interfaces? There are different perspectives, with the consensus that 'Stop' and 'Start' are probably management but less sure about the rest. - This is another item to discuss again in more detail within the design team. ** Overall - Consensus that this is a good step forward. It does need more work. - How many pages would a completed profile take? - It should not exceed 50 pages. - Next review? - Ellen's schedule is full in December. Work will continue within the smaller group and it may be possible to have another review in January before the F2F. - Jan 9 is probably the only full OGSA call possible in January before the F2F(+). But a smaller group could use one of the call slots to have a review. (+) Note: GFSG meeting is planned for the week before the OGSA F2F. * MDC presentation review - Reviewed presentation posted by Ravi to gridforge. Fred made revisions on the presentation during the call. Summary of main changes below: - Add EMC to Contributors slide - 'Concepts and Fundamental' document should be changed to Architecture document - Add that OGSA profiles are styled after WS-I profiles and are extensions of WS-I BP etc - Naming - details are under discussion but at an abstract level the content is ok - Need more graphics for OGSA Data: Ravi to ask Dave B - Newer version for 'Typical Pattern': Andreas to send to Ravi (Done) - Add CMM GFD # and also do the same for other published documents showing on the slides. - Comments to Ravi by Monday latest. The presentation is planned for Tuesday. - Fred will upoad as next version, tidy up the folder and send email how to uploade new versions of existing documents. (Done) * Next call ** Monday - 'BSP - Secure channel profile' (draft expected Friday) - Architecture and Glossary 1.5 review ** Wednesday - Naming & EMS

1 0

Teleconference minutes - 28 November 2005
by Andreas Savva 04 Dec '05

04 Dec '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051128/en/1 OGSA Teleconference - 28 November 2005 ====================================== * Participants Mike Behrens (R2AD, LLC) Dave Berry (NeSC) Fred Maciel (Hitachi) Takuya Mori (NEC) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Jem Treadwell (HP) Jay Unger (IBM) Apologies: Peter Ziu Minutes: Andreas Savva * Minutes Nov 21 approved with no changes * Jan 2006 F2F - To be held at Sunnyvale. Proposed agenda is on gridforge. - The recommended hotel is the Corporate Inn. * OGSA 1.5: Infrastructure section review Reviewed new text in the infrastructure section. Some concerns were raised about the text discussing multiple profiles. There has not been any work on a second basic profile since the last GGF so saying 'defining' is not accurate---'allowing' may be better. Also there is a technical issue with saying that WS-Management is functionally equivalent to WSRF. Action: Jay volunteered to provide revised text for section 3.3.6 for review in a future call. * Basic Security Profile discussion - Agreed with proposal outlined in the email sent by Andreas to the list: separate out portions of the 'Secure channel' in a new Basic secure profile. - Takuya is working on removing those parts out of the Secure Channel and he will prepare a new draft this week. - Takuya will also prepare the new Basic security profile document - These drafts are not ready so their review is postponed for future calls. (The secure channel may be reviewed Wednesday if ready.) * Glossary review - Reviewed the Acronym list proposed by Olegario, using the normal policy---include OGSA related acronyms, consider non-OGSA grid acronyms, and do not include general acronyms. - Decisions recorded by Jem and will be uploaded to gridforge tracker. Only actions relating to the Architecture document are recorded here: - Consider adding footnote for CORBA (Andreas) - Review usage of DBMS and also RDMBS and ODMBS (Andreas) - EMS should probably be consistenly OGSA-EMS (Andreas) - EU: Change citation to VOMS and spell out EU instead (Andreas) - LDAP, RDMBS: have a look at usage of section 3.7.5 (Andreas) - PII: Andreas to check with Frank or Takuya - VLANs: Andreas to check if RM text can be rewritten * MDC presentation review - Postponed review---no quorum. - Andreas will send editable OGSA v1 figures to Ravi - Jem will send the 'refererenced standards' slides to Ravi - Andreas will arrange for a review of the slides for the next meeeting: preferably towards the end of the meeting.

2 1

MDC presentation uploaded to GridForge
by Fred Maciel 01 Dec '05

01 Dec '05

Hi, I updated to GridForge Ravi's MDC presentation edited according to the discussion today, and re-organized the files there (folder: "Meeting Materials and Minutes/Other"): - The file "MDC 2005 OGSA intro presentation" had already three versions... - ...I uploaded the following version ("MDC Preso - High Level OGSA Intro - 4Review" in the same directory) as version 4... - ...Then uploaded the following version ("MDC-Preso-Review-20051130") as version 5... - ...And the one I edited today as version 6. The latest version (whichever number it is) can be downloaded from the URL below. I'm not attaching it to this e-mail since it's quite big. https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-high-level/en / You can upload a new version by accessing the "Details" page of the document, pressing the "Edit" button, putting the new file in the "Upload File" field, and pressing the "Update Document" button. Hiro: I don't seem to have access permission to delete or to move files, can you please move the "MDC Preso - High Level OGSA Intro - 4Review" and "MDC-Preso-Review-20051130" files to the trash folder, to avoid any confusions? (We might keep them there until after MDC just in case). Regards, Fred Maciel Hitachi America R&D

1 0

Proposed agenda for Nov. 30th call
by Hiro Kishimoto 30 Nov '05

30 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 30th 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: 1130 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 (if available) Common UML tool update Agenda bashing 2) GGF16 and B2B F2F meeting schedule (20 min) How many sessions do we have at GGF16 (default 2)? > - Planning a F2F on Friday after GGF16 > - No confirmation from Athens University for a room yet. > - Confirmed room at IBM. It is a 10 minutes ride from the hotel. > > - No discussion on how many sessions to have yet. Andrew suggested > doing an "OGSA town hall" meeting to get more feedback from the > community. [This would be in addition to or in place of Outreach.] 3) EMS architecture (30 min) (1) review sequence diagrams from composite roadmap 2.4 Job Termination 2.5 Dynamic Job Selection (2) Review Ian's comments on 2.3 Selected Job Execution > I need to see more details on what is being proposed in terms of a > selector interface, but I would be concerned if there was an attempt > to incorporate this as a primitive. As the brief and > far-from-comprehensive list above shows, there are many different > resource selection strategies that may be applied, and these > strategies may be applied in many different ways and in different > places. (3) Deployment and configuration scenarios break down Based on the discussion at the last CDDLM/ACS joint call, I think we need more fine grain scenarios breakdown for chapter 3. EMS Architecture Composition Roadmap (incorporate Nov. 9th CDDLM/ACS joint discussion) https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… 4) BES information model (30 min) Andrew and Mark help Ellen to draw up an example CIM profile for BES container. We will review their draft. 5) OGSA presentation at MDC review (30 min) Ravi will give OGSA overview presentation at Management Developer Conference on December 6th. - http://mandevcon.com/ He has uploaded his slides presentation; https://forge.gridforum.org/projects/ogsa-wg/document/MDC_Preso_-_High_Leve… 6) Wrap up (10 min) AOB <NEXT CALL> Dec. 5 (Mon) Architecture & Glossary 1.5 Basic Security Profile secure channel review Dec. 7 (Wed) Two naming requirement docs review EMS architecture Information model & CIM profile Dec. 12 (Mon) Architecture & Glossary 1.5 Basic Security Profile review Dec. 14 (Wed) EMS architecture Information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 1

Proposed agenda for Nov. 28th call
by Hiro Kishimoto 29 Nov '05

29 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 28th Monday from 4pm to 6pm (CST). I will be in Seoul for Grid Forum Korea Winter Workshop keynote. In case I cannot make this call, Tom and Andreas will chair it. 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: 1128 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 (Nov. 21) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051121/en/1 Agenda bashing 2) Basic Security Profile discussion (30 min) > Therefore the proposal is to separate these sections in an "OGSA Basic > Security Profile" document. This document would expose the claim > required to satisfy the WSRF BP security profile requirements > (http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0) but would > have no normative dependency on the WSRF BP. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00080.html 3) MDC presentation review (30 min) Ravi will give OGSA overview presentation at Management Developer Conference on December 6th. Ravi will post his draft slides before the call. - http://mandevcon.com/ 4) Architecture & Glossary 1.5 (40 min) Infrastructure section review (minus Naming) Acronyms in Glossary 5) Wrap up (10 min) AOB <NEXT CALL> Nov. 30 (Wed) EMS architecture Information model & CIM profile Dec. 5 (Mon) Architecture & Glossary 1.5 Basic Security Profile review Dec. 7 (Wed) Two naming requirement docs review EMS architecture Information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

4 5

RE: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)
by Maguire_Tom＠emc.com 29 Nov '05

29 Nov '05

<trm>Comments inline</trm> -----Original Message----- From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Mark McKeown Sent: Tuesday, November 22, 2005 9:58 AM To: Frank Siebenlist Cc: ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org Subject: Re: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing) Hi Frank, I have made some comments inline... First to remove some confusion about IRIs that have appeared in previous mails in this thread. URNs and URLs are URIs[1], IRIs[2] are an extension of URIs to support extra charactors. A URI may or may not map to a real physical address. The WS-Addressing specification[3] defines a number of URIs that do not map to real network locations (eg http://www.w3.org/2005/08/addressing/anonymous) WS-Addressing mandates that the wsa:Address element is an absolute IRI. > > * include a profile for the use of the Address and ReferenceParameters > that ensure the proper uniqueness property in time and space of the > reference. Tom Maguire suggested to use the wsdl binding of the > address which sounded very promising. I am not sure I have understood Tom's argument correctly so I will try and repeat it here in order to be corrected... TomM suggested using the wsa::Address as the name, I understand his argument as being that with the WSDL binding for WS-Addressing you can include the service part of the WSDL into the wsa:Metadata of the EPR, the service part may contain a number of network endpoints indicating that the WS-Resource is available at a number of locations. >From 'Web Services Addressing 1.0 - WSDL Binding' [4]: "In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint." In this case the wsa:Address could be a URN (or URI that is not an actual network location) and the client could look to the wsa:Metadata to find the actual network location of the WS-Resource. Quoting Tom[5]: "Let me be very clear about this an EPR does not have a 1 to 1 correspondence with a protocol and binding address. It MUST be true that an EPR can support multiple protocols and their associated addresses." I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when discussing including WSDL components in the EPR, there is no obligation. <trm>probably should not have capitalized MUST. The important aspect of that statement is 'can support'</trm> I think most services will only use one transport protocol so I think this feature will not be used often - even if a service does use more than one transport/port there is no requirement to advertise this in the EPR. <trm>yes, that is what the 'MAY' means wrt requirement to advertise. I am puzzled why you think that most services will use only one transport protocol. Certainly there are a few to choose from, SOAP/HTTP, SOAP/JMS, SOAP/BEEP and clearly the separation of protocol handlers from service implementation is a good thing.</trm> Also there is no transport bindings available for WS-Addressing - for example the SOAP bindings tells us to take the wsa:Address element and put it into the wsa:To element in the SOAP header but does not tell us what to do with it with regards to the transport protocol (eg most people use the wsa:Address element to create a RequestURI which they set as the POST HTTP Header when using HTTP - this issue has been raised with the W3C TAG[6]). <trm>I wonder what their solution will be.....</trm> Quoting WS-Addressing: "A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint." To me there is a strong emphasis on singlar. <trm>Do me a favor; Define endpoint. That argument has been raging forever.... </trm> > > * include a recipe for generation of a single IRI from the Address and > ReferenceParameters that can function as an identifier of the resource. > Mark Mc Keown pointed at the W3C Web Architecture description of the > use of URIs which we could borrow from. I am not sure about creating an IRI from the wsa:Address and the wsa:ReferenceParameters. Consider the following EPRs <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 16:05:43 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> and <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 13:07:53 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> If DateCreated is just to inform the service when the EPR was created and is not used by the service for anything else then the two EPRs are for the same WS-Resource. However if I create a name based on a combination of the wsa:Address and wsa:ReferenceParameters I will get two different names, ie I have created URI aliases and divided the network losing some of the goodness of Metcalfes law [7]. cheers Mark [1] http://www.ietf.org/rfc/rfc2396.txt [2] http://www.ietf.org/rfc/rfc3987.txt [3] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ [4] http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/ [5] http://www-unix.gridforum.org/mail_archive/ogsa-naming-wg/2005/11/msg00021.h tml [6] http://www.w3.org/2001/tag/issues.html#endPointRefs-47 [7] http://www.w3.org/TR/webarch/

4 4

My Apologies
by Ziu, Peter 28 Nov '05

28 Nov '05

Hiro, I am sorry I am unable to make this day's meeting. Peter D Ziu 703.883.5168 (o) 571.235.0208 (c) peter.ziu(a)ngc.com (o) 5712350208(a)tmomail.net (sms) pete(a)ziu.net (h)

1 0

MDC Preso review for today ...
by Subramaniam, Ravi 28 Nov '05

28 Nov '05

Hi, Tom: I cannot attend from 2-3 Pacific (i.e. the first half of the meeting). I am at a day long internal F2F and can also be only for 30 minutes between 3-4. I would prefer 3:30-4:00 if it will not disrupt the agenda. I have posted the presentation for review at today's meeting: /projects/ogsa-wg/document/MDC_Preso_-_High_Level_OGSA_Intro_-_4Review/e n/1 <https://forge.gridforum.org/projects/ogsa-wg/document/MDC_Preso_-_High_ Level_OGSA_Intro_-_4Review/en/1> I would like some help to make this more graphic oriented rather than text if possible (especially for the ogsa technical section). Would it be possible for the design team leads/members to provide one slide that would capture the essence of that area graphically? I could try to grab any diagrams that are in raw mode in the document. If people can send me the Powerpoint versions of these pictures, that would be much more helpful. (Pointers to this on Gridforge are also welcome) Thanks! Ravi

1 0

Re: [ogsa-naming-wg] Next telecon
by Frank Siebenlist 27 Nov '05

27 Nov '05

Andrew, Will there be a ws-naming telcon this week? Thanks, Frank. Frank Siebenlist wrote: > 11/29 works for me - the other dates are out because of UK travel... > > -Frank. > > > > Maguire_Tom(a)emc.com wrote: >> Either 11/29 or 12/2 work for me. >> Tom >> >> ------------------------------------------------------------------------ >> *From:* owner-ogsa-naming-wg(a)ggf.org >> [mailto:owner-ogsa-naming-wg@ggf.org] *On Behalf Of *Andrew Grimshaw >> *Sent:* Wednesday, November 16, 2005 3:07 PM >> *To:* ogsa-naming-wg(a)ggf.org >> *Subject:* [ogsa-naming-wg] Next telecon >> >> All, >> >> We have not been keeping up with telecon’s – my fault, and much >> discussion about WS-Names has been occurring in the OGSA-WG. >> >> We need to have a WS-Naming telecon soon. >> >> Please send me your preferences of the following – including “can’t >> make it at all and it is important for me to make it” comments. >> >> 11/29 10AM eastern >> >> 11/30 10AM eastern >> >> 12/1 10AM eastern >> >> 12/2 10AM eastern >> >> Issues on the agenda: (please also send me additional items you would >> like discussed) >> >> Inclusion of Abstractname in reference parameters (in addition to >> existing location) for endpoints that need the abstractname for >> dispatch (recall this topic was introduced because one cannot assume >> that extensibility elements are copied into the header. >> >> Suggested ways to do scalable, high-probability distinct name generation >> >> Wsa:to – use this as the abstract name (Tom’s proposal) >> >> 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

1 0

CFP: International Provenance and Annotation Workshop (IPAW'06)
by Hiro Kishimoto 27 Nov '05

27 Nov '05

Forwarding bounced email. -- Hiro Kishimoto Date: Mon, 21 Nov 2005 21:30:54 +0000 From: Luc Moreau <L.Moreau(a)ecs.soton.ac.uk> Subject: CFP: International Provenance and Annotation Workshop (IPAW'06) Apologies for cross-postings. Please send to interested colleagues. CALL FOR PAPERS International Provenance and Annotation Workshop (IPAW'06) Chicago, Illinois, USA May 3-5, 2006 http://www.ecs.soton.ac.uk/~lavm/IPAW06 Introduction ------------ This workshop is a follow-up to workshops in Chicago in October 2002 (http://www-fp.mcs.anl.gov/~foster/provenance/) and in Edinburgh in December 2003 (http://www.nesc.ac.uk/esi/events/304/) It will further investigate the issues of data provenance, process documentation, data derivation, and data annotation. In scientific and business workflows, typically data is repeatedly copied, corrected, and transformed as it passes through numerous databases or services. Understanding where data has come from and how it arrived in a database or filestore is of crucial importance to the trust a user will put in that data, yet this information is seldom captured properly. The importance of provenance goes well beyond verification; it is closely related to archiving and annotation, also important in the context of scientific and business data. Moreover, it may be used in data discovery. Knowing the provenance of a data item may help a user to make connections with other useful data. Alternatively, a user may want to understand a derivation in order to repeat it with modified parameters, and being able to describe a derivation may help a user to discover whether a particular kind of analysis has already been performed. Annotation is closely related to provenance. End users do more than produce and consume data: they comment on it and refer to it, and to the results of queries upon it. Annotation is therefore an important aspect of communication. One user may want to highlight a point in data space for another to investigate further. They may wish to annotate the result of a query such that similar queries show the annotation. Information for Authors ----------------------- IPAW'06 encourages the submission of theoretical, experimental, methodological, and applications papers related to the issue of provenance and annotation. Papers should be no longer than 8 pages (lncs column format). Submissions will be peer reviewed and selected for presentation at the workshop; papers will be evaluated on the basis of the quality of their technical contribution, originality, soundness, significance, presentation, understanding of the state of the art, and overall quality. There will be proceedings published after the workshop (publisher TBC). Submission instructions ----------------------- To be added here. Topics of interest ------------------ Topics of interest to IPAW'06, include but are not limited to: * models of provenance and annotation * applications requiring provenance, uses cases, methodologies * provenance systems, functionality, protocols, implementation * relationship between provenance, annotation and metadata * provenance-based reasoning and Semantic Web techonologies * relationship between workflows, processes and provenance * security considerations for provenance * scalability issues * granularity of provenance * legal issues relating to provenance * provenance, business processes and compliance Important Dates --------------- Submission deadline: February 10, 2006 Acceptance Notification: March 6, 2006 IPAW'06 date: May 3-5, 2006 Location -------- Chicago, Illinois, downtown Sheraton hotel. Provisional Programme Committee ------------------------------- * Dave Berry, National e-Science Centre, UK * Peter Buneman, University of Edinburgh, UK * Ian Foster (co-chair), Argonne National Lab/University of Chicago, USA * Jim Hendler, University of Maryland, USA * Carole Goble, University of Manchester, UK * Reagan Moore, San Diego Supercomputer Center, USA * Luc Moreau (co-chair), University of Southampton, UK * Jim Myers, National Center for Supercomputing Applications, USA * Mike Wilde, Argonne National Lab/University of Chicago, USA

1 0

BT Messaging Anti-Virus Alert
by bt.email.antivirus＠bt.com 25 Nov '05

25 Nov '05

Notification Of Blocked e-mail - This message is intended for BT employees only. All other recipients: Please ignore this message and accept our apology for any inconvenience (N.B. the links below are private). An e-mail (summarised below) has been blocked at the BT e-mail gateway because it contained an attachment of a potentially dangerous type <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> or a computer virus. Date/Time: "25 Nov 2005 03:21:38" From: "Symantec_AntiVirus_for_SMTP_Gateways(a)capitolindemnity.com" Subject: "Returned mail" Blocked file: "mailtext.zip" Virus Name: "Sober.dam" BT Employees: If there is a legitimate business requirement for this e-mail, please ask the originator to re-send it. You must advise them to follow the special instructions, which you will find at this location <http://antivirus.intra.bt.com/zippass.htm> for re-sending e-mail of this type. They should also ensure that the e-mail is virus-free. More information on blocked attachments can be found at http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> Please do not reply to this email. Thank you. BT Teamconnect Enterprise Solutions British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Generated by: C02

1 0

Returned mail
by Symantec_AntiVirus_for_SMTP_Gateways＠capitolindemnity.com 25 Nov '05

25 Nov '05

--- The message cannot be delivered to the following address. --- chris(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <chris(a)capitolindemnity.com>: Recipient address rejected: No such user (chris(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- marketinginfo(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <marketinginfo(a)capitolindemnity.com>: Recipient address rejected: No such user (marketinginfo(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- russ901(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <russ901(a)capitolindemnity.com>: Recipient address rejected: No such user (russ901(a)capitolindemnity.com)

1 0

BT Messaging Anti-Virus Alert
by bt.email.antivirus＠bt.com 24 Nov '05

24 Nov '05

Notification Of Blocked e-mail - This message is intended for BT employees only. All other recipients: Please ignore this message and accept our apology for any inconvenience (N.B. the links below are private). An e-mail (summarised below) has been blocked at the BT e-mail gateway because it contained an attachment of a potentially dangerous type <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> or a computer virus. Date/Time: "24 Nov 2005 03:41:26" From: "Symantec_AntiVirus_for_SMTP_Gateways(a)capitolindemnity.com" Subject: "Returned mail" Blocked file: "mailtext.zip" Virus Name: "Sober.dam" BT Employees: If there is a legitimate business requirement for this e-mail, please ask the originator to re-send it. You must advise them to follow the special instructions, which you will find at this location <http://antivirus.intra.bt.com/zippass.htm> for re-sending e-mail of this type. They should also ensure that the e-mail is virus-free. More information on blocked attachments can be found at http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> Please do not reply to this email. Thank you. BT Teamconnect Enterprise Solutions British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Generated by: C04

1 0

BT Messaging Anti-Virus Alert
by bt.email.antivirus＠bt.com 24 Nov '05

24 Nov '05

Notification Of Blocked e-mail - This message is intended for BT employees only. All other recipients: Please ignore this message and accept our apology for any inconvenience (N.B. the links below are private). An e-mail (summarised below) has been blocked at the BT e-mail gateway because it contained an attachment of a potentially dangerous type <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> or a computer virus. Date/Time: "24 Nov 2005 03:41:19" From: "Symantec_AntiVirus_for_SMTP_Gateways(a)capitolindemnity.com" Subject: "Returned mail" Blocked file: "mailtext.zip" Virus Name: "Sober.dam" BT Employees: If there is a legitimate business requirement for this e-mail, please ask the originator to re-send it. You must advise them to follow the special instructions, which you will find at this location <http://antivirus.intra.bt.com/zippass.htm> for re-sending e-mail of this type. They should also ensure that the e-mail is virus-free. More information on blocked attachments can be found at http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> Please do not reply to this email. Thank you. BT Teamconnect Enterprise Solutions British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Generated by: C02

1 0

Returned mail
by Symantec_AntiVirus_for_SMTP_Gateways＠capitolindemnity.com 24 Nov '05

24 Nov '05

--- The message cannot be delivered to the following address. --- register(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <register(a)capitolindemnity.com>: Recipient address rejected: No such user (register(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- kkeating(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <kkeating(a)capitolindemnity.com>: Recipient address rejected: No such user (kkeating(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- swreal(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <swreal(a)capitolindemnity.com>: Recipient address rejected: No such user (swreal(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- peter.belesis(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <peter.belesis(a)capitolindemnity.com>: Recipient address rejected: No such user (peter.belesis(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Les.Hill(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Les.Hill(a)capitolindemnity.com>: Recipient address rejected: No such user (les.hill(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- SenTStamas(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <SenTStamas(a)capitolindemnity.com>: Recipient address rejected: No such user (sentstamas(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- entertainment(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <entertainment(a)capitolindemnity.com>: Recipient address rejected: No such user (entertainment(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- vandenick(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <vandenick(a)capitolindemnity.com>: Recipient address rejected: No such user (vandenick(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- cleanearth(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <cleanearth(a)capitolindemnity.com>: Recipient address rejected: No such user (cleanearth(a)capitolindemnity.com)

1 0

Returned mail
by Symantec_AntiVirus_for_SMTP_Gateways＠capitolindemnity.com 24 Nov '05

24 Nov '05

--- The message cannot be delivered to the following address. --- dave(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <dave(a)capitolindemnity.com>: Recipient address rejected: No such user (dave(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- barbjanish(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <barbjanish(a)capitolindemnity.com>: Recipient address rejected: No such user (barbjanish(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- staff(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <staff(a)capitolindemnity.com>: Recipient address rejected: No such user (staff(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- kdettmer(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <kdettmer(a)capitolindemnity.com>: Recipient address rejected: No such user (kdettmer(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- artmp(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <artmp(a)capitolindemnity.com>: Recipient address rejected: No such user (artmp(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- rashah(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <rashah(a)capitolindemnity.com>: Recipient address rejected: No such user (rashah(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- elmbrook(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <elmbrook(a)capitolindemnity.com>: Recipient address rejected: No such user (elmbrook(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- peterbelesis(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <peterbelesis(a)capitolindemnity.com>: Recipient address rejected: No such user (peterbelesis(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Products(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Products(a)capitolindemnity.com>: Recipient address rejected: No such user (products(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- dabeck(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <dabeck(a)capitolindemnity.com>: Recipient address rejected: No such user (dabeck(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- wine(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <wine(a)capitolindemnity.com>: Recipient address rejected: No such user (wine(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- AgamingGC(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <AgamingGC(a)capitolindemnity.com>: Recipient address rejected: No such user (agaminggc(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- amckenzie(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <amckenzie(a)capitolindemnity.com>: Recipient address rejected: No such user (amckenzie(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- ellislakeresort(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <ellislakeresort(a)capitolindemnity.com>: Recipient address rejected: No such user (ellislakeresort(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- one_spook(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <one_spook(a)capitolindemnity.com>: Recipient address rejected: No such user (one_spook(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- sharonsantorum(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <sharonsantorum(a)capitolindemnity.com>: Recipient address rejected: No such user (sharonsantorum(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Manager(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Manager(a)capitolindemnity.com>: Recipient address rejected: No such user (manager(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Regs(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Regs(a)capitolindemnity.com>: Recipient address rejected: No such user (regs(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Wendy(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Wendy(a)capitolindemnity.com>: Recipient address rejected: No such user (wendy(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- matthewgillard(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <matthewgillard(a)capitolindemnity.com>: Recipient address rejected: No such user (matthewgillard(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- treasupd(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <treasupd(a)capitolindemnity.com>: Recipient address rejected: No such user (treasupd(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- aking(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <aking(a)capitolindemnity.com>: Recipient address rejected: No such user (aking(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- sil(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <sil(a)capitolindemnity.com>: Recipient address rejected: No such user (sil(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- jackie(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <jackie(a)capitolindemnity.com>: Recipient address rejected: No such user (jackie(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- employment(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <employment(a)capitolindemnity.com>: Recipient address rejected: No such user (employment(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- realestateone(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <realestateone(a)capitolindemnity.com>: Recipient address rejected: No such user (realestateone(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- kb(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <kb(a)capitolindemnity.com>: Recipient address rejected: No such user (kb(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- wd(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <wd(a)capitolindemnity.com>: Recipient address rejected: No such user (wd(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- ebaysales(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <ebaysales(a)capitolindemnity.com>: Recipient address rejected: No such user (ebaysales(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- bknopp(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <bknopp(a)capitolindemnity.com>: Recipient address rejected: No such user (bknopp(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- free2rhyme(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <free2rhyme(a)capitolindemnity.com>: Recipient address rejected: No such user (free2rhyme(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- paul.abbott(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <paul.abbott(a)capitolindemnity.com>: Recipient address rejected: No such user (paul.abbott(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- gdiller(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <gdiller(a)capitolindemnity.com>: Recipient address rejected: No such user (gdiller(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- cgoeke(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <cgoeke(a)capitolindemnity.com>: Recipient address rejected: No such user (cgoeke(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- rrezac(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <rrezac(a)capitolindemnity.com>: Recipient address rejected: No such user (rrezac(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- abc(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <abc(a)capitolindemnity.com>: Recipient address rejected: No such user (abc(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- LoriL(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <LoriL(a)capitolindemnity.com>: Recipient address rejected: No such user (loril(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- DZeller(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <DZeller(a)capitolindemnity.com>: Recipient address rejected: No such user (dzeller(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- BGrant(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <BGrant(a)capitolindemnity.com>: Recipient address rejected: No such user (bgrant(a)capitolindemnity.com)

1 0

Virus Found in message "hi ive a new mail address"
by Janice VanWagoner 23 Nov '05

23 Nov '05

Symantec AntiVirus found a virus in an attachment you (grdfm-ogsa-wg-outgoing(a)mailbouncer.mcs.anl.gov <grdfm-ogsa-wg-outgoing(a)mailbouncer.mcs.anl.gov>) sent to emailserv(a)tomia247.com. To ensure the recipient(s) are able to use the files you sent, perform a virus scan on your computer, clean any infected files, then resend this attachment. Attachment: mailtext.zip Virus name: Multiple viruses found. Please see individual log messages. Action taken: Quarantine succeeded : File status: Still contains 1 infected items

1 0

RE: [ogsa-wg] Once upon a time or two ...
by Dave Berry 23 Nov '05

23 Nov '05

There are many issues in this discussion that I don't understand , and this seems a key one. Perhaps the participants could read the following and set me straight? The W3C guidelines on the use of URIs (and hence, I presume, IRIs) is that each resource should be identified by a different URI. URIs can be compared. URIs should not be reused to refer to different resources. I don't know whether these guidelines are adhered to in practice, but on paper they seem to provide the uniqueness and comparison functionality that we require. The problem seems to be that WS-Addressing (or perhaps just some uses of it, e.g. some implementations of WSRF) breaks this nice system, by using the URI to name the access mechanism (the web service) rather than the resource being addressed. Frank has suggested on a couple of occasions that we specify how a unique address can be reconstructed from the wsa:to field and the parameters. Given this step, I would assume that the scenario that Frank considers here would not be permitted: > > An EPR-minter can decide to create a new EPR for a resource and reuse > > an Address that was used for an other resource before. So, I have many questions: 1. Is the above characterisation an accurate rendition of the W3C position on URIs and IRIs? 2. Do we want stricter limits than the W3C? 3. Can we profile WS-A as Frank suggests? 4. If (3 and not(2)), does that satisfy our requirements? Another advantage of URIs is that publishers are permitted to use their structure to pass back server-specified information and clients are permitted to parse URIs to extract this information. So an LSF system could include the job-id in a certain part of the URI and clients can extract it as necessary. (Although one could argue whether that was any neater than adding a specific XML field). Best wishes, Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of David Snelling > Sent: 18 November 2005 15:12 > To: Frank Siebenlist > Cc: ogsa-wg; ogsa-naming-wg(a)ggf.org > Subject: [ogsa-wg] Once upon a time or two ... > > Folks, > > Once up on a time or two Frank wrote: > > > Without the proper uniqueness guarantees for the > wsa:Address, the use > > of ws-naming's AbstractName is meaningless. > > > > The EPR with an embedded AbstractName essentially describes > a binding > > between the Address and the AbstractName. > > One could argue that this binding is a bit of a flaky assertion > > without any way to specify time-validity or issuer. > > As a result, one can not see from an EPR alone when it was > issued or > > whether it is still valid or not. > > > > This would yield the undesirable situation that you would have two > > EPRs with identical Addresses and two different AbstractNames > > associated with different resources, and the client would > have no way > > to see which one of the EPRs is valid... > > > > For example, if I have two EPRs with the same Address, > where one EPR > > includes an AbstractName that identifies MyBankAccount and > the other > > includes an AbstractName identifying YourBankAccount, then > one of us > > will not be happy with that situation... > > > > In order to avoid this ambiguity, we need the guarantee from the > > EPR-minter that Address values will not be reused for different > > resources: for all times, the Address should either refer > to that one > > and only resource, or it should be invalid (and it is allowed to > > change between those two states). > > Furthermore, the EPR-minters should ensure that globally unique > > Addresses are used for a resource such that different > EPR-minters do > > not (accidentally) use the same Address for different resources. > > The described uniqueness properties of the Address constitutes a > > required EPR-minter profile for the use of AbstractNames. > > > > This issue has yet to be addressed to my satisfaction. There > have been > a number of email exchanges in response to it on several > occasions, but > none of these threads actually deal with the issue. > > Put simply, if you don't put globally-unique-in-space-time > requirements > on your address (GSR in OGSI speak*) then any similar > requirements you > put on an Abstract Name (GSH in OGSI speak) are wasted. > > I believe that answering this issue will help clarify many of > the other > threads (miss) associated with this issue. > > In particular, I believe Frank is right. Therefore, if an EPR > is going > to be a WS-Name, the wsa:Address MUST have the same uniqueness > properties as the Abstract Name. Then if the answer to the question, > "Why do this uniqueness stuff twice?", is "I don't know!", then it > seems logical to me that a WS-Name is a profiled EPR along the lines > proposed by Tom M. > > Thoughts? > > Historical Footnote: > > * Note: OGSI addressed this issue in GSRs by requiring that clients > could detect when the GSRs were stale and that services > reject them if > a client attempted to use them. GSHs had uniqueness > constraints placed > on them. > > -- > > 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) > >

3 2

Data architecture requirements on naming
by Dave Berry 23 Nov '05

23 Nov '05

Dear All, Recent discussions on the OGSA data architecture have raised two use cases that may affect the naming discussion. Both involve the mapping of one "abstract" (for some meaning of "abstract") name to multiple possible "concrete" names. A further step is then required to choose the best "concrete" name, according to the policies required by the client. We are wondering whether the WS-Name/EPR resolution services can be modified to support these functionalities. Note: here, "abstract" names may or may not have the same meaning as abstract names in the proposed WS-Names spec. This is an issue that needs clarification. Case 1 is when we are dealing with replicated data. It is common to have an "abstract" name that represents a given file, table or query result that is stored someone in the system. This is then resolved to one of multiple copies. The client typically wants the copy with the best response time (which will be some function of latency and bandwidth). Case 2 is when we are dealing with data stored at a certain location and the data may be accessed by several different protocols (e.g. GridFTP, HTTP, ...). The client (or transfer service) wants to map the "abstract" name to the fastest protocol that it can handle. In each case, we could take one of two approaches: (A) resolve the "abstract" name to a list of "concrete" names, and use a separate selection service to choose among them (B) pass the appropriate policy specification to the resolver service, which will then return the appropriate "concrete" name. Note: (B) could be considered (and even implemented) as a composition of the resolver and selection services in (A). Would it make sense to specify either one of these functionalities as part of the resolver services considered in WS-Naming? E.g. the operations could return a list instead of a single EPR (option A) or they could return a single EPR as now but take a policy argument (option B). Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

2 1

RE: [ogsa-d-wg] Data architecture requirements on naming
by Hiro Kishimoto 22 Nov '05

22 Nov '05

Peter's email bounced. -- Hiro Kishimoto Subject: RE: [ogsa-d-wg] Data architecture requirements on naming Date: Tue, 22 Nov 2005 13:36:31 +0100 From: "Peter Kunszt" <Peter.Kunszt(a)cern.ch> To: "David Berry" <daveb(a)nesc.ac.uk>, <ogsa-naming-wg(a)ggf.org>, "ogsa-wg" <ogsa-wg(a)gridforum.org>, <ogsa-d-wg(a)gridforum.org> hi dave in our experience, case (B) is not being used by clients. the reason is that the policies that are put in place to find the 'best' concrete replica are very application specific and are usually implemented by the applications themselves. what turned out to be much more useful was to present the list of replicas when asked for it with some measured qualifyers that the grid can provide, i.e. predicted access cost, latency, time to wait (queues) or whatever is available so that the application can resolve the 'best' replica based on any model/policy they may want to apply. it turned out that implementing a generic policy enforcer is very difficult and what you end up doing is to provide a python interpreter so that the applications can write their own policy scripts... hope this helps, cheers, peter >> -----Original Message----- >> From: owner-ogsa-d-wg(a)ggf.org >> [mailto:owner-ogsa-d-wg@ggf.org] On Behalf Of Dave Berry >> Sent: 22 November 2005 11:30 >> To: ogsa-naming-wg(a)ggf.org; ogsa-wg; ogsa-d-wg(a)gridforum.org >> Subject: [ogsa-d-wg] Data architecture requirements on naming >> >> Dear All, >> >> Recent discussions on the OGSA data architecture have raised >> two use cases that may affect the naming discussion. Both >> involve the mapping of one "abstract" (for some meaning of >> "abstract") name to multiple possible "concrete" names. A >> further step is then required to choose the best "concrete" >> name, according to the policies required by the client. We >> are wondering whether the WS-Name/EPR resolution services can >> be modified to support these functionalities. >> >> Note: here, "abstract" names may or may not have the same >> meaning as abstract names in the proposed WS-Names spec. >> This is an issue that needs clarification. >> >> Case 1 is when we are dealing with replicated data. It is >> common to have an "abstract" name that represents a given >> file, table or query result that is stored someone in the >> system. This is then resolved to one of multiple copies. >> The client typically wants the copy with the best response >> time (which will be some function of latency and bandwidth). >> >> Case 2 is when we are dealing with data stored at a certain >> location and the data may be accessed by several different >> protocols (e.g. GridFTP, HTTP, ...). The client (or transfer >> service) wants to map the "abstract" name to the fastest >> protocol that it can handle. >> >> In each case, we could take one of two approaches: >> >> (A) resolve the "abstract" name to a list of "concrete" >> names, and use a separate selection service to choose among them >> >> (B) pass the appropriate policy specification to the resolver >> service, which will then return the appropriate "concrete" name. >> >> Note: (B) could be considered (and even implemented) as a >> composition of the resolver and selection services in (A). >> >> Would it make sense to specify either one of these >> functionalities as part of the resolver services considered >> in WS-Naming? E.g. the operations could return a list >> instead of a single EPR (option A) or they could return a >> single EPR as now but take a policy argument (option B). >> >> Best wishes, >> >> Dave Berry >> Research Manager, National e-Science Centre >> 15 South College St., Edinburgh >> Tel: +44 131 6514039

1 0

Re: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)
by Mark McKeown 22 Nov '05

22 Nov '05

Hi Frank, I have made some comments inline... First to remove some confusion about IRIs that have appeared in previous mails in this thread. URNs and URLs are URIs[1], IRIs[2] are an extension of URIs to support extra charactors. A URI may or may not map to a real physical address. The WS-Addressing specification[3] defines a number of URIs that do not map to real network locations (eg http://www.w3.org/2005/08/addressing/anonymous) WS-Addressing mandates that the wsa:Address element is an absolute IRI. > > * include a profile for the use of the Address and ReferenceParameters > that ensure the proper uniqueness property in time and space of the > reference. Tom Maguire suggested to use the wsdl binding of the address > which sounded very promising. I am not sure I have understood Tom's argument correctly so I will try and repeat it here in order to be corrected... TomM suggested using the wsa::Address as the name, I understand his argument as being that with the WSDL binding for WS-Addressing you can include the service part of the WSDL into the wsa:Metadata of the EPR, the service part may contain a number of network endpoints indicating that the WS-Resource is available at a number of locations. >From 'Web Services Addressing 1.0 - WSDL Binding' [4]: "In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint." In this case the wsa:Address could be a URN (or URI that is not an actual network location) and the client could look to the wsa:Metadata to find the actual network location of the WS-Resource. Quoting Tom[5]: "Let me be very clear about this an EPR does not have a 1 to 1 correspondence with a protocol and binding address. It MUST be true that an EPR can support multiple protocols and their associated addresses." I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when discussing including WSDL components in the EPR, there is no obligation. I think most services will only use one transport protocol so I think this feature will not be used often - even if a service does use more than one transport/port there is no requirement to advertise this in the EPR. Also there is no transport bindings available for WS-Addressing - for example the SOAP bindings tells us to take the wsa:Address element and put it into the wsa:To element in the SOAP header but does not tell us what to do with it with regards to the transport protocol (eg most people use the wsa:Address element to create a RequestURI which they set as the POST HTTP Header when using HTTP - this issue has been raised with the W3C TAG[6]). Quoting WS-Addressing: "A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint." To me there is a strong emphasis on singlar. > > * include a recipe for generation of a single IRI from the Address and > ReferenceParameters that can function as an identifier of the resource. > Mark Mc Keown pointed at the W3C Web Architecture description of the use > of URIs which we could borrow from. I am not sure about creating an IRI from the wsa:Address and the wsa:ReferenceParameters. Consider the following EPRs <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 16:05:43 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> and <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 13:07:53 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> If DateCreated is just to inform the service when the EPR was created and is not used by the service for anything else then the two EPRs are for the same WS-Resource. However if I create a name based on a combination of the wsa:Address and wsa:ReferenceParameters I will get two different names, ie I have created URI aliases and divided the network losing some of the goodness of Metcalfes law [7]. cheers Mark [1] http://www.ietf.org/rfc/rfc2396.txt [2] http://www.ietf.org/rfc/rfc3987.txt [3] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ [4] http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/ [5] http://www-unix.gridforum.org/mail_archive/ogsa-naming-wg/2005/11/msg00021.… [6] http://www.w3.org/2001/tag/issues.html#endPointRefs-47 [7] http://www.w3.org/TR/webarch/

2 1

Proposal to split "Secure channel" profile
by Andreas Savva 22 Nov '05

22 Nov '05

During the review of the "Basic Security Profile - Secure Channel" today it was pointed out that Section 3.4 (Security Token), Section 4 (SAML Token Profile 1.0) and Appendix D (Key Information Exchange) are 'more basic' than the other parts of the profile and that it would be worth splitting them off in a separate document. Doing so would allow other future security profiles (e.g., an MLS profile) to use these sections without creating unnecessary dependencies with the Secure Channel (TLS) profile. Therefore the proposal is to separate these sections in an "OGSA Basic Security Profile" document. This document would expose the claim required to satisfy the WSRF BP security profile requirements (http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0) but would have no normative dependency on the WSRF BP. In addition it was proposed that this profile would have explanatory text stating that it is defining an 'anonymous channel' (one requiring no security or authentication for service interaction) and would also expose the following claim: http://www.ggf.org/namespaces/2005/11/OGSABasicSecurityProfile-1.0-Anonymou… (This second proposal is optional and is primarily to reduce the number of security profiles we have to write.) The "Secure Channel" profile will then reference the "OGSA Basic Security Profile" and will expose in turn the following conformance claims: http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0 (as required for composition with the WSRF BP) and http://www.ggf.org/namespaces/2005/08/OGSABasicSecurityProfile-1.0-SecureCh… Comments on the list, or please join next Monday's call where this proposal is scheduled to be discussed. Andreas >From the minutes: > - 1698: Strictly speaking the features described in section 3.4 and > section 4 are orthogonal to the rest of the profile. Tokens, and > the key exchange mini-specification would apply to both TLS and > MLS. > - If this text is left here then the MLS profile would have to > depend on this profile; or worse, duplicate the same text. > - Frank proposed that if these sections are needed in general then > it might be worth deleting these sections from the Secure > Channel Profiel and adding them to the WSRF Basic Profile. > - Agreed, in principle, to remove the sections from this spec. and > discuss how to make them apply to any profile. > - Andreas proposed that these sections should be part of a Basic > Security Profile and that Profile could then be combined with > the WSRF BP or be referenced by the Channel profiles. The Claim > URI mechanism defined in the WSRF BP allows multiple Security > profiles to be composed with it so there would be no problem > with this approach. > - Hiro proposed that such a Basic Security Profile could also > serve as an 'anonymous' channel profile (one that makes no > statements on channel security) and could also solve the problem > of having a separate, essentially empty, profile document with > no security statements. > - Andreas was tasked to write up the proposal for splitting up the > Secure Channel Profile and send it to the list to collect > feedback from stakeholders not on the call. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

NO call on Wednesday (Nov. 23)
by Hiro Kishimoto 22 Nov '05

22 Nov '05

Hi all, Since Nov. 24 is Thanksgiving, we agreed to have *NO* call on Nov. 23 Wednesday. Next call is Nov. 28th. Nov. 28 (Mon) Architecture & Glossary 1.5 Basic Security Profile discussion MDC presentation review Nov. 30 (Wed) EMS architecture Information model & CIM profile Dec. 5 (Mon) Architecture & Glossary 1.5 Basic Security Profile review Dec. 7 (Wed) Two naming requirement docs review EMS architecture Information model & CIM profile Happy Thanksgiving, ---- Hiro Kishimoto

1 0

Teleconference minutes - 21 November 2005
by Andreas Savva 22 Nov '05

22 Nov '05

Minutes attached. Thanks to Alan Sill for his excellent notes of the AuthZ discussion. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051121/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconfererence - 21 November 2005 ======================================== * Participants Pete Ziu (Northrop Grumman) Von Welch (NCSA) Alan Sill (Texas Tech Univ.) Frank Siebenlist (ANL) Andreas Savva (Fujitsu) Takuya Mori (NEC) Mark Morgan (UVa) Tom Maguire (EMC) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu Dave Berry (NeSC) Michael Behrens (R2AD, LLC) Apologies: Ellen Stokes Minutes: Andreas Savva, Alan Sill * November 16 minutes approved with no changes * OGSA AuthZ Joint Call ** Background Alan described OSG, EGEE and made mention of GridShib efforts, and the desire to support a more standards-based approach to attribute-based authorization. A strong desire exists both within the user communities and at the funding agency level, he believes, for a standards-based approach to authorization that can interoperate with and be complementary to the existing standards-based approach to CA operations being taken by the CAOps-WG and the PMA technical community. (cf. http://gridpma.org for the IGTF = International Grid Trust Federation and its member organizations.) He also noted that there is ongoing research and work being done to extend and supplement the "classic PKI" authentication profile, for example with the Short-Lived Credential Service (SLCS) profile being considered by TAG PMA (The Americas Grid PMA) and about to come up for voting there. ** Future directions (OGSA services, federated authentication) Frank said most important task is to come up with an improved authorization query interface. The present one is based on SAML 1.1 and lacks features needed to communicate easily such attributes as groups and roles. Version 2 of the OGSA AuthZ specification needs to define interfaces so such attributes can be communicated more easily. The hope is to leverage part of the work done in the OASIS XACML TC for the XACML 3.0 spec. (Frank is a member of the TC.) The TC has come to some agreement on how to proceed and is preparing to write up WSDL, etc. Ideally this could be used as is provided it fits the Grid requirements. At the last GGF, the two groups had separate face-to-face meetings at the same time, which interfered with progress. Alan noted that there was good attendance at the AuthZ GGF15 wrap-up meeting, nonetheless. Von Welch agreed with the above summary of priorities, but noted that there is a need for far more people and fresh blood. Alan added that he would like to see representation from at least 3 communities: the OSG Privilege Project authors, the LCG Joint Security Group, and members of the Shibboleth community who are interested in working in the direction of international standards. Hiro asked what would be required to use the XACML v3 query i/f with the OGSA WSRF BP. Frank and Tom agreed that the XACML i/f would be complementary to the BP and it should be possible to compose the two. There is no reason to have a WSRF-specific XACML i/f. Hiro asked whether standardizing on the schema or alternatively on a language for defining attribute characteristics is preferable. Alan responded that from his point of view, the latter (an attribute language) is preferable, as schema can become outdated and attribute spaces are by their nature extensible, and that a possible reason for failure of previous AuthZ efforts might be due to attempts to overly specify the schema. (Since it is not possible to do an exhaustive definition of the attributes.) ** OGSA-AuthZ WG status update (specs) - Is there a plan to produce a new version of the Attributes specification? It is important for people who are implementing this specification to come forward and join the discussion. The WG has to see what is being adopted and what needs to be done before moving forward. Alan volunteered to take this discussion to VOMS and try to get people to join. - What is the status of the submitted AuthZ documents? The Attributes document completed its public comment period and was returned back to the authors for revision. There was some uncertainty on the call whether this document was pulled out of the process altogether or whether it was going to move forward after changing its type to Experimental. There was also an issue with making it WSRF based, or combinable with the OGSA WSRF profile. Von will check the status of this document. ** Next steps Hiro suggested to have another joint call in Dec.; it was set for the OGSA call on Dec. 19 (Mon.). Hiro also asked whether AuthZ WG members can attend the next OGSA F2F in Sunnyvale in January (week of 16). - It was pointed out that the AuthZ specific discussion is likely to be occupy a very small slot (1-2 hours) during the 5 day meeting. - Frank will attend in person. - Von and Alan may join by phone if it is not possible to attend in-person. Agreed to advertise both the joint call and the F2F and try to get wider participation. * Profile Definition Review - Tom changed his Affiliation. - Consensus on the call not to add implementation status examples. - Agreed that the change from "In other words" to "For example" in the last sections and related changes in wording are appropriate. - Other minor wording changes. Tom will accept all changes, post a new draf and announce a final call to list, lasting to next week Wednesday. (This is to allow for people who may be on holiday this week.) Tom will also reply to comments on the public forum. * Security Profile - Secure Channel Review - Using version sent out by Hiro to the list. ** Tracker review (Numbers correspond to tracker artifacts) - 1657: added; close. - 1658: MLS is dropped; close. - 1659: No problem using SSL; close. - 1662: Checked that there are no significant changes that affect this profile; updated; fixed. - 1663: Updated to remove dependency; fixed. - 1685: Added secure channel definition: fixed - Does any part of this definition imply encryption? Yes, integrity does. - 1697: Revised the list but the explanatory text still needs work to make clearer what the profile is doing. It is ok to combine some of these items if it will make the explanation easier. - Takuya to draft some text and review with Andreas - 1698: Strictly speaking the features described in section 3.4 and section 4 are orthogonal to the rest of the profile. Tokens, and the key exchange mini-specification would apply to both TLS and MLS. - If this text is left here then the MLS profile would have to depend on this profile; or worse, duplicate the same text. - Frank proposed that if these sections are needed in general then it might be worth deleting these sections from the Secure Channel Profiel and adding them to the WSRF Basic Profile. - Agreed, in principle, to remove the sections from this spec. and discuss how to make them apply to any profile. - Andreas proposed that these sections should be part of a Basic Security Profile and that Profile could then be combined with the WSRF BP or be referenced by the Channel profiles. The Claim URI mechanism defined in the WSRF BP allows multiple Security profiles to be composed with it so there would be no problem with this approach. - Hiro proposed that such a Basic Security Profile could also serve as an 'anonymous' channel profile (one that makes no statements on channel security) and could also solve the problem of having a separate, essentially empty, profile document with no security statements. - Andreas was tasked to write up the proposal for splitting up the Secure Channel Profile and send it to the list to collect feedback from stakeholders not on the call. * UML Tool Choice - No opposition on the list or the call for the Rational choice. - Agreed that there are a couple of things that need to be cleared up, and until that time the choice is still tentative. - Hiro to follow up with Ellen on the IBM liaison and with the GGF Office and make sure that we can use the tool for GGF work. - Mike proposed that CDs should be made available at the next F2F. * OGSA 1.5 review - Postponed due to lack of time. * Next call - OGSA 1.5 review - Basic security profile discussion

1 0

[Fwd: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)]
by Frank Siebenlist 22 Nov '05

22 Nov '05

Sorry, forgot to cross-post... -Frank.

1 0

Teleconference minutes - 14 November 2005
by Andreas Savva 21 Nov '05

21 Nov '05

Minutes attached. * UML tool selection * Israel Workshop participant from OGSA-WG * Basic security profile review https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051114/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 14 November 2005 ====================================== * Participants Michael Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Takuya Mori (NEC) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Ellen Stokes (IBM) Jem Treadwell (HP) * Nov 9 minutes approved with no changes * UML tool selection Michael reviewed a number of UML tools and prepared a summary that was sent to the list before the call. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html ** Requirements - Generating code is not a strong requirement for OGSA at this time. - Importing/exporting XMI from other tools probably falls in the nice-to-have category. (But Michael clarified that sometimes even importing portions of diagrams prepared by someone else using the same tool caused problems.) - Community or free editions of some commercial tools often add banner text on printouts. It should count against that tool. - Since the tools must be free other tools such as MS Visio are not reviewed. ** Tool summary - Poseidon: Very slow starting up---when clicking on a project icon it took about 45sec to start up. But after that is quite usable and the functionality is good. - Rose: A big download but the functionality and performance is good. A lot of features. But there are many editions and the RSM version may be sufficient. - It took about 1 week for a reply to the GGF license request. And Michael still has to talk with someone at IBM about receiving a license. - Jude: Also quite good, but would need the Pro version (not free) for import/export. - Visual Paradigm was also quite good. ** Discussion - Preference on the call for Rational. It is a full featured, unlimited, version. It has support for all the features needed and performance is good. Finally IBM's standards license should give all GGF participants access to same version at no extra cost. - In the case of DMTF there is a designated IBM representative within DMTF that participants can apply to and get a license. A similar arrangements should be possible within GGF. Action: Ellen will check who can be IBM's contact within GGF for Rational licenses. (It is probably going to be one of Dave Martin or Jay Unger.) Action: Hiro will send out a short memo on the rough consensus to the list. Ask for comments and make a final decision on the next call. * Israel Workshop participant from OGSA-WG OGSA-WG has had a similar request for participation to a workshop in Israel a few months ago but no one was able to go at that time. This time the proposal is to time the workshop before or after GGF16 since people are going to be nearby. The workshop organizers are flexible about the timing. - Since GGF16 runs from Monday to Thursday and OGSA-WG is planning a F2F on Friday the workshop is probably going to be the week before or the week after. - It would be a good idea to check whether the workshop organizers are willing to pay expenses. Many people have budget restrictions and many not be able to justify it to their companies otherwise. - No volunteer on the call - On a side note, Jem suggested that doing a webcast on OGSA and then providing access to the recording may also be a way to help interested parties engage with OGSA - WS-I has done something similar recently and it seems a good way to share information - OGSA, and in particular Ravi, is already preparing for the MDC presentation Action: Hiro to check with Steve Crumb whether expenses will be covered by the workshop organizers. Action: Hiro to ask Steve Crumb how far GGF can support an OGSA webcast. * Basic security profile review Draft uploaded by Takuya before the call. Reviewed trackers and other changes in the text. - Issue 1685: Added definition of secure channel. Agreed to modify to say 'mutual authentication' instead and also add a more specific word such as 'layer' to transport - Line 105: Add key info exchange to the list - Also since secure channel is defined further up try to use similar terminology here to make clearer what is being addressed by the profile. - Issue 1663: Deleted text on normative dependency to WSRF BP. - Should also delete the 'ogsa-bp' namespace from Table 1 (not used) - And the 'wsse' namespace; it is not used in main document and there is a separate table in the appendix that includes it. - On line 118 and also in the Abstract there is some text that still seems to imply sole use of this profile by the WSRF BP. Needs revision. Andreas volunteered to review the new text. - Issue 1662: Decided to use the latest version of the spec. - Issue 1660: Verified, closed. - R0321: Is this compliance statement needed? It seems MLS related and not needed by TLS. - Takuya will check whether it is needed; delete otherwise. - Plan: - Prepare a new draft by Wed - Do the final review next Monday - Make the final call after that and submit by Nov'30 - (Cannot do earlier given the Thanksgiving holiday) * Glossary review Jem has followed up on some issues with the submitters and confirmed that no action is needed. - Issue 1159 : no action; close - Issue 1333 : no action; close - Further review postponed. - Agreed that from now on a 10-15 minute slot must be reserved on *each call* for a brief glossary review. * Next call - Per agreed schedule. - Note: NO CALL on Wednesday, 11/23 (Thanksgiving holidays)

3 2

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

21 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 21st 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: 1121 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 (Nov. 16) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051116/en/1 Agenda bashing 2) OGSA-AughZ WG joint call (20 min) OGSA-AughZ WG status update (proposed specs, re-charter) Future directions (OGSA services, federated authentication) 3) Basic Security Profile document *final* review (40 min) Takuya uploaded revised draft to GridForge https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… > <Basic security profile - secure channel - submission plan> > - Prepare a new draft by Wed (done) > - Do the final review next Monday (Nov. 21) > - Make the final call after that and submit by Nov'30 > (Cannot do earlier given the Thanksgiving holiday) 4) common UML tool selection (20 min) Make decision on common UML tool > - Preference on the call for Rational. It is a full featured, > unlimited, version. It has support for all the features needed and > performance is good. Finally IBM's standards license should give > all GGF participants access to same version at no extra cost. Mike's tool comparison summary http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html Hiro's proposal (Rational) http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00068.html 5) OGSA architecture and glossary 1.5 (30 min) Infrastructure section review (minus Naming) Acronyms in Glossary 6) Profile definition public comments review (if time permits) Greg passed back "profile definition" to ogsa-wg accept or reject all public comments https://forge.gridforum.org/forum/forum.php?forum_id=568 Jem and Tom are working on the new draft 7) Wrap up AOB <NEXT CALL> Nov. 23 (Wed) NO call (Thanksgiving) Nov. 28 (Mon) Architecture & Glossary 1.5 Profile Definition Update Nov. 30 (Wed) EMS architecture information model & CIM profile Dec. 5 (Mon) Architecture & Glossary 1.5 Profile Definition *final* review Dec. 7 (Wed) two naming requirement docs review EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Once upon a time or two ...
by David Snelling 18 Nov '05

18 Nov '05

Folks, Once up on a time or two Frank wrote: > Without the proper uniqueness guarantees for the wsa:Address, the use > of ws-naming's AbstractName is meaningless. > > The EPR with an embedded AbstractName essentially describes a binding > between the Address and the AbstractName. > One could argue that this binding is a bit of a flaky assertion > without any way to specify time-validity or issuer. > As a result, one can not see from an EPR alone when it was issued or > whether it is still valid or not. > > An EPR-minter can decide to create a new EPR for a resource and reuse > an Address that was used for an other resource before. > This would yield the undesirable situation that you would have two > EPRs with identical Addresses and two different AbstractNames > associated with different resources, and the client would have no way > to see which one of the EPRs is valid... > > For example, if I have two EPRs with the same Address, where one EPR > includes an AbstractName that identifies MyBankAccount and the other > includes an AbstractName identifying YourBankAccount, then one of us > will not be happy with that situation... > > In order to avoid this ambiguity, we need the guarantee from the > EPR-minter that Address values will not be reused for different > resources: for all times, the Address should either refer to that one > and only resource, or it should be invalid (and it is allowed to > change between those two states). > Furthermore, the EPR-minters should ensure that globally unique > Addresses are used for a resource such that different EPR-minters do > not (accidentally) use the same Address for different resources. > The described uniqueness properties of the Address constitutes a > required EPR-minter profile for the use of AbstractNames. > This issue has yet to be addressed to my satisfaction. There have been a number of email exchanges in response to it on several occasions, but none of these threads actually deal with the issue. Put simply, if you don't put globally-unique-in-space-time requirements on your address (GSR in OGSI speak*) then any similar requirements you put on an Abstract Name (GSH in OGSI speak) are wasted. I believe that answering this issue will help clarify many of the other threads (miss) associated with this issue. In particular, I believe Frank is right. Therefore, if an EPR is going to be a WS-Name, the wsa:Address MUST have the same uniqueness properties as the Abstract Name. Then if the answer to the question, "Why do this uniqueness stuff twice?", is "I don't know!", then it seems logical to me that a WS-Name is a profiled EPR along the lines proposed by Tom M. Thoughts? Historical Footnote: * Note: OGSI addressed this issue in GSRs by requiring that clients could detect when the GSRs were stale and that services reject them if a client attempted to use them. GSHs had uniqueness constraints placed on them. -- 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

RE: naming issues resolution process discussion (Re: [ogsa-wg] Proposed agenda for Nov. 16 call)
by Ian Foster 17 Nov '05

17 Nov '05

Andrew: I'm not ignoring you: either I hadn't heard you express the use cases below (I haven't been on all the calls) or I hadn't internalized you doing so. I appreciate you taking the time to write them down: this information is very helpful. Three comments on the use cases: 1) These use cases, like Chris Smith's, do not imply a need for names that are "globally unique in time and space." The only requirement is that names be unique with respect to the scope of the activities that the user wants to monitor or track. This might seem a minor point, but I think it's an important one: as Chris pointed out, a sensible key to use as a name in #1 could be, in some circumstances, e.g. the LSF jobid. That choice of key is prohibited by the current WS-Name definition. 2) In use case #1, I think you assume that a notification has the form "job with epr E has status S." Certainly, if that was the case, then you'd face the problem of determining which job that EPR referred to, something that you can't do without the ability to compare EPRs. But in WS-Notification, at least, when a client subscribes to notifications it can supply, as the callback address, an EPR to a unique WS-Resource. So the notification delivers the message "status S" to the subscription for job with epr E. Thus, there is no need to include a key in the EPR for the purpose of disambiguation. 3) Use case #2 makes sense to me. I could also do this without an AbstractName, by passing around an XML structure containing an application-specific key and the EPR--or, more likely, embedding the EPR in a larger application-specific structure that I have created for other purposes. But clearly an AbstractName could usefully be applied here. Ian. At 12:03 PM 11/16/2005 -0500, Andrew Grimshaw wrote: >Ian, > >I did give a scenario you just chose to ignore it. Here are two: > >1) As a client of BES I want to be able to keep track of the activities I >start. Suppose I have one hundred going. I want to build a data structure >that keys off of the activity. Id like the handle I get back from the BES >container (which is basically acting like a factory) to have a keyin it I >can use so that when I get notifications about the activity, or some other >services wants to talk about the activity I have some way to associate and >search for the activity information I am keeping. > >2) Using the WS-name (specifically the abstract name) to correlate >information flows about an activity. (This is the example I have used >several times.) > > > >The requirement in both cases is to be able to identify when two EPRs >refer to the same activity. > > > >Andrew > > > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Wednesday, November 16, 2005 9:33 AM >To: Hiro Kishimoto; Andrew Grimshaw; Tom Maguire; Frank Siebenlist; Smith >Chris; Mark Morgan >Cc: Savva Andreas >Subject: Re: naming issues resolution process discussion (Re: [ogsa-wg] >Proposed agenda for Nov. 16 call) > > > >Hiro: > >Ahead of the call, I'd like to raise the question again of what >application requirements motivate the use of WS-Names in BES. I asked this >on the last call, and my question wasn't answered. I asked the question >again via email, and Chris replied with what turned out to be a >requirement for something different than WS-Names. I think it would be >really helpful to have a list of requirements as a basis for discussion. > >Ian.

1 0

Teleconference minutes - 16 November 2005
by Andreas Savva 17 Nov '05

17 Nov '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051116/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 16 November 2005 ====================================== * Participants Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Jem Treadwell (HP) Apologies: Steven Newhouse, Ellen Stokes, Michael Behrens Minutes: Andreas Savva * November 15 minutes approved with no changes * January 2005 F2F Update Reminder: Scheduled for week of Jan 16 at Sunnyvale (Fujitsu) Agenda discussion: - ByteIO: A one hour slot should be sufficient to give an update on group activities. - The specification documents have already been submitted and it is expected that by January the main focus will be on interoperability testing. - Naming session - Not sure if it should include RNS. Andrew will check Manuel's plan and the status of the RNS specification. - Allocate a WS-Management BP slot? - There has been no update---delayed due to other developments. - An MS volunteer to lead this effort is the main requirement. - Tom will ask Dave Snelling and Tony Hey for an update. - Allocate OGSA & Glossary 1.5 slot? - It should not be necessary. Other actions: - Andreas to re-check network setup at Fujitsu * GGF16 F2F Update - Planning a F2F on Friday after GGF16 - No confirmation from Athens University for a room yet. - Confirmed room at IBM. It is a 10 minutes ride from the hotel. - No discussion on how many sessions to have yet. Andrew suggested doing an "OGSA town hall" meeting to get more feedback from the community. [This would be in addition to or in place of Outreach.] * Naming issue resolution process ** Review of status - The BES-WG has not had a chance to discuss the naming issue on a teleconference yet. Given that this week is SC05 and next week is Thanksgiving it will take a few weeks. - The OGSA Naming WG will also have to discuss the related issue of the AbstractName definition. - The wider discussion within OGSA on Naming policy is more related to BES and not so much to the WS-Naming definition. Agreed that it will likely take about 3 weeks to reach a decision due to the various schedule issues, and given that some people prefer to discuss the issues on teleconfs rather than using e-mail. ** Next steps - Accepted Hiro's proposal to create a document (two in fact) on the requirements and issues and use it to drive the consensus process - Get a shared understanding of issues, requirements and people's positions. 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 2. Tom will add issues from the list discussion to the policy document, including BES related issues. * EMS discussion - Postponed technical discussion; no quorum. - Hiro and Andreas are working on refining the scenario list in section 3. They will send a proposal to list. * Information Model discussion - Postponed technical discussion; no quorum. - Andrew will talk with Ellen and Fred on how best to continue. * Glossary review - Messaging service: keep as is - Metadata: check the OGSA document. If there has not been any change then leave as is. (Andreas and Jem) - portType: delete WSDL 2.0 definition. Check the OGSA document and delete any mention to WSDL 2.0, if it exists. (Andreas and Jem) - Provisioning: keep as is. Maybe not the only definition but it is the way it is used in the OGSA document. - Task: Review the OGSA document and delete if not used - UUID: leave as is - WSDL: Accepted Jem's proposal - Acronyms: Need to review separately. In principle add the ones defined in OGSA or grid specific ones. No need to add the general ones. - IRI: May be added if it ends up being used in the OGSA document. A reference to the appropriate RFC number should be sufficient. * UML Tool choice - Rational is the choice from the last call. - Review and finalize decision next call. * Next call ** Monday - UML tool - Basic Security Profile - AuthZ joint call - Profile Definition public comment revision - OGSA 1.5 Infrastructure section review (minus Naming) ** Wednesday (No call)

1 0

[ogsa-wg | Secure Channel 1.0 - 1698] - R0321: Is this compliance statement needed? It seems MLS related
by Sourceforge Tracker Monitor 16 Nov '05

16 Nov '05

A new artifact has been added: 1698 Submitted by: Takuya Mori Submitted date: 2005-11-17 02:13:34 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1698&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1698&group_id…) Summary: - R0321: Is this compliance statement needed? It seems MLS related Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1698 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-11-17 02:13:34 Submitted By: Takuya Mori Submit Date: 2005-11-17 02:13:34 Assigned To: &lt;None&gt; File(s): <None> Description: - R0321: Is this compliance statement needed? It seems MLS related and not needed by TLS. View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1697] Line 105: Add key info exchange to the list
by Sourceforge Tracker Monitor 16 Nov '05

16 Nov '05

A new artifact has been added: 1697 Submitted by: Takuya Mori Submitted date: 2005-11-17 02:08:38 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1697&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1697&group_id…) Summary: Line 105: Add key info exchange to the list Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1697 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-11-17 02:08:38 Submitted By: Takuya Mori Submit Date: 2005-11-17 02:08:38 Assigned To: &lt;None&gt; File(s): <None> Description: - Line 105: Add key info exchange to the list - Also since secure channel is defined further up try to use similar terminology here to make clearer what is being addressed by the profile. View the Secure Channel 1.0 : 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

Common UML tool selection
by Hiro Kishimoto 16 Nov '05

16 Nov '05

Hi all, At November 14th tele-conference, OGSA-WG reviewed Mike's excellent UML tool survey. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html Attendees for this call thought Rational is the best among others. > - Preference on the call for Rational. It is a full featured, > unlimited, version. It has support for all the features needed and > performance is good. Finally IBM's standards license should give > all GGF participants access to same version at no extra cost. I want to make a final decision on the next Monday call. Please post your comments and preference to the list before Monday. Thanks, -- Hiro Kishimoto From telecon minutes; > * UML tool selection > > Michael reviewed a number of UML tools and prepared a summary that > was sent to the list before the call. > http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html > > ** Requirements > - Generating code is not a strong requirement for OGSA at this time. > - Importing/exporting XMI from other tools probably falls in the > nice-to-have category. (But Michael clarified that sometimes even > importing portions of diagrams prepared by someone else using the > same tool caused problems.) > - Community or free editions of some commercial tools often add > banner text on printouts. It should count against that tool. > - Since the tools must be free other tools such as MS Visio are not > reviewed. > > ** Tool summary > - Poseidon: Very slow starting up---when clicking on a project icon > it took about 45sec to start up. But after that is quite usable > and the functionality is good. > - Rose: A big download but the functionality and performance is > good. A lot of features. But there are many editions and the RSM > version may be sufficient. > - It took about 1 week for a reply to the GGF license request. And > Michael still has to talk with someone at IBM about receiving a > license. > - Jude: Also quite good, but would need the Pro version (not free) > for import/export. > - Visual Paradigm was also quite good. > > ** Discussion > > - Preference on the call for Rational. It is a full featured, > unlimited, version. It has support for all the features needed and > performance is good. Finally IBM's standards license should give > all GGF participants access to same version at no extra cost. > - In the case of DMTF there is a designated IBM representative > within DMTF that participants can apply to and get a license. A > similar arrangements should be possible within GGF. > > Action: Ellen will check who can be IBM's contact within GGF > for Rational licenses. (It is probably going to be one of > Dave Martin or Jay Unger.) > > Action: Hiro will send out a short memo on the rough consensus to > the list. Ask for comments and make a final decision on the > next call.

1 0

RE: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profil e, AbstractName is meaningless ...
by Maguire_Tom＠emc.com 16 Nov '05

16 Nov '05

>And if so, is everyone expected to (a) have read and understood >section 3.2.3. on the subject of URI equivalence(below), or (b) >to explicitly require case-sensitive-string-matching as the comparison. I think logically (a) but since they SHOULD be IRIs I would use section 5 of RFC 3987 (below). Which basically adds codepoint normalization to the URI normalization you ref'd in section 3.2.3. The point being that we should be EXCEPTIONALLY clear about what it means to be equivalent. Perhaps we should even right a few TEST CASES. :-) Tom ---------------------------------------------------------------------------- --------------------- 5. Normalization and Comparison Note: The structure and much of the material for this section is taken from section 6 of [RFC3986]; the differences are due to the specifics of IRIs. One of the most common operations on IRIs is simple comparison: Determining whether two IRIs are equivalent without using the IRIs or the mapped URIs to access their respective resource(s). A comparison is performed whenever a response cache is accessed, a browser checks its history to color a link, or an XML parser processes tags within a namespace. Extensive normalization prior to comparison of IRIs may be used by spiders and indexing engines to prune a search space or reduce duplication of request actions and response storage. IRI comparison is performed for some particular purpose. Protocols or implementations that compare IRIs for different purposes will often be subject to differing design trade-offs in regards to how much effort should be spent in reducing aliased identifiers. This section describes various methods that may be used to compare IRIs, the trade-offs between them, and the types of applications that might use them. 5.1. Equivalence Because IRIs exist to identify resources, presumably they should be considered equivalent when they identify the same resource. However, this definition of equivalence is not of much practical use, as there is no way for an implementation to compare two resources unless it has full knowledge or control of them. For this reason, determination of equivalence or difference of IRIs is based on string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. We use the terms "different" and "equivalent" to describe the possible outcomes of such comparisons, but there are many application-dependent versions of equivalence. Even though it is possible to determine that two IRIs are equivalent, IRI comparison is not sufficient to determine whether two IRIs identify different resources. For example, an owner of two different domain names could decide to serve the same resource from both, resulting in two different IRIs. Therefore, comparison methods are designed to minimize false negatives while strictly avoiding false positives. In testing for equivalence, applications should not directly compare relative references; the references should be converted to their respective target IRIs before comparison. When IRIs are compared to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) should be excluded from the comparison. Applications using IRIs as identity tokens with no relationship to a protocol MUST use the Simple String Comparison (see section 5.3.1). All other applications MUST select one of the comparison practices from the Comparison Ladder (see section 5.3 or, after IRI-to-URI conversion, select one of the comparison practices from the URI comparison ladder in [RFC3986], section 6.2) 5.2. Preparation for Comparison Any kind of IRI comparison REQUIRES that all escapings or encodings in the protocol or format that carries an IRI are resolved. This is usually done when the protocol or format is parsed. Examples of such escapings or encodings are entities and numeric character references in [HTML4] and [XML1]. As an example, "http://example.org/rosé" (in HTML), "http://example.org/ros&#233"; (in HTML or XML), and "http://example.org/ros&#xE9"; (in HTML or XML) are all resolved into what is denoted in this document (see section 1.4) as "http://example.org/ros&#xE9"; (the "é" here standing for the actual e-acute character, to compensate for the fact that this document cannot contain non-ASCII characters). Similar considerations apply to encodings such as Transfer Codings in HTTP (see [RFC2616]) and Content Transfer Encodings in MIME ([RFC2045]), although in these cases, the encoding is based not on characters but on octets, and additional care is required to make sure that characters, and not just arbitrary octets, are compared (see section 5.3.1). 5.3. Comparison Ladder In practice, a variety of methods are used, to test IRI equivalence. These methods fall into a range distinguished by the amount of processing required and the degree to which the probability of false negatives is reduced. As noted above, false negatives cannot be eliminated. In practice, their probability can be reduced, but this reduction requires more processing and is not cost-effective for all applications. If this range of comparison practices is considered as a ladder, the following discussion will climb the ladder, starting with practices that are cheap but have a relatively higher chance of producing false negatives, and proceeding to those that have higher computational cost and lower risk of false negatives. 5.3.1. Simple String Comparison If two IRIs, when considered as character strings, are identical, then it is safe to conclude that they are equivalent. This type of equivalence test has very low computational cost and is in wide use in a variety of applications, particularly in the domain of parsing. It is also used when a definitive answer to the question of IRI equivalence is needed that is independent of the scheme used and that can be calculated quickly and without accessing a network. An example of such a case is XML Namespaces ([XMLNamespace]). Testing strings for equivalence requires some basic precautions. This procedure is often referred to as "bit-for-bit" or "byte-for-byte" comparison, which is potentially misleading. Testing strings for equality is normally based on pair comparison of the characters that make up the strings, starting from the first and proceeding until both strings are exhausted and all characters are found to be equal, until a pair of characters compares unequal, or until one of the strings is exhausted before the other. This character comparison requires that each pair of characters be put in comparable encoding form. For example, should one IRI be stored in a byte array in UTF-8 encoding form and the second in a UTF-16 encoding form, bit-for-bit comparisons applied naively will produce errors. It is better to speak of equality on a character-for-character rather than on a byte-for-byte or bit-for-bit basis. In practical terms, character-by-character comparisons should be done codepoint by codepoint after conversion to a common character encoding form. When comparing character by character, the comparison function MUST NOT map IRIs to URIs, because such a mapping would create additional spurious equivalences. It follows that an IRI SHOULD NOT be modified when being transported if there is any chance that this IRI might be used as an identifier. False negatives are caused by the production and use of IRI aliases. Unnecessary aliases can be reduced, regardless of the comparison method, by consistently providing IRI references in an already normalized form (i.e., a form identical to what would be produced after normalization is applied, as described below). Protocols and data formats often limit some IRI comparisons to simple string comparison, based on the theory that people and implementations will, in their own best interest, be consistent in providing IRI references, or at least be consistent enough to negate any efficiency that might be obtained from further normalization. 5.3.2. Syntax-Based Normalization Implementations may use logic based on the definitions provided by this specification to reduce the probability of false negatives. This processing is moderately higher in cost than character-for-character string comparison. For example, an application using this approach could reasonably consider the following two IRIs equivalent: example://a/b/c/%7Bfoo%7D/rosé eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9 Web user agents, such as browsers, typically apply this type of IRI normalization when determining whether a cached response is available. Syntax-based normalization includes such techniques as case normalization, character normalization, percent-encoding normalization, and removal of dot-segments. 5.3.2.1. Case Normalization For all IRIs, the hexadecimal digits within a percent-encoding triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore should be normalized to use uppercase letters for the digits A - F. When an IRI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and US-ASCII only host are case insensitive and therefore should be normalized to lowercase. For example, the URI "HTTP://www.EXAMPLE.com/" is equivalent to "http://www.example.com/". Case equivalence for non-ASCII characters in IRI components that are IDNs are discussed in section 5.3.3. The other generic syntax components are assumed to be case sensitive unless specifically defined otherwise by the scheme. Creating schemes that allow case-insensitive syntax components containing non-ASCII characters should be avoided. Case normalization of non-ASCII characters can be culturally dependent and is always a complex operation. The only exception concerns non-ASCII host names for which the character normalization includes a mapping step derived from case folding. 5.3.2.2. Character Normalization The Unicode Standard [UNIV4] defines various equivalences between sequences of characters for various purposes. Unicode Standard Annex #15 [UTR15] defines various Normalization Forms for these equivalences, in particular Normalization Form C (NFC, Canonical Decomposition, followed by Canonical Composition) and Normalization Form KC (NFKC, Compatibility Decomposition, followed by Canonical Composition). Equivalence of IRIs MUST rely on the assumption that IRIs are appropriately pre-character-normalized rather than apply character normalization when comparing two IRIs. The exceptions are conversion from a non-digital form, and conversion from a non-UCS-based character encoding to a UCS-based character encoding. In these cases, NFC or a normalizing transcoder using NFC MUST be used for interoperability. To avoid false negatives and problems with transcoding, IRIs SHOULD be created by using NFC. Using NFKC may avoid even more problems; for example, by choosing half-width Latin letters instead of full-width ones, and full-width instead of half-width Katakana. As an example, "http://www.example.org/résumé.html" (in XML Notation) is in NFC. On the other hand, "http://www.example.org/résumé.html" is not in NFC. The former uses precombined e-acute characters, and the latter uses "e" characters followed by combining acute accents. Both usages are defined as canonically equivalent in [UNIV4]. Note: Because it is unknown how a particular sequence of characters is being treated with respect to character normalization, it would be inappropriate to allow third parties to normalize an IRI arbitrarily. This does not contradict the recommendation that when a resource is created, its IRI should be as character normalized as possible (i.e., NFC or even NFKC). This is similar to the uppercase/lowercase problems. Some parts of a URI are case insensitive (domain name). For others, it is unclear whether they are case sensitive, case insensitive, or something in between (e.g., case sensitive, but with a multiple choice selection if the wrong case is used, instead of a direct negative result). The best recipe is that the creator use a reasonable capitalization and, when transferring the URI, capitalization never be changed. Various IRI schemes may allow the usage of Internationalized Domain Names (IDN) [RFC3490] either in the ireg-name part or elsewhere. Character Normalization also applies to IDNs, as discussed in section 5.3.3. 5.3.2.3. Percent-Encoding Normalization The percent-encoding mechanism (section 2.1 of [RFC3986]) is a frequent source of variance among otherwise identical IRIs. In addition to the case normalization issue noted above, some IRI producers percent-encode octets that do not require percent-encoding, resulting in IRIs that are equivalent to their non encoded counterparts. These IRIs should be normalized by decoding any percent-encoded octet sequence that corresponds to an unreserved character, as described in section 2.3 of [RFC3986]. For actual resolution, differences in percent-encoding (except for the percent-encoding of reserved characters) MUST always result in the same resource. For example, "http://example.org/~user", "http://example.org/%7euser", and "http://example.org/%7Euser", must resolve to the same resource. If this kind of equivalence is to be tested, the percent-encoding of both IRIs to be compared has to be aligned; for example, by converting both IRIs to URIs (see section 3.1), eliminating escape differences in the resulting URIs, and making sure that the case of the hexadecimal characters in the percent-encoding is always the same (preferably uppercase). If the IRI is to be passed to another application or used further in some other way, its original form MUST be preserved. The conversion described here should be performed only for local comparison. 5.3.2.4. Path Segment Normalization The complete path segments "." and ".." are intended only for use within relative references (section 4.1 of [RFC3986]) and are removed as part of the reference resolution process (section 5.2 of [RFC3986]). However, some implementations may incorrectly assume that reference resolution is not necessary when the reference is already an IRI, and thus fail to remove dot-segments when they occur in non-relative paths. IRI normalizers should remove dot-segments by applying the remove_dot_segments algorithm to the path, as described in section 5.2.4 of [RFC3986]. 5.3.3. Scheme-Based Normalization The syntax and semantics of IRIs vary from scheme to scheme, as described by the defining specification for each scheme. Implementations may use scheme-specific rules, at further processing cost, to reduce the probability of false negatives. For example, because the "http" scheme makes use of an authority component, has a default port of "80", and defines an empty path to be equivalent to "/", the following four IRIs are equivalent: http://example.com http://example.com/ http://example.com:/ http://example.com:80/ In general, an IRI that uses the generic syntax for authority with an empty path should be normalized to a path of "/". Likewise, an explicit ":port", for which the port is empty or the default for the scheme, is equivalent to one where the port and its ":" delimiter are elided and thus should be removed by scheme-based normalization. For example, the second IRI above is the normal form for the "http" scheme. Another case where normalization varies by scheme is in the handling of an empty authority component or empty host subcomponent. For many scheme specifications, an empty authority or host is considered an error; for others, it is considered equivalent to "localhost" or the end-user's host. When a scheme defines a default for authority and an IRI reference to that default is desired, the reference should be normalized to an empty authority for the sake of uniformity, brevity, and internationalization. If, however, either the userinfo or port subcomponents are non-empty, then the host should be given explicitly even if it matches the default. Normalization should not remove delimiters when their associated component is empty unless it is licensed to do so by the scheme specification. For example, the IRI "http://example.com/?" cannot be assumed to be equivalent to any of the examples above. Likewise, the presence or absence of delimiters within a userinfo subcomponent is usually significant to its interpretation. The fragment component is not subject to any scheme-based normalization; thus, two IRIs that differ only by the suffix "#" are considered different regardless of the scheme. Some IRI schemes may allow the usage of Internationalized Domain Names (IDN) [RFC3490] either in their ireg-name part or elsewhere. When in use in IRIs, those names SHOULD be validated by using the ToASCII operation defined in [RFC3490], with the flags "UseSTD3ASCIIRules" and "AllowUnassigned". An IRI containing an invalid IDN cannot successfully be resolved. Validated IDN components of IRIs SHOULD be character normalized by using the Nameprep process [RFC3491]; however, for legibility purposes, they SHOULD NOT be converted into ASCII Compatible Encoding (ACE). Scheme-based normalization may also consider IDN components and their conversions to punycode as equivalent. As an example, "http://résumé.example.org" may be considered equivalent to "http://xn--rsum-bpad.example.org". Other scheme-specific normalizations are possible. 5.3.4. Protocol-Based Normalization Substantial effort to reduce the incidence of false negatives is often cost-effective for web spiders. Consequently, they implement even more aggressive techniques in IRI comparison. For example, if they observe that an IRI such as http://example.com/data redirects to an IRI differing only in the trailing slash http://example.com/data/ they will likely regard the two as equivalent in the future. This kind of technique is only appropriate when equivalence is clearly indicated by both the result of accessing the resources and the common conventions of their scheme's dereference algorithm (in this case, use of redirection by HTTP origin servers to avoid problems with relative references).

2 1

Proposed agenda for Nov. 16 call
by Hiro Kishimoto 16 Nov '05

16 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 16 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: 1116 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 (Nov. 14) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051114/en/1 Agenda bashing 2) naming issues resolution process discussion (20 min hard-bound) Discuss how to proceed resolving naming issues For example; - identify requirements and open issues - collect position statements from all stakeholders - prioritize requirements and acceptable solutions to reach rough consensus 3) OGSA-WG January F2F schedule (20 min) Review F2F agenda proposal (attached) Also uploaded to the GridForge https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… 4) EMS discussion (30 min) (1) review sequence diagrams from composite roadmap 2.4 Job Termination 2.5 Dynamic Job Selection (2) Review Ian's comments on 2.3 Selected Job Execution > I need to see more details on what is being proposed in terms of a > selector interface, but I would be concerned if there was an attempt > to incorporate this as a primitive. As the brief and > far-from-comprehensive list above shows, there are many different > resource selection strategies that may be applied, and these > strategies may be applied in many different ways and in different > places. (3) Deployment and configuration scenarios break down Based on the discussion at the last CDDLM/ACS joint call, I think we need more fine grain scenarios breakdown for chapter 3. EMS Architecture Composition Roadmap (incorporate Nov. 9th CDDLM/ACS joint discussion) https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… 5) information model discussion (20 min) > Action: Andrew to review and point out what is needed for the > BES container > - Goal: A preliminary set of attributes that are > needed for the BES container 6) Glossary 1.5 discussion (20 min) At Nov. 14 call, we agreed that from now on a 10-15 minute slot must be reserved on *each call* for a brief glossary review. 7) Wrap up AOB <Basic security profile - secure channel - submission plan> - Prepare a new draft by Wed (Today) - Do the final review next Monday (Nov. 21) - Make the final call after that and submit by Nov'30 (Cannot do earlier given the Thanksgiving holiday) <NEXT CALL> Nov. 21 (Mon) OGSA-AuthZ joint call OGSA Basic Security Profile final review Architecture & Glossary 1.5 Profile Definition Update Nov. 23 (Wed) NO call (Thanksgiving) Nov. 28 (Mon) Architecture & Glossary 1.5 Profile Definition Update Nov. 30 (Wed) EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

RE: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profil e, AbstractName is meaningless ...
by Maguire_Tom＠emc.com 15 Nov '05

15 Nov '05

So we have had this discussion several times now. I suggest that when the WS-Addressing 1.0 WSDL Binding becomes a recommendation that the wsa:Address will not be treated by the tooling as a URL. Further the fact that current tooling gets it wrong is not surprising given that there is no normative profile for WS-Addressing. While I understand the tooling issues I would be extremely hesitant to base an architectural decision on vagaries of tooling. Let me be very clear about this an EPR does not have a 1 to 1 correspondence with a protocol and binding address. It MUST be true that an EPR can support multiple protocols and their associated addresses. With that as a base understanding is there any argument, other than URL tooling, that you can articulate against using the wsa:Address IRI field as a unique resource identifier? Tom -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, November 15, 2005 11:11 AM To: 'Steve Loughran' Cc: ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org Subject: RE: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profile, AbstractName is meaningless ... I'm concerned that by saying that we will start using the Address field for uniqueness and comparison reasons that that is going to place a MUCH heavier burden on the tooling, programers, and users then the abstract name does currently. All of my web services right now have URLs in the Address field because that's what the tooling supports and clearly the URL is not unique for all resource endpoints (I in fact have thousands of resource endpoints residing on my machine right now at exactly one URL). Using IRIs or URIs in the address field of the EPR is great on paper, but I don't know of any tooling that in fact supports that. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf > Of Steve Loughran > Sent: Monday, November 14, 2005 12:16 PM > Cc: ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org > Subject: Re: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address > profile, AbstractName is meaningless ... > > Mark McKeown wrote: > > Hi Frank, > > The Web Architecture > > (http://www.w3.org/TR/webarch/#identification) > > discusses and provides guidance on the issues you describe of IRI > > collision, IRI aliases etc. Does this document not address > the issues > > of the profile work you are suggesting? > > > > When you advocate using the wsa:Address for the > AbstractName are you > > saying that there is no need for adding the AbstractName > element from > > WS-Naming into the EPR or are you saying that the > wsa:Address (or some > > combination of the > > wsa:Address+wsa:ReferenceParameters) should be used in the > > AbstractName element. > > > > eg. > > <wsa:EndpointReference > > xmlns:wsa="http://www.w3.org/2005/03/addressing" > > xmlns:name="http://ggf.org/name"> > > <wsa:Address>http://ggf.org/example/B944388</wsa:Address> > > > > > <name:AbstractName>http://ggf.org/example/B944388</name:AbstractName> > > </wsa:EndpointReference> > > And if so, is everyone expected to (a) have read and understood > section 3.2.3. on the subject of URI equivalence(below), or (b) to > explicitly require case-sensitive-string-matching as the comparison. > > In the case above, are the following abstract names equivalent? > > <name:AbstractName>http://GGF.ORG/example/B944388</name:AbstractName> > <name:AbstractName>http://GGF.ORG:80/example/B944388</name:Abs > tractName> > <name:AbstractName>http://ggf.org:/example/B944388</name:AbstractName> > <name:AbstractName>HTTP://ggf.org/%65xample/B944388</name:Abst > ractName> > > I ask, as for the test document for CDDLM, I need to define > equivalence of things. And as EPR equivalence is so troublesome I am > looking at WSDM ResourceIDs, but even there you have to specify what > equivalence logic you will be using. > > -steve > > --------------------- > RFC2616 on comparisons. Note that java.net does not implement this > logic: > > 3.2.3 URI Comparison > > When comparing two URIs to decide if they match or not, a client > SHOULD use a case-sensitive octet-by-octet comparison of the > entire > URIs, with these exceptions: > > - A port that is empty or not given is equivalent to the > default > port for that URI-reference; > > - Comparisons of host names MUST be case-insensitive; > > - Comparisons of scheme names MUST be case-insensitive; > > - An empty abs_path is equivalent to an abs_path of "/". > > Characters other than those in the "reserved" and "unsafe" sets > (see > RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. > > For example, the following three URIs are equivalent: > > http://abc.com:80/~smith/home.html > http://ABC.com/%7Esmith/home.html > http://ABC.com:/%7esmith/home.html >

1 0

... without wsa:Address profile, AbstractName is meaningless ...
by Frank Siebenlist 15 Nov '05

15 Nov '05

Without the proper uniqueness guarantees for the wsa:Address, the use of ws-naming's AbstractName is meaningless. The EPR with an embedded AbstractName essentially describes a binding between the Address and the AbstractName. One could argue that this binding is a bit of a flaky assertion without any way to specify time-validity or issuer. As a result, one can not see from an EPR alone when it was issued or whether it is still valid or not. An EPR-minter can decide to create a new EPR for a resource and reuse an Address that was used for an other resource before. This would yield the undesirable situation that you would have two EPRs with identical Addresses and two different AbstractNames associated with different resources, and the client would have no way to see which one of the EPRs is valid... For example, if I have two EPRs with the same Address, where one EPR includes an AbstractName that identifies MyBankAccount and the other includes an AbstractName identifying YourBankAccount, then one of us will not be happy with that situation... In order to avoid this ambiguity, we need the guarantee from the EPR-minter that Address values will not be reused for different resources: for all times, the Address should either refer to that one and only resource, or it should be invalid (and it is allowed to change between those two states). Furthermore, the EPR-minters should ensure that globally unique Addresses are used for a resource such that different EPR-minters do not (accidentally) use the same Address for different resources. The described uniqueness properties of the Address constitutes a required EPR-minter profile for the use of AbstractNames. --- This has been reiterated in a number of emails, but i wanted to call it out separately to facilitate the discussion whether the observation holds water and if so, whether such a EPR-minter Address-profile should become part of the ws-naming spec. Again, I would especially welcome comments/reactions/acknowledgments from the ws-naming authors... Regards, Frank. PS. Note that everywhere I wrote "Address" above, it should probably be substituted by "Address+ReferenceParameters", but this simplification doesn't change the observation. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

4 4

Proposed agenda for Nov. 14 call
by Hiro Kishimoto 14 Nov '05

14 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 14th 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: 1114 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 (Nov. 9) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051109/en/1 Agenda bashing 2) Common UML tool review (20 min) Mike sent out his study summary to the list. Thanks Mike! Let's learn what he found. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 3) OGSA workshop at Israel Grid Alliance (20 min) Steve Crumb ask us to send a rep to Tel Aviv before or after GGF16. > In my continued efforts to get an OGSA expert to Israel to discuss > the architecture to a primarily technical audience, Avner and I have > settled on the proposal of having an OGSA half-day workshop > immediately after (or before) the Athens event. This would allow for > someone to be roughly in the same geographic area making a quick, > one-day hop to Tel Aviv much more doable. 4) Basic Security Profile document review (60 min) Takuya will post revised draft before the call. 5) Architecture & Glossary 1.5 discussion (if time permits) 6) Wrap up AOB <NEXT CALL> Nov. 16 (Wed) EMS architecture, information model & CIM profile Nov. 21 (Mon) OGSA-AuthZ joint call Architecture & Glossary 1.5 Profile Definition Update Nov. 23 (Wed) NO call (Thanksgiving) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 1

RE: [ogsa-wg] Teleconference minutes - 9 November 2005
by Maguire_Tom＠emc.com 14 Nov '05

14 Nov '05

So is OGSA-Naming suggesting that the agreed upon algorithm for uniqueness in time and space is RFC4122? There are several well known issues with UUIDs that should be considered. The general algorithm uses the Mac address (in fact the algorithm piggy backs on the uniqueness of the mac address and adds a timestamp component for uniqueness over and above the mac addr). There have been a number of discussions about privacy and the UUID/GUID algorithms w.r.t mac addresses. Additionally, as the authors themselves point out in RFC4122 there are circumstances where duplicates may occur; failure of a node and restart, migration of network card to another machine. There is also no way to ensure that a UUID is 'valid'. Also please be careful; if you ever need to resolve a UUID to a reference it will be next to impossible. So in short, I think there are considerable technical issues with UUIDs. I will point out that the general pattern that UUIDs use is: 1) Base uniqueness by some body handling registration (IEEE does this for mac addresses) 2) Agreed upon algorithms or encoding schemes for spatial uniqueness within the uniqueness provided by point 1 This is not terribly different from URI pattern: 1) Base uniqueness by IANA for domain names 2) Agreed upon encoding scheme for pathing after base The not so subtle difference is that you can resolve a URI.... Tom -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark McKeown Sent: Monday, November 14, 2005 8:53 AM To: Andreas Savva Cc: 'ogsa-wg' Subject: Re: [ogsa-wg] Teleconference minutes - 9 November 2005 A comment on the minutes... "* Naming Policy discussion Tom sent out the naming policy proposal to the list before the call. Briefly it states that OGSA fellow WG specifications must return EPRs. The EPRs may be decorated with more information but there should be no normative statement in the specifications that that information must be present. One technical issue is the level of coordination required for mandating WS-Names. The main point being the difficulty of quaranteeing uniqueness-in-space-and-time. For the uniqueness statement to be true an algorithm to create a unique string must be specified and everyone must agree to use it, which introduces a new set of problems." Is this technical issue not addressed by IETF RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace"? http://www.ietf.org/rfc/rfc4122.txt cheers Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown(a)man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Mon, 14 Nov 2005, Andreas Savva wrote: > Minutes attached. Main topics: > * EMS and CDDLM, ACS joint discussion > * Naming Policy discussion > > https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051109 > /en/1 > -- > Andreas Savva > Fujitsu Laboratories Ltd >

2 1

Teleconference minutes - 9 November 2005
by Andreas Savva 14 Nov '05

14 Nov '05

Minutes attached. Main topics: * EMS and CDDLM, ACS joint discussion * Naming Policy discussion https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051109/en/1 -- Andreas Savva Fujitsu Laboratories Ltd Teleconfence Minutes - 9 November 2005 ====================================== * Participants Michael Behrens (R2AD, LLC) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Tom Maguire (EMC) Dejan Milojicic (HP) Mark Morgan (UVa) Takuya Mori (NEC) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Stuart Schaefer (Softricity) Frank Siebenlist (ANL) Ellen Stokes (IBM) Jay Unger (IBM) Jem Treadwell (HP) Apologies: Fred Maciel, Peter Ziu Minutes: Andreas Savva * Minutes approval ** November 7 minutes approved with minor corrections - Clarify that it is the sophisticated estimation of deployment time is not a high priority. (Per Hiro's email to OGSA-WG ml) (Done) ** November 2 minutes: - Add Manuel Pereira to participants (Done) * EMS and CDDLM, ACS joint discussion - A number of ongoing discussions on the list. There seems to be convergence on many issues. - Remaining discussion points: 1. Where to draw the line in the CDL tree (aka deployment vs provisioning) - CDDLM team to follow up with Jay 2. EMS requirements for deployment - CDDLM team to follow up with Andrew 3. What kind of information CSG (RSS-WG) expects to get from an ACS repository. Or, more generally what kind of information CSG expects to be able to get and from where. - Hiro has started a discussion with the RSS-WG - CDDLM and ACS services should be added to the EMS architectural diagrams - Deployment requests to CDDLM deployment service - Static information about applications to the (ACS) repository - Dynamic information to information services - CDDLM services could provide information about which applications are installed where - (And optionally, if needed, an estimate of deployment cost--- keeping in mind previous discussions that such estimates are unlikely to be accurate.) - Deployment versus provisioning requirements (Or, where to 'cut' the CDL tree. Above the 'cut' point is deployment---assumed to be a relatively 'light' operation---and below is provisioning---assumed to be more heavy-weight.) - Deciding the cut point is orthogonal to CDDLM---it is policy or best practices and is therefore a system choice - Information (metadata) to help in making the choice could be added to the CDL as mark up - CDDLM implementations have walked the tree fairly far down (to the hardware) for deployment - CDL may be sufficient to express both deployment and provisioning. But it is an open issue if these two activities can, or should be unified in this way in OGSA. In particular CDL may not be going to the full extent of supporting costing, etc., that maybe needed to address all requirements - Resources beneath the cut point can be considered as pre-provisioned: they either exist or they don't. They are not going to be deployed themselves; but they can be used to deploy on. - Which resource to choose for deployment? It is the choice of the EMS architecture (EPS, CSG) and not of CDDLM. - Discussion on how CDL may be viewed as a hierarchy of scripts; and that one could have a history of costs associated with each node. In other words the tree could be decorated with other information (cost, etc, as metadata) - JSDL and CDL relation and can one cover the requirements for the other - A JSDL submission may be associated with a deployment description or request, and the deployment portion could be described in CDL. [I.e., CDL could be a more specific application sub-type in a JSDL document.] - JSDL is not intended to describe the configuration of the software that will be used by the job. The aim is to describe things at a higher level. There may be similarities between the languages (perhaps around resource description) but it does not mean that one language can, or should, replace the other because they serve different purposes. - Jay wants to pursue the issue further among a smaller group of people. Actions: - Hiro to arrange the next joint call - Tentatively scheduled for Dec'21 due to various conflicts. - 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. * Naming Policy discussion Tom sent out the naming policy proposal to the list before the call. Briefly it states that OGSA fellow WG specifications must return EPRs. The EPRs may be decorated with more information but there should be no normative statement in the specifications that that information must be present. One technical issue is the level of coordination required for mandating WS-Names. The main point being the difficulty of quaranteeing uniqueness-in-space-and-time. For the uniqueness statement to be true an algorithm to create a unique string must be specified and everyone must agree to use it, which introduces a new set of problems. It was re-stated that the motivation for WS-Names is so that clients do not have to re-invent this kind of functionality. And that (for certain applications) this is really useful functionality. Andrew also read out portions of an email from Marvin Theimer on the need for WS-Names. (Andrew may send out the email to the list with Marvin's permission.) It was pointed out that there are two issues that should be discussed separately: - Reference resiliency; and - Equivalence checking And that Marvin's email calls out the need for resiliency rather than equivalence. In summary the technical issues are: 1. How to make sure that the identifiers (AbstractName) are unique 2. Some people might choose to provide resiliency using different mechanisms; and mandating this particular mechanism (unique identifier) forces implementations to create identifiers that the client software may not require or use. It was clarified that if a specification defines that EPRs are returned it does not stop a particular service implementation from decorating its EPRs with identifiers and therefore returning WS-Names. And that a mechanism to introspect services and determine whether they are in fact returning WS-Names could be provided. And that clients that absolutely require WS-Names could discover appropriate services that way. - For example, some (OGSA) profile might define a claim URI that means that compliant services return EPRs that are in fact WS-Names. Tom also explained that current tooling does not support extended types of EPRs. So defining an extension of EPRs such as WS-Names will *not work* with available tooling. This means that the WSDL defined by a specification such as BES would will still have to be defined as returning an EPR; and it is only some text in the specification that may make extra statements anyway. [So one cannot programmatically discover this feature.] Action: The next step is up to the BES-WG co-chairs: - Discuss this issue on a BES call and decide how to proceed. Options include the BES specification being redefined to return a URI and then also defining an optional porttype to 'resolve' that URI and so on.... Frank also raised the separate issue of whether the current formulation of WS-Naming is adequate. - There is a need to bind policy using unique identifiers. The current formulation of WS-Naming does not provide sufficient support because the unique identifier does not flow on the wire. - For this identifier to be useful for this purpose it must be part of the header of messages on the wire - Currently the AbstractName is defined as metadata so it does not get on the wire - Frank's proposal is to use the wsa:address IRI as the unique identifier - He has proposed this in the past but did not get an adequate response. He will raise it again on the list. Discussion to continue on the list. * Postponed for the future calls ** Common UML tool discussion - Michael to send out his evaluation in advance ** OGSA volunteer to give presentation in Israel ** Information model discussion - Postponed for next week. - It is pending on Andrew to provide the information that Ellen has asked for. * Next week - Agreed that despite SC'05 there should be sufficient people participating so the calls can go ahead as planned. - Monday call - Basic security profile (Takuya to send out final draft) - UML tool review - OGSA representative to Israel - The OGSA-AuthZ discussion should be re-scheduled for November 21 since it is not clear if members of AuthZ can participate (due to SC'05).

3 2

UML Tools
by Michael Behrens 14 Nov '05

14 Nov '05

Attached is the presentation I put together regarding the UML Tools. It will be discussed in a future teleconference. -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)

1 0

Profile for EPR's Address as "abstract name" ?
by Frank Siebenlist 11 Nov '05

11 Nov '05

I'm starting to sound like a broken record, but I'd like to get a clear statement and direction from the ws-naming authors whether they believe that such a profile is or should be part of their charter. The issues, requirements and possible solutions have been discussed on the list by Tom and myself, but no reactions or follow-up has occurred. Please... Thanks, Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

6 16

Re: [ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES
by Hiro Kishimoto 11 Nov '05

11 Nov '05

Ian's email bounced. -- Hiro Kishimoto Date: Thu, 10 Nov 2005 15:46:52 -0600 (CST) Subject: Re: [ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES From: itf(a)mcs.anl.gov To: "Frank Siebenlist" <franks(a)mcs.anl.gov> Cc: "Mark McKeown" <zzalsmm3(a)nessie.mcc.ac.uk>, "Donal K. Fellows" <donal.k.fellows(a)manchester.ac.uk>, ogsa-wg(a)ggf.org, ogsa-naming-wg(a)ggf.org, ogsa-bes-wg(a)ggf.org I'm concerned that the following two notions may be inconsistent: a) WS-Names should be globally unique (Andrew) b) The WS-Name can be used to pass a LSF jobid (Chris) Or is Chris proposing that LSF be changed to generate its jobids with whatever scheme WS-Naming proposes to ensure global uniqueness? (If it doesn't, then I don't think that Chris can guarantee that the names that LSF generates and the names that someone else generates will not collide.) Ian. >> Mark McKeown wrote: > >>>> Hi Donal, >>>> >>>> >> >>>>>>>> Regarding Chris's desire to be able to pass the LSF jobid >>>>>>>> back to the client somehow - it could be included in the EPR's >>>>>>>> Metdata, possibly RDF could be used to mark up the Metadata >>>>>>>> to indicate that it is a LSF jobid. In this way the Address >>>>>>>> IRI can be kept opaque. >>>>>>>> >>> >>>>>> That would seem to me to be needless disambiguation. Surely it is just >>>>>> up to the service that mints the abstract name to understand it; there >>>>>> is no inherent need for it to explain what that means to anyone else. >>>>>> >> >>>> >>>> I am not sure I understand your comment - you don't seem to >>>> be disagreeing with me... >>>> >>>> Frank wants to use the EPR's wsa:Address IRI as an AbstractName, >>>> Chris wants to send a LSF jobid to the client and the W3C >>>> recommends that IRIs should be opaque. One way to include >>>> the LSF jobid in the EPR is to embed it into the wsa:Address >>>> IRI, this might help make it unique and the client could extract >>>> it from the IRI - however the W3C recommends that IRIs >>>> should be opaque. >>>> > >> >> Well, I also believe that it's better to keep the IRIs opaque and was >> suggesting to use the complete IRI itself as an alternative jobId. >> >> Whether that could work depends on the use cases we have to consider... >> >> -Frank. >> >> -- >> Frank Siebenlist franks(a)mcs.anl.gov >> The Globus Alliance - Argonne National Laboratory >> >>

3 2

RE: [ogsa-wg] Re: [ogsa-bes-wg] Abstract names in BES
by Subramaniam, Ravi 10 Nov '05

10 Nov '05

Hi, I am sorry I missed today's call (combination of a partial conflict and the old habit of expecting the call at 3:00-5:00 Pacific). I may be missing something that has already been covered. Apologies for any redundant discussion. I thought that BES is a focus on the container and not the jobs. It is a job execution environment but the abstract names (if any) should be generated before the request reaches the BES container since the job factory is in the job manager or some such entity. I am not seeing the connection between abstract names for jobs and BES. An abstract name for a container makes sense in this context. In this case, a job id may not be appropriate. I would expect that abstract names have a form that is independent of the type of resource or entity that is referred to by this abstract name. The specific aspects that are determined by type would have to be in the payload. As I was typing this, I saw Mike's email. I would agree that something like a GUID would be appropriate. Alternatively a URI that is parameterized in a domain/application manner may also work (this may accommodate the job id requirement that Chris mentions below while having a similar form for other resources/entities too). Abstract names would be unique (as we all know) but I would expect have a validity lifecycle attached to them (could be as simple as at Time to Live possibly embedded in the name). I would not expect that these are for ever persistent and available but may be driven by policy. Expecting otherwise may put a big burden on the implementation. Is the abstract name an optional or required in all cases (whether embedded in the EPR or not i.e. resolved)? I would vote for it to be optional since in some instances generating the name may not be necessary. An example is an ephemeral job (i.e. < 15 - 30 sec for the lifetime). We have many of these jobs in our environment and these are the ones that really stress our schedulers in many of our production pools. The effort to generate and assign and manage abstract name may not be worth the overhead here. An EPR is all that we may have (hopefully the simplest and really necessary parts in the EPR). Thanks! Ravi ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Christopher Smith Sent: Wednesday, November 09, 2005 5:38 PM To: Ian Foster; ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org; OGSA-BES-wg(a)ggf.org Subject: [ogsa-wg] Re: [ogsa-bes-wg] Abstract names in BES For a mapping of BES to LSF, I would put something like a job id in the abstract name, so that it could be used outside the web services world (say with a CLI). Sure, it could be put in the payload of messages, or retrieved via some explicit call, but it seems reasonable to use the abstract name for this. -- Chris On 9/11/05 17:28, "Ian Foster" <foster(a)mcs.anl.gov> wrote: I found the call today very helpful. One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES. I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique. Are there others? Regards -- Ian.

1 0

service/resource identifier on the wire?
by Frank Siebenlist 09 Nov '05

09 Nov '05

In the past I've advocated that we need an AbstractName equivalent as a service/resource identifier on the wire, i.e. present in the soap message. During the last conference call it was mentioned that at the ws-naming F2F it was discussed that this was not needed. Could someone explain what the arguments were? What the discussion was about exactly? (maybe the f2f-minutes would be nice too ... hint, hint ;-) ) Thanks, Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

4 5

RE: [ogsa-wg] RE: One paragraph describing your expectations from the deployment component
by Milojicic, Dejan S 09 Nov '05

09 Nov '05

Hi Andrew, I presume we will have a chance to discuss this during the meeting today, but here is my attempt in summarizing what CDDLM has discussed this morning. > -----Original Message----- > From: Milojicic, Dejan S > Sent: Monday, November 07, 2005 8:31 AM > To: 'Andrew Grimshaw'; 'Andrew Grimshaw' > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org; > 'cddlm-wg(a)ggf.org' > Subject: RE: [ogsa-wg] RE: One paragraph describing your > expectations from the deployment component > > Thanks Andrew, > > We will get back to you before the meeting on Wednesday and > we can discuss it in more detail at the meeting. Thank you > very much for taking the time to summarize your expectations, > it will go a long way towards clarifying how CDDLM can > contribute to EMS. I am forwarding your email to the CDDLM > mailing list. > > Best regards, > > Dejan > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] > On Behalf > > Of Andrew Grimshaw > > Sent: Monday, November 07, 2005 8:21 AM > > To: Milojicic, Dejan S; 'Andrew Grimshaw' > > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org > > Subject: [ogsa-wg] RE: One paragraph describing your > expectations from > > the deployment component > > > > Dejan, et al, > > > > There are two basic things that EMS needs (in my opinion): > > 1) The ability to identify on which hosts an activity can execute > > because either the executable for the activity is installed > - or CAN > > BE installed. > > 2) The ability to direct that the necessary components for > an activity > > be installed and configured in/on a container - whether that means > > binaries and libraries, licenses, databases, whatever. > > > > In both cases I do not want the activity started. > > > > Let me dive a bit deeper into both: > > 1) The information needed to determine where an activity > can execute - > > either directly, or after some deployment step is needed by RSS so > > that it can make scheduling decisions. While it is not sufficient > > information to make scheduling decisions, it is necessary. > (Other info > > could include load, whether a particular user has privileges or the > > necessary currency, etc.) By definition, CDDLM is not primarily intended to support this functionality. We think that some sort of information service should provide this information. Having said that, CDDLM can still provide some support in this direction (which is maybe 20% of what you need if not less): a) CDL can capture dependencies of deployed components on certain resources which can compared against what is supported on nodes (information provided by other means) and used to decide if/where you can deploy components, and b) CDDLM engines can return information on what has been deployed on them (this is not something that we have specified so far, but it naturally falls under CDDLM). > > 2) Once a placement decision has been made then we must ensure that > > the application/activity is ready to run on the selected container > > resource. In the current JSDL model - all of the information is > > carried in the executable information. > > For more interesting, non-legacy, components latter, it is > likely that > > the mechanism in JSDL will not suffice. Thus, something like: > > Deploy("name of application/component", "name of container > resource") > > > > Where each of the "names" are either path names in a > directory based > > service or EPR's of some sort. CDDLM is primarily focused on deliverying the functionality you have described above. You can take a look at how we utilize it using our deployment APIs, submission language, and component model. One should be able easily to wrap up our functionality to accomplish the interfaces and support requierment you outline in 2) above. Thanks, Dejan. > > Andrew

1 0

RE: [ogsa-naming-wg] service/resource identifier on the wire?
by Maguire_Tom＠emc.com 09 Nov '05

09 Nov '05

So my recollection of the conversation is that I pointed out that AbstractName as currently defined in WS-Naming will not flow on the wire. The discussion from that point forward was about whether or not the AbstractName needed to flow on the wire. There were those that argued that you could make the argument that it was not necessary on an invocation. I suspect that this perspective only considers certain interaction (equivalency for instance). If the AbstractName is used for Authorization policy then I would imagine that it must flow on the wire. There was a thread on this that dealt with a binding of an AbstractName to wsa:Address. Tom -----Original Message----- From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, November 09, 2005 1:19 PM To: Andrew Grimshaw Cc: ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org Subject: Re: [ogsa-naming-wg] service/resource identifier on the wire? Andrew Grimshaw wrote: > Frank, et al, > Let me make sure I understand your question. > > When you say "on the wire" do you mean "must be present in the soap header"? > Yes. > If so, then the discussion was to change the document to state that > the endpoint receiving the message MUST NOT assume that the header > contains the abstract name. The "endpoint" in this case refers to an > endpoint that is being "named". Thus, it cannot be used for dispatch. > > I cannot recall who suggested this (it might have been Tom, I cannot > recall though). The motivation was that because not all elements of > the WS-Address are guaranteed to be included in the header by all tooling. > I'm not sure if I understand what the discussion was related to. It is clear that the current AbstractName element will not end-up in the soap-header. This was the reason for me to suggest the use of the Address as an alternative to the AbstractName and by using a profile to add the right uniqueness properties to the Address such that it can be used as an identifier. Are there issues with the tooling and the address value, and how it ens up in the soap header? And even more important: does the current ws-naming working group believes that having a service/resource identifier that is also present in the message is important enough to standardize its use? -Frank. > -----Original Message----- > From: owner-ogsa-naming-wg(a)ggf.org > [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Frank Siebenlist > Sent: Tuesday, November 08, 2005 11:49 PM > To: ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org > Subject: [ogsa-naming-wg] service/resource identifier on the wire? > > In the past I've advocated that we need an AbstractName equivalent as > a service/resource identifier on the wire, i.e. present in the soap message. > > During the last conference call it was mentioned that at the ws-naming > F2F it was discussed that this was not needed. > Could someone explain what the arguments were? What the discussion was > about exactly? > > (maybe the f2f-minutes would be nice too ... hint, hint ;-) ) > > Thanks, Frank. > > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

AI: Proposal for OGSA-WG policy regarding EPRs, WS-Names and such
by Maguire_Tom＠emc.com 09 Nov '05

09 Nov '05

Sorry for the delay. It has been an exceptionally long day..... An OGSA compliant service when returning a reference MUST use a WS-Addressing EndpointReference (EPR). An OGSA compliant service MAY return a profiled usage of a WS-Addressing EndpointReference (EPR). An OGSA compliant service SHOULD return a WS-Naming profiled WS-Addressing EndpointReference (EPR) where appropriate. An OGSA compliant service MUST NOT require that a specific profiled usage of a WS-Addressing EndpointReference (EPR) be returned. Therefore an OGSA compliant service MUST NOT require that a WS-Naming profiled WS-Addressing EndpointReference (EPR) be returned. The reasoning for this is quite simple. The architectural construct for OGSA is a WS-Addressing EndpointReference. WS-Naming presupposes a particular client interaction. Clients may or may not use this particular interaction style (equivalence checking). In particular, placing the requirement that all implementations of a particular portType must return a WS-Naming profiled EPR may be onerous, especially considering that the interaction being fulfilled by the service might never be exercised by the consumer. In general, OGSA would be better served if clients that required such profiled use selected only services that can provide that information. This area, metadata discovery and exchange, is something that OGSA should be addressing. There were further arguments that were raised during the telecon discussion that would be more appropriately addressed to the WS-Naming WG. 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

Proposed agenda for Nov. 9th call (CDDLM/ACS/GRAAP joint call)
by Hiro Kishimoto 09 Nov '05

09 Nov '05

Hi all, Apologies for cross-posting *ATTENTION* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST OGSA-WG revised charter draft has been accepted by GFSG with no change. Congratulations! https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-Charter-2005/… The following is a proposed agenda for OGSA-WG telecon on Nov. 9th 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: 1109 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 (Nov. 7th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 Since SC05 is next week, can we have a quorum next week? Agenda bashing 2) CDDLM/ACS/GRAAP joint EMS discussion (60 min) > From F2F minutes; > - Action: Agreed on two-pronged approach for CDDLM(+ACS) on one > side and EMS on the other to describe their approaches in > more detail and to then unify those approaches. (Note > these are 3 separate actions.) > - Action(1): CDDLM team volunteered to look into two issues that > were identified as requirements and report back in an > OGSA call > 1. Where to draw the line in the (CDL) provisioning tree > (see above) > 2. How to provide the cost of configuration Dejan already sent out their discussion summary to the list; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/10/msg00026.html OGSA-WG has already reviewed their summary (see Nov. 7 minutes) and will give these feedbacks to them. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 > - Action (2): Andrew provide one paragraph describing his > expectations from the deployment component. (done) > Using this paragraph, CDDLM-WG provides a feedback on > how they match his expectations. Andrew's description; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00013.html > Actions(3): > - RSS-WG to produce abstract interface (and responsibilities) of EPS > and CSG. > - Clarify responsibilities/functionality of JM > - Andreas to send detailed EMS draft (pre OGSA 1.0) document to > Steven N. EMS team is working on "composition roadmap" https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/ > 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) 3) OGSA naming policy discussion (30 min) Tom will have the written proposal (agreed on the previous call) 4) Information model discussion (20 min) > Action: Andrew to review and point out what is needed for the > BES container > - Goal: A preliminary set of attributes that are > needed for the BES container 5) Common UML tool review (if time permit) > - Mike Behrens has some experience with a number of the listed > tools. He volunteered to check out the rest and give an > evaluation next week > - export/import as one required feature > > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 6) OGSA workshop at Israel Grid Alliance (if time permit) Steve Crumb ask us to send a rep to Tel Aviv before or after GGF16. > In my continued efforts to get an OGSA expert to Israel to discuss > the architecture to a primarily technical audience, Avner and I have > settled on the proposal of having an OGSA half-day workshop > immediately after (or before) the Athens event. This would allow for > someone to be roughly in the same geographic area making a quick, > one-day hop to Tel Aviv much more doable. 7) Wrap up AOB <NEXT CALL> Nov. 14 (Mon) OGSA-AuthZ joint call Basic Security Profile document review, Architecture & Glossary 1.5 Nov. 16 (Wed) EMS architecture, information model & CIM profile Nov. 21 (Mon) Architecture & Glossary 1.5 Profile Definition Update Nov. 23 (Wed) NO call (Thanksgiving) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Glossary 1.5 draft 1 uploaded
by Treadwell, Jem 08 Nov '05

08 Nov '05

Hi, I've uploaded the current working draft of the Glossary - it's available at http://tinyurl.com/dwx8k. - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

Teleconference minutes - 7 November 2005
by Andreas Savva 08 Nov '05

08 Nov '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 7 November 2005 ===================================== * Participants Pete Ziu (Northorp Grumman) Jay Unger (IBM) Jem Treadwell (HP) Frank Siebenlist (ANL) Andreas Savva (Fujitsu) Darren Pulsipher (Xango) Takuya Mori (NEC) Tom Maguire (EMC) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Mike Behrens (R2AD, LLC) Apologies: Ellen Stokes, Fred Maciel Minutes: Andreas Savva * November 2 minutes approved with no changes * Profile Definition 1.0 update - Public comment has finished. There are a small number of comments but nothing major. - The GGF Editor has not officially returned the pen to OGSA-WG. The group will start preparing a new version. - Jem will take the pen and make an initial draft. - Tom will take the pen after Jem. * EMS, CDDLM, GRAAP joint call preparation ** CDDLM discussion preparation Reviewed Dejan's meeting notes from October 12 in preparation for the next call. - No issue with communication between CDDLM and ACS via data services (option 2) but eventually details of this interaction should be filled in. - ACS does not place restrictions on the application data it stores. It is up to EMS(CSG) to decide what is where. Action: Hiro will talk with the RSS-WG (owners of the CSG spec) and ask them to outline in a memo what information they expect to have and where it may be coming from (ACS, Information Services, etc.) - [And match that against what the ACS spec already defines.] - Estimate of deployment time - Agreed that this is not a high-priority item at the moment. - Defining the interface and not detailing how the estimation is carried out is a reasonable first step. (Estimation could be history based and also involve some prediction when deployment requests are received for the first time.) - Should this be a simple interface receiving a CDL fragment or one that unwinds a bigger CDL tree? For example, ask for estimates for deploying a CDL tree made of (A,B,C,D) (and considering deployments may be done in parallel) or ask separately for each A,B,C,D part? - Also in the more complex form what should happen if there is history for deploying B,C,D but not A. - Agreed that initially this interface may be very simple: either returns an estimate for whatever CDL (simple or complex) it receives; or "don't know" - Probably need a new sequence diagram to show the relative positioning of this service. [Need to decide when in the EMS Roadmap it appears.] - Hiro will follow up on other issues with Jay ** WS-Agreement discussion preparation - Not sure what the state of this work is as there has been no update from the volunteer team. * Glossary 1.5 review - Client/Service provider/Service requestor - Not sure if these are really needed. The definitions look ok so include them for now. - ACID : leave as is - CSG: leave as is - Component: Jem and Andreas to discuss offline - Context: leave as is - IPC: leave as is - Legacy program: leave as is - Manageability: Refer to WSDM and WS-Manageability specs for consistency (Jem) - Management: Revised definition Action: Jem will update the working glossary copy and the trackers. Action: Andreas to check the use of the term 'use case' in the Architecture document. * Naming proposal status update - Recap of key points from last call - Tom will have the written proposal (agreed on during the previous call) ready within the day. * Basic Security Profile - Draft not ready - postponed for next week * Teleconference schedule ** Next call - EMS discussion first; followed by Naming proposal review - UML tool review (given time) - Mike will send out his evaluation to the list before the call * Next week - SC'05 is next week. - Next Monday: OGSA-AuthZ joint call. (Deliverables, charter, collaboration topics, etc.) Action: Takuya to invite the OGSA-AuthZ team to the call.

2 1

Proposed agenda for Nov. 7th call
by Hiro Kishimoto 08 Nov '05

08 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 7th Monday from 4pm to 6pm (CST). *ATTENTION* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST 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: 1107 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 (Nov. 2nd) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051102/en/1 Agenda bashing 2) CDDLM/ACS/GRAAP joint call preparation (10 min) This Wednesday is a joint call with CDDLM/ACS/GRAAP in order to review progress after GGF15. EMS team needs to get ready for it. > From F2F minutes; > - Action: Agreed on two-pronged approach for CDDLM(+ACS) on one > side and EMS on the other to describe their approaches in > more detail and to then unify those approaches. (Note > these are 3 separate actions.) > - Action(1): CDDLM team volunteered to look into two issues that were > identified as requirements and report back in an OGSA call > 1. Where to draw the line in the (CDL) provisioning tree > (see above) > 2. How to provide the cost of configuration Dejan already sent out their discussion summary to the list; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/10/msg00026.html > Actions(2): > - RSS-WG to produce abstract interface (and responsibilities) of EPS > and CSG. > - Clarify responsibilites/functionality of JM > - Andreas to send detailed EMS draft (pre OGSA 1.0) document to > Steven N. EMS team is working on "composition roadmap" https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/ > Action(3): 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) 3) Common UML tool (20 min) > - Mike Behrens has some experience with a number of the listed > tools. He volunteered to check out the rest and give an > evaluation next week > - export/import as one required feature > > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 4) Basic Security Profile document review (60 min) Takuya will post revised draft before the call. 5) Glossary 1.5 discussion (20 min) Jem will lead several open issues in Glossary 1.5. 6) Wrap up (10 min) AOB <NEXT CALL> Nov. 9 (Wed) EMS architecture, CDDLM/ACS/GRAAP joint call information model & CIM profile Nov. 14 (Mon) OGSA-AuthZ joint call Basic Security Profile document final review, Architecture & Glossary 1.5 Nov. 16 (Wed) EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 4

RE: [ogsa-wg] RE: One paragraph describing your expectations from the deployment component
by Milojicic, Dejan S 07 Nov '05

07 Nov '05

Thanks Ansdrew, We will get back to you before the meeting on Wednesday and we can discuss it in more detail at the meeting. Thank you very much for taking the time to summarize your expectations, it will go a long way towards clarifying how CDDLM can contribute to EMS. I am forwarding your email to the CDDLM mailing list. Best regards, Dejan > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Andrew Grimshaw > Sent: Monday, November 07, 2005 8:21 AM > To: Milojicic, Dejan S; 'Andrew Grimshaw' > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org > Subject: [ogsa-wg] RE: One paragraph describing your > expectations from the deployment component > > Dejan, et al, > > There are two basic things that EMS needs (in my opinion): > 1) The ability to identify on which hosts an activity can > execute because either the executable for the activity is > installed - or CAN BE installed. > 2) The ability to direct that the necessary components for an > activity be installed and configured in/on a container - > whether that means binaries and libraries, licenses, > databases, whatever. > > In both cases I do not want the activity started. > > Let me dive a bit deeper into both: > 1) The information needed to determine where an activity can > execute - either directly, or after some deployment step is > needed by RSS so that it can make scheduling decisions. While > it is not sufficient information to make scheduling > decisions, it is necessary. (Other info could include load, > whether a particular user has privileges or the necessary > currency, etc.) > > 2) Once a placement decision has been made then we must > ensure that the application/activity is ready to run on the > selected container resource. In the current JSDL model - all > of the information is carried in the executable information. > For more interesting, non-legacy, components latter, it is > likely that the mechanism in JSDL will not suffice. Thus, > something like: > Deploy("name of application/component", "name of container resource") > > Where each of the "names" are either path names in a > directory based service or EPR's of some sort. > > Andrew > > -----Original Message----- > From: Milojicic, Dejan S [mailto:dejan.milojicic@hp.com] > Sent: Wednesday, November 02, 2005 10:35 AM > To: Andrew Grimshaw > Cc: Hiro Kishimoto; Stuart Schaefer > Subject: One paragraph describing your expectations from the > deployment component > > Hi Andrew, > > At Boston, you agreed to provide one paragraph describing > your expectations from the deployment component. You have > articulated it at that time. Using this paragraph, we'll > provide a feedback on how we match your expectations. > > Can you please provide this paragraph to us? This is in > preparation for the OGSA meeting on 11/9 which CDDLM > participants will join. > > Thanks, > > Dejan. > >

1 0

RE: One paragraph describing your expectations from the deployment component
by Andrew Grimshaw 07 Nov '05

07 Nov '05

Dejan, et al, There are two basic things that EMS needs (in my opinion): 1) The ability to identify on which hosts an activity can execute because either the executable for the activity is installed - or CAN BE installed. 2) The ability to direct that the necessary components for an activity be installed and configured in/on a container - whether that means binaries and libraries, licenses, databases, whatever. In both cases I do not want the activity started. Let me dive a bit deeper into both: 1) The information needed to determine where an activity can execute - either directly, or after some deployment step is needed by RSS so that it can make scheduling decisions. While it is not sufficient information to make scheduling decisions, it is necessary. (Other info could include load, whether a particular user has privileges or the necessary currency, etc.) 2) Once a placement decision has been made then we must ensure that the application/activity is ready to run on the selected container resource. In the current JSDL model - all of the information is carried in the executable information. For more interesting, non-legacy, components latter, it is likely that the mechanism in JSDL will not suffice. Thus, something like: Deploy("name of application/component", "name of container resource") Where each of the "names" are either path names in a directory based service or EPR's of some sort. Andrew -----Original Message----- From: Milojicic, Dejan S [mailto:dejan.milojicic@hp.com] Sent: Wednesday, November 02, 2005 10:35 AM To: Andrew Grimshaw Cc: Hiro Kishimoto; Stuart Schaefer Subject: One paragraph describing your expectations from the deployment component Hi Andrew, At Boston, you agreed to provide one paragraph describing your expectations from the deployment component. You have articulated it at that time. Using this paragraph, we'll provide a feedback on how we match your expectations. Can you please provide this paragraph to us? This is in preparation for the OGSA meeting on 11/9 which CDDLM participants will join. Thanks, Dejan.

1 0

RE: OGSA 1.5: transaction reference
by Maguire_Tom＠emc.com 07 Nov '05

07 Nov '05

WS-AtomicTransaction submission document to WS-TX TC in OASIS (http://www.oasis-open.org/apps/org/workgroup/ws-tx/) is http://xml.coverpages.org/WS-AtomicTransaction200508.pdf Some things to watch out for; references to the following specs: WS-Policy (just public at this point not in standards body) WS-PolicyAttachment (just public at this point not in a standards body) WS-SecurityPolicy (new TC WS-SX) WS-SecureConversation (new TC WS-SX) WS-Trust (new TC WS-SX) Also using the older August 2004 WS-Addressing specification. Tom -----Original Message----- From: Andreas Savva [mailto:andreas.savva@jp.fujitsu.com] Sent: Monday, November 07, 2005 4:24 AM To: Maguire, Tom Cc: Dave Berry Subject: Re: OGSA 1.5: transaction reference Hi Tom This is another reminder for the action below. Andreas Savva wrote: > Hi Tom > > A reminder that you volunteered to provide a reference to the > Transactions spec. > > >> - Transactions: Tom to send reference > > > -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Joining at approximately 5:30PM ET
by Maguire_Tom＠emc.com 02 Nov '05

02 Nov '05

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

FW: [Fwd: Revised Selected Job Example]
by Treadwell, Jem 02 Nov '05

02 Nov '05

Hi, I'm forwarding this for today's meeting on behalf of Steven... - Jem -----Original Message----- From: Steven Newhouse [mailto:sjn5@doc.ic.ac.uk] Sent: Wednesday, November 02, 2005 5:11 PM To: Treadwell, Jem Subject: [Fwd: Revised Seclected Job Example] -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

Proposed agenda for Nov. 2nd call
by Hiro Kishimoto 02 Nov '05

02 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 2nd Wednesday from 4pm to 6pm (CST). *ATTENTION* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST 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: 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 (Oct. 26) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051026/en/1 Agenda bashing 2) EPR/WS-name use policy in OGSA (30 min) > - Add to the agenda a review the state of the naming > discussion/decisions. From F2F meeting minutes; > The group went through the exercise of doing a number of straw polls > to identify the weight people put on various approaches. > > In summary: > "MUST support EPRs, may support WS-Names or RRs or other things" > > It seems to depend on the situation whether to use something > beyond an EPR. Need more exploratory work to identify which areas > would benefit from using WS-Names or RenewableReference. > > - Proposal to also just say they are EPRs that may be decorated > (and hence be WS-Names) See also discussion thread; http://www-unix.gridforum.org/mail_archive/ogsa-bes-wg/2005/10/msg00002.html 3) EMS architecture discussion (30 min) usecase 2.4 "Dynamic Job Selection" > Instead of using a static pre-defined list of BES instances these > service interfaces will be obtained and selected from a service > registry (information service). With a defined selection language the > RSS implementation can be more sophisticated than in 2.3 allowing a > user defined selection policy to be applied to the available services > in the registry. Requirements: Information/Data model to represent > the service and a selection language. > > The state of art – EGEE & OSG & Naregi. https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… - Steven N will do a first draft. 4) information model discussion (30 min) > Action: Andrew to review and point out what is needed for the > BES container > - Goal for next Wed: A preliminary set of attributes that are > needed for the BES container 5) Common UML tool (20 min) > - Mike Behrens has some experience with a number of the listed > tools. He volunteered to check out the rest and give an > evaluation next week > - export/import as one required feature > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 6) Wrap up AOB <NEXT CALL> Nov. 7 (Mon) Basic Security Profile document final(?) review, Architecture & Glossary 1.5 Nov. 9 (Wed) EMS architecture, CDDLM/ACS/GRAAP joint call information model & CIM profile Nov. 14 (Mon) OGSA-AuthZ joint call Architecture & Glossary 1.5 Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 1

WS-RenewableReferences
by Andrew Harrison 01 Nov '05

01 Nov '05

Hi, Does anyone know the status of WS-RenewableReferences? I understand it's been removed from WSRF and have heard something about OGSA having a profile that covers the same area. Any ideas? cheers, Andrew

3 2

No RM teleconference on November 1st
by Fred Maciel 01 Nov '05

01 Nov '05

Hi, First of all, given that we are using the teleconferences of the OGSA-WG itself to discuss information modeling, the RM design team teleconferences are now in an "off-by-default" mode, i.e., if no announcement is posted then there won't be a teleconference. So, I didn't really need to post this announcement that we won't have a teleconference tomorrow, but I'm sending it just in case (for the last time...). Regards, Fred Maciel Hitachi America R&D

1 0

Teleconference minutes - 24 October 2005
by Andreas Savva 31 Oct '05

31 Oct '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051024/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 24 October 2005 ===================================== * Participants Mike Behrens (R2AD, LLC) Dave Berry (NeSC) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Tom Maguire (EMC) Takuya Mori (NEC) Andreas Savva (Fujitsu) Jem Treadwell (HP) Jay Unger (IBM) Pete Ziu (Northrop Grumman) Minutes: Andreas Savva * Teleconference minutes - Oct. 19 minutes approved with no changes. - Hiro's proposed modifications to previously approved minutes (see mailing list) accepted with the exception of modifying the 'profile' term---it is not a minutes issue. - Hiro to follow up with the RM team on what the proper term should be. - Andreas to correct the other issues. * OGSA Architecture 1.5 - Review of draft 2: Data requirements and Data Capability ** Data requirements - Added policy specification & management - "OGSA must provide consistent update.." is not intended as a general requirement for all services since some could provide weaker consistency. - Agreed to change to "agreed or decided level..." - Use OGSA as an adjective. - Andreas & Jem to review the usage in this document and propose revised usage. - Usage of 'should', 'must' etc - Prioritizing requirements is not a goal for this version so there is no normative meaning implied. - Andreas & Jem to review and provide guidelines - 'Data discovery' and 'Metadata catalogues' and interraction with information services. - Dave B has asked Abdeslem to check the revised text. - Is 'Transport selection' mentioned? In the Data capability section ** Data Capability - Modified definition (previously in terms of providing one or more specific interface). - Deleted the EMS like supply-demand section since explanation was unsatisfactory. No volunteers to write up properly. - What is the 'Legacy considerations' section? - Things that are not functionality or properties and seemed misplaced in previous drafts. - Agreed that the title needs revision. Considered alternatives and settled for "Heterogeneity and Extensibility" - XQuery was not a client API and was replaced by SAX/DOM - Data transfer: Added security paragraph - 'Autonomic' should be changed to 'self-managing' or 'autonomous' as used in other sections. - Simple Access: Add Byte IO reference. - In general refer to other grid-specific standards; but it is not necessary to provide references to all the non-grid ones. - Update: provisioning as implied by "Other examples..." moved here from a later paragraph. - Metadata catalogue: Waiting for feedback from Abdeslem as mentioned above. - Properties: Agreed to keep sub-sections separate (rather than merging in QoS) and to expand the QoS section - Agreed to add Integrity: Andrew will provide text. - Interactions with rest of OGSA - Transactions: Tom to send reference - Scheduling is a new sub-section - Provisioning text merged to earlier paragraph (see above) - The group worked on a high level architecture diagram during last May's F2F. Dave B to look into adding that diagram to this section. * Basic Security Profile review - Draft uploaded to gridforge by Takuya. Reviewed status of trackers. - 1656: Checked and fixed URI - 1657: Confirmed and updated extensibility points according to August version of WS-I BSP (in the process of bringing the rest of the text up to date). Also need to update Appendix B. - 1658: In progress; expect to be done by next Monday's call - 1659: SSL allowed as underlying protocol per WS-I BSP - 1660: Closed - 1661: Closed - 1662: Working on bringing up to date with August BSP 1.0 - 1663: Tom to follow up on it this week - 1685: Define 'secure channel' per Von's comment - Expected revised and possibly final text by next Monday - Also need to update the Roadmap and spreadsheet - Agreed it's a good idea to keep track of updates. Proposed and accepted to log all spec updates to the Roadmap 1.1 tracker. - Takuya will update the spreadsheet and section 5.2 of the Roadmap and references. - Unused references (due to dropping MLS) should be deleted. - Andreas to create a tracker for Roadmap 1.1 * MDC presentation Postponed for next call since Ravi was not present. * Glossary review - Tracker review. - 957: - Resource discovery: Agreed to include using Jem's revised definition. - Factory: add to the glossary. This is a generic definition not the OGSI one. - Grid environment: generic term; leave out - Heterogeneous, homogeneous: generic terms; leave out - Use case / Scenario usage is opposite to the industry usage. It was also pointed out that the usage within OGSA 1.0 may be inconsistent. - Andreas to review usage of "Use case / scenario" in the document and make sure that the terms are used consistently within the Architecture document. Check if they can be aligned with common usage; put an appropriate definition in the Glossary otherwise. - Publish/Subscribe - defined in line; leave out - Multicast - generic term; leave out - broadcast - generic term; leave out (also not used in the document). * Next call - Information model discussion - MDC presentation review - This is scheduled for December but the Title and Abstract should be submitted soon.

3 3

Teleconference minutes - 26 October 2005
by Andreas Savva 31 Oct '05

31 Oct '05

Minutes attached. Also https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051026/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 26 October 2005 ===================================== * Participants Mike Behrens (R2AD, LLC) Chris Jordan (SDSC) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Steven Newhouse (OMII) Kazushige Saga (NAREGI) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Ravi Subramaniam (Intel) Jem Treadwell (HP) Jay Unger (IBM) Pete Ziu (Northrop Grumman) * Oct 24 minutes approved with no changes * Information model discussion - Ellen posted an initial draft of a mapping of GLUE to CIM to the list before the call. - This is still ongoing work; material is incomplete. - Ellen has also had the opportunity to talk with some of the GLUE authors this week and has gained a better understanding of the model. In particular, some elements in GLUE have had no experience; they may be included as placeholders to allow for extensibility later on. - Explanation of the MDS-GLUE-BES model (pdf file) - Items in blue are required by GLUE - Items in black are already in CIM - Items in red: - if {D} they deprecated by CIM - if {E} (experimental) they are new and need experience before complete acceptance - 'Blue' is GLUE-required and in CIM (or equivalent) - There are also a number of GLUE items that have not been mapped yet and so are not in the diagram (these are listed in the Excel sheet) - One example is 'site' - It is not in CIM and seems reasonable to add; but haven't done so yet. - Items such as 'Load' may map to CIM metrics instead - Some items may map to a combination of existing CIM entries: e.g., 'StorageDevice::Size' - For items such as ClockSpeed (l.162), and MTU (l.157): - These are defined as having one value while CIM has equivalent items that have two values: Maximum and Current. - The meaning is probably equivalent to 'Current' but need to confirm. - Also there are some items, e.g., lines 165-168, in the Excel sheet, that are not clear how they will be used. They have been added to GLUE on the assumption that they might be useful but there is no experience with them yet. - It was discussed how such items should be tackled. For example identifying the size of cache might be better abstracted as a memory performance metric. - Why is vendor model version needed? It seems like a composite identification for particular chip and chipset and might be required for specific codes. (Scientific codes may have different requirements.) - Following the above discussion it was clarified that the purpose of this modelling work is - For things that are obviously missing from CIM to extend CIM to include them; and - For things that may be too domain specific(*) and a CIM extension may not be appropriate at this time to show how they can be included without extending CIM formally. There will be no standard mapping for them but they can still be used. The guidelines document will show how these can be added to CIM in this way. [(*) These were called "situational extensions" during the teleconf call] - All these 'situational extensions' will be listed in the final version and will not be defined as either CIM or OGSA 'extensions' ** Slide 3: BES preliminary Action: Andrew to review and point out what is needed for the BES container - Goal for next Wed: A preliminary set of attributes that are needed for the BES container - Additional attributes (Network, Cluster, etc) to be added later incrementally. * UML tool selection - Probable usage is sequence diagrams and information modelling - Prefer a commercial tool (because it may be better supported) - Easy to use is a big advantage - RSM is commercial, has rich functionality but there are some concerns on how easy it is to start using it. - Also whether the IBM Scholar program is available only to US and Canada. - Agreed that it is not possible to make a decision on this call. - One of the IBM participants will follow up and confirm the procedures needed and that everyone can use the RSM tool, if the group decides to go with it. - Mike Behrens has some experience with a number of the listed tools. He volunteered to check out the rest and give an evaluation next week - export/import as one required feature * MDC presentation review - Ravi sent out modified presentation based on Andrew's presentation that was uploaded to Gridforge. - A 45 minutes slot in total is allocated for the presentation. There are too many slides as things stand. - Not sure if it includes Q&A; someone (Hiro?) has to confirm. - Audience? It is not clear. Assume people with various backgrounds. - What should the focus be? - On technical work; on process; or motivation/goal? - It is an introductory presentation. Jay and Hiro suggested a higher level of abstraction. It was agreed to do so and also add some slides on the connection between DMTF and OGSA. - Assume they know what a grid is, or just put one slide on what grid is - OGSA: what it is, what is based on, where it is going (a max of 3 slides) - Relation to other activities - More functional description of components in OGSA; component diagrams as in EMS for other capabilities if possible (not quite ready for this yet). - Slide 26 is good as standards landscape - Slide 24 is also good; add CIM and WSDM (and transitions to call out the standards bodies) - Slide 38 is good but maybe too detailed for this presentation - Slide 16 is ok; but it is not good to explain things from this slide - slide 22; Replace with Fred's version since it includes the CIM profile (Hiro will send to Ravi.) - Are the Acknowledments correct? - Ellen will help with DMTF-OGSA slide. Again start from Fred's slides at GGF15. - Ravi will update, and circulate to collect comments. - And arrange to have a short discussion on a subsequent call - Need to send agenda and title of this presentation to MDC: - Title: " Open Grid Services Architecture" and - Subtitle: "Service Oriented Architecture for Grids" - Agenda should be a paragraph of text. Ravi to write up. * EMS scenario review. Postponed. * Next call - Agreed to cancel the Monday call since it looks unlikely to reach quorum. - Next Wed: - Add to the agenda a reviewa the state of the naming discussion/decisions.

1 0

OGSA Profile Definition Public Comment Period ends today
by Hiro Kishimoto 30 Oct '05

30 Oct '05

Hi all, Public Comment Period for "OGSA Profile Definition" will end today. We have no comment so far. No comment is *not* good news! Please read this short document and make your comments ASAP. Also, encourage your colleague to do so. Document: http://www.ggf.org/Public_Comment_Docs/Documents/Sep-2005/draft-ggf-ogsa-pr… Make comment: https://forge.gridforum.org/forum/forum.php?forum_id=568 Thanks, -- Hiro Kishimoto

1 0

[ogsa-wg | Roadmap 1.1 - 1691] ACS Acronym incorrect
by Sourceforge Tracker Monitor 29 Oct '05

29 Oct '05

A new artifact has been added: 1691 Submitted by: Michael Behrens Submitted date: 2005-10-29 14:36:13 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1691&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1691&group_id…) Summary: ACS Acronym incorrect Project: Open Grid Services Architecture Tracker: Roadmap 1.1 Artifact ID: 1691 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Michael Behrens Last Modified: 2005-10-29 14:36:13 Submitted By: Michael Behrens Submit Date: 2005-10-29 14:36:13 Assigned To: &lt;None&gt; File(s): <None> Description: It should state: Application Contents Service (ACS) Contents is plural. View the Roadmap 1.1 : 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: New version of ByteIO Specifications]
by Hiro Kishimoto 28 Oct '05

28 Oct '05

Hi all, OGSA-ByteIO will submit their specs to GGF Editor next week. I take it that Neil's email as their final call. Please take time to read this since it is one of OGSA key specifications. Thanks, -- Hiro Kishimoto

1 0

NO CALL on Monday Oct. 31
by Hiro Kishimoto 28 Oct '05

28 Oct '05

Hi all, Since Oct. 31st is Halloween, cancellation of Monday call was discussed and agreed at the last Wednesday call. Next call is Nov. 2nd and starts one hour earlier, 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST Nov. 2 (Wed) EPR/WS-name use in OGSA, EMS architecture, information model, common UML tool Nov. 7 (Mon) Basic Security Profile document *final* review, Architecture & Glossary 1.5 Nov. 9 (Wed) EMS architecture, CDDLM/ACS/GRAAP joint call information model & CIM profile Nov. 14 (Mon) OGSA-AuthZ joint call Architecture & Glossary 1.5 Happy Halloween, ---- Hiro Kishimoto

1 0

Question on minutes
by Maguire_Tom＠emc.com 27 Oct '05

27 Oct '05

Sorry for the cross post.... * Mark to do WSRF Profile Rendering, Stephen to do WS-I Rendering. So does the 'WS-I Rendering' contemplate anything over and above WS-I BP 1.1? For instance is there a need for eventing? Or is this just really a 'Not OGSA WSRF Basic Profile' in which case isn't it really just the WSDL for the BES portTypes? Don't those just get composed with the WSDLs for the WSRF Basic Profile portTypes? 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

***SPAM*** CONFIRM
by elena yengeni 26 Oct '05

26 Oct '05

Dear sir/Madam, My name is Elena Yengeni a South African Parliamentarian Wife. I got your Contact through a personal research .I am the Wife to Mr. Tony Yengeni .Mr. Yengeni was the chairman of parliament's in south Africa and the former chief whip of the ruling political party ANC. My Husband (MR. T. YENGENI), has as a result of trust and Confidence he has mandated that I search for a Reliable and trustworthy foreign partner, who Will help us in investing this funds, which we have in cash Totaling US$9.5m (Nine Million five Hundred United States Dollars) into a personal, company or any Reliable foreign bank account for safe keeping for a Short period of time, since our family Bank accounts within and outside the country have all been Frozen by the authorities. (I would refer you to these Websites for further information about my family) http://www.cnn.com/2001/WORLD/europe/10/03/safrica.arms/index.html However we have managed to ship through a Diplomatic means the said fund out, and it is presently in the custody of a security company in Europe . I believe you are trustworthy and will utilize the money when you receive it. The total sum will be shared as follows: 15% for you, 80% for my family, and then the remaining 5% will be used for the reimbursement of all the expenses we will incur in the process of this transaction with your interest in this business, Endeavor to keep this business strictly confidential because of South African Government. Awaiting your urgent reply. Thanks Mrs., Elena Yengeni REPLY HERE: elena_yengeni(a)mailz.net

1 0

OGSA Preso for MDC ...
by Subramaniam, Ravi 26 Oct '05

26 Oct '05

HI Hiro et al, I have updated/modified foils and reorganized the presentation that Andrew/Dave developed and Andrew sent a pointer to. This is for the conversation today at the telecon. Comments/suggestions by email welcome too. Thanks! Ravi

1 0

Proposed agenda for Oct. 26th call
by Hiro Kishimoto 26 Oct '05

26 Oct '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Oct. 26th Wednesday from 5pm to 7pm (CDT). *Advance Notice* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST 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: 1026 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 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051024/en/1 Agenda bashing 2) EMS architecture discussion (40 min) usecase 2.4 "Dynamic Job Selection" > Instead of using a static pre-defined list of BES instances these > service interfaces will be obtained and selected from a service > registry (information service). With a defined selection language the > RSS implementation can be more sophisticated than in 2.3 allowing a > user defined selection policy to be applied to the available services > in the registry. Requirements: Information/Data model to represent > the service and a selection language. > > The state of art – EGEE & OSG & Naregi. https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… - Steven N will do a first draft. 3) information model discussion (30 min) BES container profile status update Ellen will lead this topic 4) UML tool discussion (20 min) > - OGSA-WG should agree on a common UML tool so as to share the work > of drawing up these sequence diagrams. > - Criteria: free for use and reasonable performance > - Andreas has a list of (free) tools and will send it out. > - JUDE is being used by some people. It comes in various versions > with the free versions having some limitations. IBM Scholar Program allow SDOs to use "Rational Software Modeler" (RSM) V6.0 and "Rational Software Architect" (RSA) for free. http://www.developer.ibm.com/us/en/university/scholars/ 5) MDC presentation review (20 min) Review OGSA overview title, abstract, and presentation slides https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-high-level/en 6) Wrap up AOB <NEXT CALL> Oct. 31 (Mon) Basic Security Profile document review, Architecture & Glossary 1.5 Nov. 2 (Wed) EMS architecture, information model & CIM profile Nov. 7 (Mon) Basic Security Profile document *final* review, Architecture & Glossary 1.5 Nov. 9 (Wed) EMS architecture, CDDLM/ACS/GRAAP joint call information model & CIM profile Nov. 14 (Mon) OGSA-AuthZ joint call Architecture & Glossary 1.5 Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 1

Roadmap 1.1 documents
by Treadwell, Jem 26 Oct '05

26 Oct '05

Hi, Per discussion on Monday's call I've now set up initial versions of the Roadmap 1.1 document and the spreadsheet. * I moved the Roadmap 1.0 documents to the Published Documents Folder. * I created a new Roadmap 1.1 folder in the Working Drafts folder. * Andreas has set up a Roadmap 1.1 tracker. We agreed that we should begin updating the Roadmap sections and the spreadsheet as changes to documents and references become known, so that the working draft can be seen as a reasonable accurate view of the state, even though the published document will become outdated. Before making changes, though, you should open a tracker to describe the change. Takuya will make the first change. Note: For the spreadsheet, I added an "auto_open" macro that automatically takes you to the Index page and protects all the other pages when you open it. That way, you get a consistent view and state every time you open it, regardless of how it was last left. This does have an undesirable side-effect that even if you make no other changes Excel will always ask you if you want to save it when you close. Sorry about that! Here's the URL to the Roadmap 1.1 folder: http://tinyurl.com/aez86 Let me know if you see any issues... - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

List of UML tools
by Andreas Savva 25 Oct '05

25 Oct '05

Here's the list of UML tools I promised on the call last week. I think Hiro is going to put this on the agenda for the Wednesday call. I haven't included tools that are not free (at least for non-commercial use) since that was the main requirement. Obviously the list is not exhaustive; and I have not tried all of these. Note that the IBM offering is the one that started this thread and since the last call we confirmed that GGF participants can use it for standards work. * Rational Software Modeler (RSM) V6.0 Free for standards work (IBM Scholar Program) * FUJABA Tool Suite (http://wwwcs.uni-paderborn.de/cs/fujaba/index.html) Free software. (IBM Eclipse Innovation Award 2004) * UMLGraph - Declarative Drawing of UML Diagrams (http://www.spinellis.gr/sw/umlgraph/) Free software. UML class and sequence diagrams only at the moment. * ArgoUML (http://argouml.tigris.org/) Free software. (Poseidon for UML is a commercial extension of this tool) * Poseidon for UML (http://www.gentleware.com/index.php?id=ce) Community edition is free for non-commercial use (Logo on printouts) * JUDE UML Modeling Tool (http://www.esm.jp/jude-web/index.html) Community Edition is free (with JUDE logo on printouts) A much longer list is here: http://www.objectsbydesign.com/tools/umltools_byPrice.html -- Andreas Savva Fujitsu Laboratories Ltd

1 0

[ogsa-wg | Secure Channel 1.0 - 1685] the document doesn't clarify what a "secure channel" is
by Sourceforge Tracker Monitor 24 Oct '05

24 Oct '05

A new artifact has been added: 1685 Submitted by: Takuya Mori Submitted date: 2005-10-25 03:25:35 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1685&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1685&group_id…) Summary: the document doesn't clarify what a "secure channel" is Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1685 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-25 03:25:35 Submitted By: Takuya Mori Submit Date: 2005-10-25 03:25:35 Assigned To: &lt;None&gt; File(s): <None> Description: A comment from Von Welch. General comment: In part the above comment comes from the fact that the document doesn't clarify what a "secure channel" is. At the architectural level, what does the use of this profile provide? It seems to be the intention that it is a channel has authentication, privacy and integrity attributes, but that is only implied. View the Secure Channel 1.0 : 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

Proposed agenda for Oct. 24th call
by Hiro Kishimoto 24 Oct '05

24 Oct '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Oct. 24th Monday from 5pm to 7pm (CDT). *Advance Notice* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST 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: 1024 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 (Oct. 19) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051019/en/1 Proposal to fix approved minutes http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/10/msg00050.html Agenda bashing 2) MDC presentation review (20 min) Review OGSA overview slides https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-high-level/en 3) Basic Security Profile discussion (45 min) > - Takuya uploaded issues: 7 issues in total for the secure channel > profile > > - 1656: Added the WSRF BP Security Profile URI claim > - Takuya to double-check that the correct URI is used > - 1657: Takuya checking BSP 1.0 and will add the missing > extensibility points, if appropriate > - 1658: Focus profile on TLS and review MLS requirements > - Main things left are statement to only use TLS (not SSL), > mutual authentication, and some of the assertions. > - The key exchange is worded for MLS but can also be used > for TLS. > - Takuya to change the text to 'When exchanging keys...' > instead of 'When using MLS...' > - 1659: Takuya reviewing > - 1662: WS-I BSP reference. Takuya checking which version to use > (Jan or Aug). But, unless there is a specific reason it is > better to refer to the latest one. > > - Other issues: > - Since there may be additional basic profiles the text > describing the relation of this security profile and the WSRF > BP should be revised. (Tom will propose new text.) 4) Architecture & Glossary 1.5 (45 min) Data section review (Dave Berry) Glossary update (Jem) 5) Wrap up AOB <NEXT CALL> Oct. 26 (Wed) EMS architecture, information model & CIM profile Oct. 31 (Mon) Basic Security Profile document review, Architecture & Glossary 1.5 Nov. 2 (Wed) EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

3 2

Comments wrt Secure Channel 1.0 Profile
by Von Welch 24 Oct '05

24 Oct '05

Two nits, one general comment. - Von Section 3.2.1: I find it odd that while for message-level security encryption is mandated, it's not for TLS (as I read the BSP-1.0 document, it's optional). Is this intentional or is encryption assumed with TLS? General comment: In part the above comment comes from the fact that the document doesn't clarify what a "secure channel" is. At the architectural level, what does the use of this profile provide? It seems to be the intention that it is a channel has authentication, privacy and integrity attributes, but that is only implied. R0312, R0313, R0314, R0315, R0316: "When using Message Level Security..." This phrase seems confusing since many of the instances discussed don't actually occur at the time messages are being sent. I would suggest "In order to support Message Level Security..."

2 1

No OGSA resource mgmt design team call Tues Oct 25 <eom>
by Ellen Stokes 24 Oct '05

24 Oct '05

Ellen Stokes STSM, Grid Computing TC Member, IBM Academy of Technology Austin, Texas tl 678 0552 outside +1 512 838 0552 stokese(a)us.ibm.com

1 0

Slides available at
by Andrew Grimshaw 23 Oct '05

23 Oct '05

/ <https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-high-level/en/1> projects/ogsa-wg/document/OGSA-high-level/en/1.

5 8

RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
by Maguire_Tom＠emc.com 21 Oct '05

21 Oct '05

Mark, I'm going to chime in on a few points you make... Your question number 3... 3) wsa:address identifies a resource, it has a IRI, but is that the same thing that the AbstractName is meant to identify? The suggestion that I was making is that the wsa:address CAN be the abstract name. Especially given that in the presence of wsdl port bindings there is no need for it to be the URL (and I mean Locator here) of the resource. I expect that the WS Addressing WSDL Binding will address this issue. Think of the wsa:address as a 'logical' address. Your statement 4... 4) A WSRF WS-Resource has this concept of being composed of two things, a Web Service and a resource - http://docs.oasis-open.org/wsrf/wsrf-ws_resource-1.2-spec-pr-02.pdf (personally I prefer to thing of a WS-Resource as a single thing)- so is the AbstractName ment to identify the resource or the Web Service. (Of course according to W3C Web Services Architecture the Web service is a resource as well) I prefer to think of a WS-Resource as a Resource that happens to have a Web Service interface. And yes the AbstractName is meant to identify the resource which is why I want to use the <wsa:address> (IRI) for that. Your question 5.... 5) A scenario from RealityGrid (http://www.realitygrid.org)- I am working in collaboration with others, I have a job running on resource provider A's machine, the job has an EPR and the A gives it an AbstractName, I migrate the job to another machine provided by B, it has a new EPR and B gives it a different AbstractName. This is not what I want - I want the job to have the same AbstractName after I migrate it so that my fellow collaborators can find it. Can a client add an AbstractName to an EPR, or is only the EPR minter allowed to do that? The AbstractName is immutable (based on the rules defined thus far). Btw, I don't think this is a problem if you view the <wsa:address> (IRI) as logical and the addresses (protocol bound) as the wsdl port binding addresses which is what (I believe) the WS-Addressing WSDL Binding will contemplate. Your question 6... 6) Can I use the AbstractName to identify a particular conversation I am having with a Web service? I guess you could but I would use reference parameters for this..... Tom

1 0

RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding
by Maguire_Tom＠emc.com 21 Oct '05

21 Oct '05

As promised at the F2F in Boston I have started a thread of discussion on the subject line. I have reposted the thread to the this mailing list (ogsa-wg) in the hope that broader distribution will spur debate and discussion. Tom -----Original Message----- From: Maguire, Tom Sent: Sunday, October 09, 2005 4:51 PM To: Maguire, Tom; David.Snelling(a)UK.Fujitsu.com Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding Dave you mentioned in one of your question: >>It appears that in the example that either the was:Address and the >>soap:address must be the same or that the wsa:Addess is irrelevant. >> I can't really believe the former so let's assume the later. It's not that the wsa:adddress is irrelevant it is that the wsa:address is logical as opposed to physical. This is precisely why I think we can use it.... Tom -----Original Message----- From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Maguire, Tom Sent: Sunday, October 09, 2005 8:35 AM To: David.Snelling(a)UK.Fujitsu.com Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding Dave, I'll do my best to answer your questions inline below. Let me caution this thread a bit. The WSDL Binding specification is not complete and is clearly still evolving... >>It appears that in the example that either the was:Address and the soap:address must >>be the same or that the wsa:Addess is irrelevant. I can't really >>believe the >>former so let's assume the later. Yes, I believe that is the intent. As I mentioned in my note it is 'interesting' that they are the same. My guess is that makes implementations that are not <wsa:metadata> aware able to cope. I would expect that would be a 'best practice'. Not sure what the implications would be for us if that were the case... >>With a wsdl11:definitions section present, the wsa:Address field must >>be superseded >>by the soap:address chosen by the client. I assume that the >>soap:address gets copied to the was:To field in the soap header. Ultimately you are correct however I expect that the specification of that linkage would not be quite as explicit as that. >>There is no linkage in the wsdl11:definitions to connect the >>wsa:Address to it. No >>Q1) What happens with more than one wsdl11:definitions section in the >>was:Metadata? I have no idea what that would even mean. I presume they would limit that in the spec. As I said it is still evolving. >>Q2) In this case can we put any old junk in the wsa:Address? >>i.e. leave it out (except that the scheme saus [1..]. <wsa:address> is required and I would assume that at a minimum there would be a statement of 'best practice' where the <wsa:address> is the 'default' address. >>Q3) If we use the wsa:Address as an Abstract Name, how do we know that >>is what >>we are doing? We could subtype the EPR to create a WS-Name as we do >>now, and bind the usage of the was:Address to type of the WS-Name. I would use a wsi conformance claim on both the wsdl and the EPR. The wsdl claim would be that the service is capable of generating WS-Names. The EPR claim would be that this EPR adheres to the additional semantics of a WS-Name. >>Q4) I thought WS-Addressing was NOT about naming or identity. >>How will this use (abuse) of the wsa:Address go down with the W3C folks? I think this is a misread on your part W3C objected to identity being encoded in something OTHER than a URI (IRI); in the WS-Addressing case they objected to ReferenceProperties. Ultimately ReferenceProperties were merged with ReferenceParameters which weakened (removed) the identity semantic. I think they would be extremely happy with the use of a URI as an identifier :-). Tom On 7 Oct 2005, at 12:41, Maguire_Tom(a)emc.com wrote: > This will be a fairly long note to discuss the current incarnation of > WS-Naming Abstract Names. An Abstract Name has the following > properties: > > * The name MUST be globally unique in both space and time. > * The name conforms to URI syntax ("Uniform Resource Identifiers > (IRI): Generic Syntax", RFC 3987). > > Let's leave aside the first point, for the time being, and focus on > the second point. The abstract name is an IRI which is an > internationalized URI. Currently this means that a WS-Name abstract > name would look like > this: > > <wsa:EndpointReference > xmlns:wsa="http://www.w3.org/2005/03/addressing" > xmlns:name="http://ggf.org/name"> > <wsa:Address>http://tempuri.org/example</wsa:Address> > > <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</ > name:Abstr > actName> > </wsa:EndpointReference> > > There are several built in assumptions in this particular rendering of > an > abstract name. First, there is an assumption that the <wsa:Address> > is the > [destination] MAP of the EPR. Second, the AbstractName does not need > to flow on the wire when 'dereferencing' this EPR. > > It may be ok for the AbstractName to not flow on the wire. I will > leave that discussion to others. Let's focus on the first > assumption... > If you assume that the <wsa:Address> is NOT necessarily a physical > address > (URL) then it is essentially the same as an AbstractName minus the > "MUST be globally unique in both space and time" property described > above. > > This is essentially how 'Web Services Addressing 1.0 - WSDL Binding' > defines > a <wsa:Address>. An example from that specfication: > > <wsa:EndpointReference > xmlns:wsa="http://www.w3.org/2005/03/addressing"> > <wsa:Address>http://example.com/fabrikam/acct</wsa:Address> > <wsa:Metadata> > <wsdl11:definitions targetNamespace="http://example.com/fabrikam" > xmlns:fabrikam="http://example.com/fabrikam" > xmlns:abc="http://www.abccorp.com/" > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > xmlns:iiop="http://www.iiop.org/" > xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/"> > <wsdl11:import namespace="http://example.com/fabrikam" > location="http://example.com/fabrikam/fabrikam.wsdl"/> > <wsdl11:import namespace="http://www.abccorp.com/" > location="http://www.abccorp.com/abc.wsdl"/> > <wsdl11:service name="InventoryService"> > <wsdl11:port name="ep1" binding="abc:soap-http-binding"> > <soap:address location="http://example.com/fabrikam/acct"/> > </wsdl11:port> > <wsdl11:port name="ep2" binding="abc:iiop"> > <iiop:address location="..."/> > </wsdl11:port> > </wsdl11:service> > </wsdl11:definitions> > </wsa:Metadata> > </wsd:EndpointReference> > > And also from 'Web Services Addressing 1.0 - WSDL Binding' > > In particular, embedding a WSDL service component description MAY be > used by EPR issuers to indicate the presence of alternative addresses > and protocol bindings to access the referenced endpoint. The > alternatives are provided by the different endpoints of the embedded > service. > > It is interesting to note that in the above example that the > <wsa:address> matches the soap:address location. > So this says to me that the <wsa:address> is essentially equivalent > (or at least could be) to an abstract name. > > Thoughts? > > > 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 > > -- 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)

5 6

Teleconference minutes - 19 October 2005
by Andreas Savva 20 Oct '05

20 Oct '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051019/en/1 -- Andreas Savva OGSA Teleconference - 19 October 2005 ===================================== * Participants Mike Behrens (R2AD, LLC) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Tom Maguire (EMC) Takuya Mori (NEC) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Ravi Subramaniam (Intel) Jay Unger (IBM) Pete Ziu (Northrop Grumman) Minutes: Andreas Savva * Minutes approval - Teleconference minutes for Sep 28, Oct 12 and 17 approved with no changes - GGF15 minutes approved with no changes - F2F minutes approved with no changes * Management Developement Conference presentation - Confirmed Ravi as the presenter - There is an existing slide deck. Andrew will upload it to Gridforge and the group will review it next week. - Hiro to add the review of this presentation on next Monday's call. Scheduled time 20 minutes. * EMS discussion - Review of UML sequence diagram previously sent out by Steven N. - Background: - Initially generated during last F2F and partly revised afterwards. - This is scenario 2.3 - Clarified that this is *a* scenario not *the* scenario to address this particular stage of the EMS Roadmap. There may be other sequences. - The JSDL document is initially abstract and becomes more concrete, for example, as a result of the EPS invocation. - The EMS Roadmap should also list the JSDL features that should be supported and make clearer what is becoming more concrete. - Where is ACS? - ACS is part of a later scenario according to this Roadmap. - Why not include CSG in this diagram? - EPS is seen as a black box at this point. It may be calling CSG behind the scenes but this interaction does not need to be shown in this diagram. - Why not rename EPS to RSS then? - RSS is the name of the group not of a service or interface. - The positioning of Agreement - Donal pointed out on the list that the return of EPS may be some form of Agreement. - Details are not clear yet. May have to put together another diagram to show this. Or it may be clearer in later stages of the Roadmap, e.g., when including reservations in the sequences. - Ravi volunteered to refine some of these scenarios. He will provide text for the EMS Roadmap. - Why is the job and its management not shown in the sequence diagram? - Its representation and management are out of scope of this stage of the Roadmap. - Is a sequence diagram of stopping the job also out of scope at this stage? Yes. - The EMS Architecture document should include more detail to describe everything in the sequence diagram, e.g., the ordering policy mentioned in the call to EPS. - It is not the intention for the EMS Architecture document to be normative but it should be more detailed than what's in OGSA Architecture (1.0 or later). The OGSA Architecture document should contain a higher level summary of what will (eventually) be in the EMS Architecture document. - Starting point: - The EMS section from OGSA 1.0 (or 1.5); and - the older EMS draft (pre-OGSA 1.0) (Andreas has sent this to Steven. It is somewhat dated but useful as background information.) - OGSA-WG should agree on a common UML tool so as to share the work of drawing up these sequence diagrams. - Criteria: free for use and reasonable performance - Andreas has a list of (free) tools and will send it out. - JUDE is being used by some people. It comes in various versions with the free versions having some limitations. * Charter - Andrew to take the OGSA-WG charter to the GFSG for approval. * Other business - Postponed the Information model discussion for next week.

2 1

UML Diagram for today's call
by Steven Newhouse 19 Oct '05

19 Oct '05

Following on from the GGF15 F2F and last week's call here is a UML diagram illustrating stage 2.3 of the EMS Composition Roadmap) for the next call. Comments to the list or save it for the call if you will be there! Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

2 1

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

19 Oct '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Oct. 19th Wednesday from 5pm to 7pm (CDT). OGSA WSRF Basic Profile has entered public comment period. Thanks Andrew and Dave. https://forge.gridforum.org/forum/forum.php?forum_id=575 *Advance Notice* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST 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: 1019 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 Agenda bashing 2) Minutes approval (20 min) Telecon minutes approval (Sept. 28, Oct. 12, and Oct. 17): https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050928/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051012/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051017/en/1 GGF15: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-1/… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-2/… F2F: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… 3) Management Development Conference (10 min) > - Looking for volunteers to give an introductory presentation on > OGSA. > - No known hard deadline for accepting; as-soon-as-possible. > - Both Jay and Tom expressed interest but cannot commit yet. > - Interested parties should contact Hiro. - Ravi has volunteered and committed to present. Discuss and choose presenter. 4) EMS architecture discussion (60 min) > The plan is to merge the Roadmap draft from the F2F and the sequence > diagrams together with the EMS architecture text from OGSA 1.0. The > end result to be the EMS architecture document, one of the > deliverables listed in the new charter. > > - Steven N will do a first draft. > - Weekly EMS calls (allocate half of Wed call) > - Steven volunteered to update the draft scenario (3.2) by next > Wednesday's call https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… 5) information model discussion (20 min) BES container profile status update 6) Wrap up (10 min) AOB <NEXT CALL> Oct. 24 (Mon) Basic Security Profile document review, Architecture & Glossary 1.5 (data section review) Oct. 26 (Wed) EMS architecture, information model & CIM profile Oct. 31 (Mon) Basic Security Profile document review, Architecture & Glossary 1.5 (data section review) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Teleconference minutes - 17 October 2005
by Andreas Savva 18 Oct '05

18 Oct '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051017/en/1 -- Andreas Savva OGSA Teleconference - 17 October 2005 ===================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Andreas Savva (Fujitsu) Takuya Mori (NEC) Tom Maguire (IBM) Hiro Kishimoto (Fujitsu) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * The approval of the following minutes was postponed for Wednesday - Sep 28 - GGF15 sessions - GGF15 F2F - Oct 12 * WSRF RMD spec ownership Dan Jemiolo from WSDM TC joined WSRF TC and has taken over the editorial of the RMD spec. No action from OGSA-WG is needed. * Charter update - Hiro incorporated minor edits by Jem. - Andrew as AD to take to the GFSG. * Teleconference schedule - Teleconference schedule as agreed on during the F2F. * Management Developer Conference - Venue: Santa Clara - Looking for volunteers to give an introductory presentation on OGSA. - No known hard deadline for accepting; as-soon-as-possible. - Both Jay and Tom expressed interest but cannot commit yet. - Interested parties should contact Hiro. * Security Profile issues review - Takuya uploaded issues: 7 issues in total for the secure channel profile - 1656: Added the WSRF BP Security Profile URI claim - Takuya to double-check that the correct URI is used - 1657: Takuya checking BSP 1.0 and will add the missing extensibility points, if appropriate - 1658: Focus profile on TLS and review MLS requirements - Main things left are statement to only use TLS (not SSL), mutual authentication, and some of the assertions. - The key exchange is worded for MLS but can also be used for TLS. - Takuya to change the text to 'When exchanging keys...' instead of 'When using MLS...' - 1659: Takuya reviewing - 1660: Agreed on the call that it is ok as is. - 1661: Tom is ok as contributor - 1662: WS-I BSP reference. Takuya checking which version to use (Jan or Aug). But, unless there is a specific reason it is better to refer to the latest one. - Other issues: - Since there may be additional basic profiles the text describing the relation of this security profile and the WSRF BP should be revised. (Tom will propose new text.)

1 0

[ogsa-wg | Secure Channel 1.0 - 1663] normative dependency to OGSA WSRF Profile
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1663 Submitted by: Takuya Mori Submitted date: 2005-10-18 08:47:42 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1663&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1663&group_id…) Summary: normative dependency to OGSA WSRF Profile Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1663 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 08:47:42 Submitted By: Takuya Mori Submit Date: 2005-10-18 08:47:42 Assigned To: &lt;None&gt; File(s): <None> Description: Not the profile has a normative dependency to the OGSA WSRF Basic Profile. There may be another (or some more?) Basic Profile come up in the future. It's good to remove the normative dependency to the OGSA WSRF Basic Profile to make the profile combinable with other Basic Profles. View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1662] the latest WS-I BSP
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1662 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:43:08 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1662&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1662&group_id…) Summary: the latest WS-I BSP Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1662 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:43:08 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:43:08 Assigned To: &lt;None&gt; File(s): <None> Description: The Aug. 29 version of the WS-I BSP 1.0 has been released. We need to check the difference between the jan 20th version. (It might be better to refer to the latest one) View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1661] author information
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1661 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:41:32 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1661&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1661&group_id…) Summary: author information Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1661 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:41:32 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:41:32 Assigned To: &lt;None&gt; File(s): <None> Description: Should we move 'Tom Maguire' from Contributors to Author Information? View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1660] R0324
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1660 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:40:05 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1660&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1660&group_id…) Summary: R0324 Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1660 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:40:05 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:40:05 Assigned To: &lt;None&gt; File(s): <None> Description: Review WS-I BSP and check what is the requirement for RECEIVER. Perhaps, this should be phrased differently from the description for SENDER role. View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1659] R0305, 0306 Support for SSL
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1659 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:37:12 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1659&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1659&group_id…) Summary: R0305, 0306 Support for SSL Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1659 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:37:12 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:37:12 Assigned To: &lt;None&gt; File(s): <None> Description: Does the use of SSL violates the conformance statement? Shoud we preclude SSL? Takuya to follow up on distinction between ssl and tls. View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1658] R0301 Requiring support for both TLS and MLS is too much.
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1658 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:34:02 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1658&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1658&group_id…) Summary: R0301 Requiring support for both TLS and MLS is too much. Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1658 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:34:02 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:34:02 Assigned To: &lt;None&gt; File(s): <None> Description: Requiring support for both TLS and MLS is too much. The consensus is: ---- Proposed and accepted to focus the secure channel profile on just TLS in the interests of making quick progress. Leave MLS out until the requirements for it are made clear. MLS may be included in a later version; or a separate profile for it may be defined. Action: Takuya and Frank to re-check the WS-I BSP for the MLS choices and which portions of those might be refined in an OGSA security profile. from the Sep28th call minuts ---- View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1657] Missing extensibility points?
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1657 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:31:07 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1657&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1657&group_id…) Summary: Missing extensibility points? Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1657 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:31:07 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:31:07 Assigned To: &lt;None&gt; File(s): <None> Description: WS-I BSP 1.0 has seven extensibility points. Now the v005 draft has five. Check if the missing ones need not to be included. View the Secure Channel 1.0 : 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 | Secure Channel 1.0 - 1656] Claiming Conformance
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1656 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:27:58 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1656&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1656&group_id…) Summary: Claiming Conformance Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1656 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:27:58 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:27:58 Assigned To: &lt;None&gt; File(s): <None> Description: Hiro pointed out that the previous draft of the profile missed a conformance claim URI, OGSABasicProfile-1.0. Now the v.005 of the profile has some text for the conformance claim URI. Check if the description is good or not. View the Secure Channel 1.0 : 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

Minutes: Teleconf, GGF15, F2F
by Andreas Savva 17 Oct '05

17 Oct '05

Teleconf: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050928/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051012/en/1 GGF15: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-1/… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-2/… F2F: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… -- Andreas Savva

1 0