- dmis-bof - lists.ogf.org

RE: [dmis-bof] Vote for submission of Charter
by James Casey 21 Mar '06

21 Mar '06

> -----Original Message----- > From: owner-dmis-bof(a)ggf.org [mailto:owner-dmis-bof@ggf.org] > On Behalf Of Arie Shoshani > Sent: 20 March 2006 23:06 > To: allcock(a)mcs.anl.gov > Cc: dmis-bof(a)ggf.org; Peter Kunszt; 'Alex Sim'; Timur Perelmutov > Subject: Re: [dmis-bof] Vote for submission of Charter > > > > Well, in this case there is probably some overlap with the > DAIS activity (or whatever they call it now). It is > interesting how far one can use the file paradigm to include > other types of data, or vice versa. Again, I am not sure it > is worth pushing this item into your agenda. I am neutral on this. > > As to someone to handle the srm_copy WSDL, in theory anyone who can > > read WSDL could do that, but it will be the ensuing discussion that > > will be more important, and where the SRM communities > viewpoint would > > be useful. Could whoever is leading the gsm WG meeting > handle this? > > Or is there not going to be a gsm WG meeting at this GGF? > > > So far, we chose to skip GGF17 as far as GSM is concerned. > But, perhaps we could prepare some slides and somebody like > James Casey could present that. > Arie, That's fine with me. Peter Kunszt might be coming too, I'm not sure. James. > Timur, if you are reading this email - are you going to GGF in Tokyo? > > It would be best if someone was present from all the concerned > > parties, but if not, there will be discussions via email and future > > GGFs. I don't really see an option other than proceeding > as best we > > can with those that can make it. > > > I understand. > > Arie > >

1 0

RE: [dmis-bof] Vote for submission of Charter
by James Casey 20 Mar '06

20 Mar '06

Bill, I'll cover the FTS at GGF17. Cheers, James. > -----Original Message----- > From: owner-dmis-bof(a)ggf.org [mailto:owner-dmis-bof@ggf.org] > On Behalf Of William E. Allcock > Sent: 18 March 2006 20:12 > To: dmis-bof(a)ggf.org > Subject: [dmis-bof] Vote for submission of Charter > > DOH! I thought this went out yesterday morning. > > --------------------------------------------- > > All, > > The deadline for getting our charter in is fast approaching > (it may be today, I have sent mail to ask). I would like to > call for a vote on the current charter (attached). If anyone > has any objections to submitting as is, please speak up > immediately. Note that there is now the concept of a living > charter, so we can make changes if necessary. > > Also, need to know if anyone objects violently to going with > DMIS as the name. > > Also, per our proposed schedule we would have two sessions in > Tokyo, one of which is the WSDL presentation, the second is > discussion and a start at trying to extract the common > elements for the functional spec. > > I will handle the presentation for RFT WSDL. > Can we have a volunteer that will be at GGF17 volunteer for: > > - srm_copy? Alex? > - FTS? Erwin? > - Unicore (not even sure that is the right way to reference > it)? Michel? > > I look forward to working with you on this. > > Bill > > --------------------------------------------------------------- > William E. Allcock > Argonne National Laboratory > Bldg 221, Office B-139 > 9700 South Cass Ave > Argonne, IL 60439-4844 > Email: allcock(a)mcs.anl.gov > Office Phone: +1-630-252-7573 > Office Fax: +1-630-252-1997 > Cell Phone: +1-630-854-2842 > >

1 0

Updated Charter
by William E. Allcock 18 Mar '06

18 Mar '06

All, Michel and I have updated the charter based on discussions that took place at GGF16. They are already scheduling slots for next GGF, so we need to ratify this charter ASAP and become a full fledged working group. The charter is short, only a couple of pages of text and a table with goals and timelines. This shouldn't take long, so please take a few minutes now and review this. In particular we would like comments on: - Do you agree with the focus and scope - Do you think the Goals and timeline are reasonable? Are we missing anything? - Which documents / implementations would you be willing to work on? Thanks, and I hope to see you in Tokyo. Bill --------------------------------------------------------------- William E. Allcock Argonne National Laboratory Bldg 221, Office B-139 9700 South Cass Ave Argonne, IL 60439-4844 Email: allcock(a)mcs.anl.gov Office Phone: +1-630-252-7573 Office Fax: +1-630-252-1997 Cell Phone: +1-630-854-2842

7 18

RE: [dmis-bof] Updated Charter
by Dave Berry 16 Mar '06

16 Mar '06

I agree, this is looking good. Dave. _____ From: owner-dmis-bof(a)ggf.org [mailto:owner-dmis-bof@ggf.org] On Behalf Of Allen Luniewski Sent: 15 March 2006 18:58 To: allcock(a)mcs.anl.gov Cc: dmis-bof(a)ggf.org; 'Hiro Kishimoto'; 'Michel Drescher' Subject: RE: [dmis-bof] Updated Charter Bill, Thanks for taking care of my concerns! From my perspective, I think that the charter is just fine and we are nearing the "polishing the round ball" stage, if we are not already there. So, I am agreeable to submitting this charter to the area directors for consideration. DMIS works just fine for me as a name. Allen "William E. Allcock" <allcock(a)mcs.anl.gov> 03/15/2006 05:59 AM Please respond to <allcock(a)mcs.anl.gov> To "'Michel Drescher'" <Michel.Drescher(a)uk.fujitsu.com>, "'Hiro Kishimoto'" <hiro.kishimoto(a)jp.fujitsu.com>, "'Allen Luniewski'" <luniew(a)almaden.ibm.com> cc <dmis-bof(a)ggf.org> Subject RE: [dmis-bof] Updated Charter I added the suggested Document goals, but also left the existing table as I think it gives more detailed info and will be better for tracking WG progress in the short term. It has been suggested that DMI is already a well known acronym and we should change it. The floor is open for suggestions. I know that this has already been panned because by definition we are doing standards, but I am going to again suggest Data Movement Interface Standardization (DMIS), because it solves our overlapping acronym problem AND it is easy to say (dee-miss). Other suggestions? I have also attached my draft of the 7 questions. Bill > -----Original Message----- > From: Michel Drescher [mailto:Michel.Drescher@uk.fujitsu.com] > Sent: Wednesday, March 15, 2006 6:16 AM > To: Hiro Kishimoto; Allen Luniewski > Cc: William E. Allcock; dmis-bof(a)ggf.org > Subject: Re: [dmis-bof] Updated Charter > > Hiro, Allen, all, > > I took the pen on the charter again, and tried to incorporate your > comments. I passed it to Bill for a brush and further work, so that > there should be an updated charter soon. > > Cheers, > Michel > > On 15 Mar 2006, at 3:04, Hiro Kishimoto wrote: > > > Hi Bill, > > > > Thank you very much for revising WG charter document. > > In general, it sounds good to me. > > > > The following is my comments; > > > > (1) Goals section > > Given that GFSG is now asking all WG/RG co-chairs to maintain web > > based > > "Living Charter" (see attached OGSA-WG example), I recommend to > > organize goals section based on deliverable documents. > > > > Goals section has list of documents and each document has > > - title > > - abstract > > - type > > - milestones (date for first draft, public comment, publication) > > > > (2) transport document > > Goals section says this WG will create "transport document" but > > focus/purpose and scope sections don't mention this. Please > > explain what is transport document in these previous sections. > > > > (3) 7 Q&A document > > Please update and send out 7 Q&A document as well as charter. > > You need to provide both to your area director for WG approval. > > > > (4) reference > > > > "OGSA WSRF Basic Profile Rendering 1.0, GFD.59, T. Maguire, D. > > Snelling, > > Global Grid Forum, January 2006" > > > > should be > > > > "[OGSA WSRF BP] OGSA WSRF Basic Profile 1.0, Foster, I., > Maguire, T., > > and Snelling, D. Global Grid Forum, GWD-R, September 2005. > > > http://www.ggf.org/Public_Comment_Docs/Documents/Oct-2005/draft-ggf- > > ogsa-wsrf-basic-profile-v43.pdf" > > > > (5) Management issues > > I would add the following sentence to this section; > > > > The WG will have joint review discussion with the OGSA-WG and the > > OGSA-D-WG before every milestone. > > > > (5) DMI > > The Desktop Management Interface (DMI) is rather well known in > > IT industry. Do you have any other alphabet soup (e.g. Interface > > of Data Movement: IDM). > > > > p.s. > > OGSA-WG will have interim F2F meeting in San Francisco Bay Area > > from April 4-7. If you want to have session at this F2F meeting > > please provide agenda and how long do you need. > > > > https://forge.gridforum.org/projects/ogsa-wg/document/ > > 200604F2F_session > > > > Thanks, > > ---- > > Hiro Kishimoto > > > > William E. Allcock wrote: > >> Ok, next iteration is attached. We tried to address the comments > >> we had > >> received so far. > >> Bill > >>> -----Original Message----- > >>> From: owner-dmis-bof(a)ggf.org [mailto:owner-dmis-bof@ggf.org] On > >>> Behalf Of Robert B. Wood > >>> Sent: Tuesday, March 14, 2006 10:07 AM > >>> To: Michel Drescher > >>> Cc: allcock(a)mcs.anl.gov; dmis-bof(a)ggf.org > >>> Subject: Re: [dmis-bof] Updated Charter > >>> > >>> In my opinion, "4th party data transfer" as a term such as > >>> described below offers more debate than value. To my > >>> understanding, a 3rd party copy operation is a data transfer > >>> between two data stores that is initiated by [at least] one of > >>> the data stores or devices themselves, without the aid or > >>> instruction of the user or their server/application code. > It was > >>> originally coined in the realm of data backup. > >>> > >>> When an agent of the user (including the user him or herself) > >>> initiates a data transfer and the data transfer path > includes the > >>> user's system, that is a first party operation. When an agent > >>> initiates a data transfer directly between two data stores or > >>> devices, without placing their server in the data stream, > this is > >>> an extended data movement operation; what is referred to as > >>> extended copy or serverless backup in the data backup realm. > >>> > >>> The usage of these terms is pretty well codified in the SCSI-3 > >>> specification and implemented in storage products. > >>> I'm not suggesting that management of agents, like the "truly > >>> independent service" that Michel describes is trivial, in fact > >>> the data security aspects can be quite challenging. Also the > >>> line between direct control and independent operations is pretty > >>> fuzzy, as data movements rarely occur without some user > >>> involvement, be it simply an exersize of a service level > >>> agreement with the data storage service provider[s]. > >>> > >>> Just a couple of comments to the comments to the comments ... Bob > >>> > >>> Michel Drescher wrote: > >>> > >>> > >>>> Bill, > >>>> > >>>> some comments, related to the comments you put in the > >>> > >>> charter document: > >>> > >>>> 4th party data transfer: > >>>> I see 3 different scenarios for data movement. Let's assume > >>> > >>> we have a > >>>> (data) source and a (data) destination. We also have a user > >>>> that wants data moved. If the user is the source, we have a > >>>> direct pull case, if the user is the destination, then we have > >>>> a direct push case. If the user tells the source to move some > >>>> data to the destination, then this is 3rd party push, if the > >>>> user tells the destination to get some data, then this is 3rd > >>>> party pull. > >>>> Well, if the user tells a truly independent service to initiate > >>>> a data transfer from source to target, then this is very > >>> > >>> similar to 3rd > >>>> party data transfer, but different enough as there is a 4th > >>> > >>> instance > >>>> participating in the data movement. > >>>> > >>>> Transport protocols: > >>>> Yes I meant application level protocols from a network > >>> > >>> point of view, > >>>> such as GridFTP, HTTP, FTP, etc. > >>>> > >>>> > >>>> Regarding the timeline: > >>>> The short term planning is ambitious, but manageable, I think, > >>>> especially if we can appreciate broad contribution support. > >>>> > >>>> Cheers, > >>>> Michel > >>>> > >>>> On 13 Mar 2006, at 22:41, William E. Allcock wrote: > >>>> > >>>> > >>>>> All, > >>>>> > >>>>> Michel and I have updated the charter based on discussions > >>> > >>> that took > >>>>> place > >>>>> at GGF16. They are already scheduling slots for next GGF, so > >>>>> we need to > >>>>> ratify this charter ASAP and become a full fledged working > >>> > >>> group. The > >>> > >>>>> charter is short, only a couple of pages of text and a table > >>>>> with goals and > >>>>> timelines. This shouldn't take long, so please take a few > >>> > >>> minutes > >>>>> now and > >>>>> review this. > >>>>> > >>>>> In particular we would like comments on: > >>>>> > >>>>> - Do you agree with the focus and scope > >>>>> - Do you think the Goals and timeline are reasonable? > >>> > >>> Are we missing > >>> > >>>>> anything? > >>>>> - Which documents / implementations would you be willing > >>> > >>> to work on? > >>> > >>>>> Thanks, and I hope to see you in Tokyo. > >>>>> > >>>>> Bill > >>>>> > >>>>> --------------------------------------------------------------- > >>>>> William E. Allcock > >>>>> Argonne National Laboratory > >>>>> Bldg 221, Office B-139 > >>>>> 9700 South Cass Ave > >>>>> Argonne, IL 60439-4844 > >>>>> Email: allcock(a)mcs.anl.gov > >>>>> Office Phone: +1-630-252-7573 > >>>>> Office Fax: +1-630-252-1997 > >>>>> Cell Phone: +1-630-854-2842 > >>>>> > >>>>> <charter-v3.doc> > >>>> > >>>> > >>> -- > >>> Bob Wood > >>> Network Storage Architecture Office > >>> Sun Microsystems Inc. > >>> > >>> 303.395.3801 (x43011) > >>> Robert.B.Wood(a)Sun.com > >>> > >>> > >>> <Charter for OGSA-WG.pdf> > > [attachment "DMIS GFSG Questions.doc" deleted by Allen Luniewski/Almaden/IBM] [attachment "charter-v6.doc" deleted by Allen Luniewski/Almaden/IBM]

1 0

FW: BOUNCE dmis-bof@ggf.org: Non-member submission from [Toshiyuki Nakata <nakata@mtg.biglobe.ne.jp>]
by William E. Allcock 15 Mar '06

15 Mar '06

Forwarding a bounced message. ------------------------------------ Date: Thu, 16 Mar 2006 01:32:18 +0900 From: Toshiyuki Nakata <nakata(a)mtg.biglobe.ne.jp> To: Hiro Kishimoto <hiro.kishimoto(a)jp.fujitsu.com> Cc: allcock(a)mcs.anl.gov, "'Robert B. Wood'" <Robert.B.Wood(a)Sun.COM>, "'Michel Drescher'" <Michel.Drescher(a)uk.fujitsu.com>, dmis-bof(a)ggf.org, graap-wg(a)gridforum.org Subject: Re: [graap-wg] Re: [dmis-bof] Updated Charter Hi: My name is Toshiyuki Nakata (or just Toshi) one of the members of GRAAP-WG. (Hiro: Thank you very much for the pointer) The WS-Agreement Spec that had been submitted for review can be found in http://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificat ionDraft.doc/en/17 There is also a newer one ( which we're currently working on trying to reflect all the valuable comments made during the Public Comments Period) in https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecifica tionDraft.doc/en I can also send you some tutorial material that I together with another group member made if you like. Hope you find it useful. Best Regards Toshi Hiro Kishimoto wrote: > Hi Bill, > > One more comment. > > Scope section says > >> This Working Group will define two Web Service interfaces. The first > > > interface deals with the agreement on a particular transport protocol > > used for a data movement. The second interface defines the invocation > > of the data movement itself, and the associated aspects of > > reliability, transfer scheduling, granularity, performance settings, > > control, and progress. > > Are you familiar with WS-Agreement specification by GRAAP-WG? > Can you include investigation of applicability of WS-Agreement to > your interface as an WG's activity? > > Thanks, > ---- > Hiro Kishimoto > > Hiro Kishimoto wrote: > >> Hi Bill, >> >> Thank you very much for revising WG charter document. >> In general, it sounds good to me. >> >> The following is my comments; >> >> (1) Goals section >> Given that GFSG is now asking all WG/RG co-chairs to maintain web based >> "Living Charter" (see attached OGSA-WG example), I recommend to >> organize goals section based on deliverable documents. >> >> Goals section has list of documents and each document has >> - title >> - abstract >> - type >> - milestones (date for first draft, public comment, publication) >> >> (2) transport document >> Goals section says this WG will create "transport document" but >> focus/purpose and scope sections don't mention this. Please >> explain what is transport document in these previous sections. >> >> (3) 7 Q&A document >> Please update and send out 7 Q&A document as well as charter. >> You need to provide both to your area director for WG approval. >> >> (4) reference >> >> "OGSA WSRF Basic Profile Rendering 1.0, GFD.59, T. Maguire, D. Snelling, >> Global Grid Forum, January 2006" >> >> should be >> >> "[OGSA WSRF BP] OGSA WSRF Basic Profile 1.0, Foster, I., Maguire, T., >> and Snelling, D. Global Grid Forum, GWD-R, September 2005. >> http://www.ggf.org/Public_Comment_Docs/Documents/Oct-2005/draft-ggf-ogsa-wsr f-basic-profile-v43.pdf" >> >> >> (5) Management issues >> I would add the following sentence to this section; >> >> The WG will have joint review discussion with the OGSA-WG and the >> OGSA-D-WG before every milestone. >> >> (5) DMI >> The Desktop Management Interface (DMI) is rather well known in >> IT industry. Do you have any other alphabet soup (e.g. Interface >> of Data Movement: IDM). >> >> p.s. >> OGSA-WG will have interim F2F meeting in San Francisco Bay Area >> from April 4-7. If you want to have session at this F2F meeting >> please provide agenda and how long do you need. >> >> https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session >> >> Thanks, >> ---- >> Hiro Kishimoto >> >> William E. Allcock wrote: >> >>> Ok, next iteration is attached. We tried to address the comments we had >>> received so far. >>> >>> Bill >>> >>>> -----Original Message----- >>>> From: owner-dmis-bof(a)ggf.org [mailto:owner-dmis-bof@ggf.org] On >>>> Behalf Of Robert B. Wood >>>> Sent: Tuesday, March 14, 2006 10:07 AM >>>> To: Michel Drescher >>>> Cc: allcock(a)mcs.anl.gov; dmis-bof(a)ggf.org >>>> Subject: Re: [dmis-bof] Updated Charter >>>> >>>> In my opinion, "4th party data transfer" as a term such as described >>>> below offers more debate than value. To my understanding, a 3rd >>>> party copy operation is a data transfer between two data stores that >>>> is initiated by [at least] one of the data stores or devices >>>> themselves, without the aid or instruction of the user or their >>>> server/application code. It was originally coined in the realm of >>>> data backup. >>>> >>>> When an agent of the user (including the user him or herself) >>>> initiates a data transfer and the data transfer path includes the >>>> user's system, that is a first party operation. When an agent >>>> initiates a data transfer directly between two data stores or >>>> devices, without placing their server in the data stream, this is an >>>> extended data movement operation; what is referred to as extended >>>> copy or serverless backup in the data backup realm. >>>> >>>> The usage of these terms is pretty well codified in the SCSI-3 >>>> specification and implemented in storage products. >>>> I'm not suggesting that management of agents, like the "truly >>>> independent service" that Michel describes is trivial, in fact the >>>> data security aspects can be quite challenging. Also the line >>>> between direct control and independent operations is pretty fuzzy, >>>> as data movements rarely occur without some user involvement, be it >>>> simply an exersize of a service level agreement with the data >>>> storage service provider[s]. >>>> >>>> Just a couple of comments to the comments to the comments ... Bob >>>> >>>> Michel Drescher wrote: >>>> >>>> >>>>> Bill, >>>>> >>>>> some comments, related to the comments you put in the >>>> >>>> >>>> >>>> charter document: >>>> >>>>> 4th party data transfer: >>>>> I see 3 different scenarios for data movement. Let's assume >>>> >>>> >>>> >>>> we have a >>>> >>>>> (data) source and a (data) destination. We also have a user that >>>>> wants data moved. If the user is the source, we have a direct pull >>>>> case, if the user is the destination, then we have a direct push >>>>> case. If the user tells the source to move some data to the >>>>> destination, then this is 3rd party push, if the user tells the >>>>> destination to get some data, then this is 3rd party pull. >>>>> Well, if the user tells a truly independent service to initiate a >>>>> data transfer from source to target, then this is very >>>> >>>> >>>> >>>> similar to 3rd >>>> >>>>> party data transfer, but different enough as there is a 4th >>>> >>>> >>>> >>>> instance >>>> >>>>> participating in the data movement. >>>>> >>>>> Transport protocols: >>>>> Yes I meant application level protocols from a network >>>> >>>> >>>> >>>> point of view, >>>> >>>>> such as GridFTP, HTTP, FTP, etc. >>>>> >>>>> >>>>> Regarding the timeline: >>>>> The short term planning is ambitious, but manageable, I think, >>>>> especially if we can appreciate broad contribution support. >>>>> >>>>> Cheers, >>>>> Michel >>>>> >>>>> On 13 Mar 2006, at 22:41, William E. Allcock wrote: >>>>> >>>>> >>>>>> All, >>>>>> >>>>>> Michel and I have updated the charter based on discussions >>>> >>>> >>>> >>>> that took >>>> >>>>>> place >>>>>> at GGF16. They are already scheduling slots for next GGF, so we >>>>>> need to >>>>>> ratify this charter ASAP and become a full fledged working >>>> >>>> >>>> >>>> group. The >>>> >>>>>> charter is short, only a couple of pages of text and a table with >>>>>> goals and >>>>>> timelines. This shouldn't take long, so please take a few >>>> >>>> >>>> >>>> minutes >>>> >>>>>> now and >>>>>> review this. >>>>>> >>>>>> In particular we would like comments on: >>>>>> >>>>>> - Do you agree with the focus and scope >>>>>> - Do you think the Goals and timeline are reasonable? >>>> >>>> >>>> >>>> Are we missing >>>> >>>>>> anything? >>>>>> - Which documents / implementations would you be willing >>>> >>>> >>>> >>>> to work on? >>>> >>>>>> Thanks, and I hope to see you in Tokyo. >>>>>> >>>>>> Bill >>>>>> >>>>>> --------------------------------------------------------------- >>>>>> William E. Allcock >>>>>> Argonne National Laboratory >>>>>> Bldg 221, Office B-139 >>>>>> 9700 South Cass Ave >>>>>> Argonne, IL 60439-4844 >>>>>> Email: allcock(a)mcs.anl.gov >>>>>> Office Phone: +1-630-252-7573 >>>>>> Office Fax: +1-630-252-1997 >>>>>> Cell Phone: +1-630-854-2842 >>>>>> >>>>>> <charter-v3.doc> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> Bob Wood >>>> Network Storage Architecture Office >>>> Sun Microsystems Inc. >>>> >>>> 303.395.3801 (x43011) >>>> Robert.B.Wood(a)Sun.com >>>> >>>> > > >

1 0

RE: [dmis-bof] Change of Plans
by Dave Berry 10 Feb '06

10 Feb '06

I'll be there. Dave. -----Original Message----- From: owner-dmis-bof(a)ggf.org [mailto:owner-dmis-bof@ggf.org] On Behalf Of William E. Allcock Sent: 09 February 2006 16:23 To: allcock(a)mcs.anl.gov; dmis-bof(a)ggf.org Subject: RE: [dmis-bof] Change of Plans We are in luck. Michel Drescher has been kind enough to step up and will run the BOF. The time, place, and agenda are unchanged. It is imperative that we come to resolution on our charter. I will be working with Michel to hand off as much "state" as possible between now and then. My previous message is below for your reference. Bill ------------------------- We have a session at GGF 16, in Athens, Greece at 8:30 AM, on Wednesday the 15th of February, in the Pella room. We are basically at a turning point here. We need to reach agreement on our charter (can we agree on what we want out of this) and get a commitment from people to put in some effort, or decide that we don't have critical mass and let the effort go. > -----Original Message----- > From: owner-dmis-bof(a)ggf.org [mailto:owner-dmis-bof@ggf.org] > On Behalf Of William E. Allcock > Sent: Tuesday, February 07, 2006 5:14 PM > To: dmis-bof(a)ggf.org > Subject: [dmis-bof] Change of Plans > > > The Department of Energy (DOE) has chosen not to approve any > DOE employee > participation in GGF this time. It is a "paperwork snafu" > rather than "we > don't think GGF is important" issue, but the result is the > same, I wont be > able to attend GGF. > > Please let me know if someone is willing to try and lead the > session or if I > should cancel. > > Sorry for the short notice. I found out about an hour ago. > > Bill > > --------------------------------------------------------------- > William E. Allcock > Argonne National Laboratory > Bldg 221, Office B-139 > 9700 South Cass Ave > Argonne, IL 60439-4844 > Office Phone: +1-630-252-7573 > Office Fax: +1-630-252-1997 > Cell Phone: +1-630-854-2842 > > >

1 0

Change of Plans
by William E. Allcock 09 Feb '06

09 Feb '06

The Department of Energy (DOE) has chosen not to approve any DOE employee participation in GGF this time. It is a "paperwork snafu" rather than "we don't think GGF is important" issue, but the result is the same, I wont be able to attend GGF. Please let me know if someone is willing to try and lead the session or if I should cancel. Sorry for the short notice. I found out about an hour ago. Bill --------------------------------------------------------------- William E. Allcock Argonne National Laboratory Bldg 221, Office B-139 9700 South Cass Ave Argonne, IL 60439-4844 Office Phone: +1-630-252-7573 Office Fax: +1-630-252-1997 Cell Phone: +1-630-854-2842

1 1

GGF 16
by William E. Allcock 07 Feb '06

07 Feb '06

All, We have a session at GGF 16, in Athens, Greece at 8:30 AM, on Wednesday the 15th of February, in the Pella room. We are basically at a turning point here. We need to reach agreement on our charter (can we agree on what we want out of this) and get a commitment from people to put in some effort, or decide that we don't have critical mass and let the effort go. See you in Greece! Bill --------------------------------------------------------------- William E. Allcock Argonne National Laboratory Bldg 221, Office B-139 9700 South Cass Ave Argonne, IL 60439-4844 Office Phone: +1-630-252-7573 Office Fax: +1-630-252-1997 Cell Phone: +1-630-854-2842

2 1

AW: [dmis-bof] Comments on the charter?
by Peter Kunszt 22 Dec '05

22 Dec '05

hi ian, i fully agree with the aims for DMI. of course you need a unique ID for the transfers by which you can refer to them from the client side. and all the rest. but for defining how to do all this, i questioned the relevance of WSRF or WS-I. i said that we should try to define the interface without going into the rendering. to this bill replied that we have to fix that 'detail' already before we start otherwise interoperability is not guaranteed. and he may be right. at least this is what i understood, so please correct me if i missed the point. to answer your question: what my concern is that at least to someone like myself who only follows the development of WSRF sporadically, it is not clear to what extent we'll have to delve into detailed modifications of our current services if we are to do it using WSRF. to be honest, we didn't have the time to gather the necessary experience. so it's your basic 'fear of all that is new'. it's hard for us to estimate the amount of work involved, and resources are scarce (getting worse not better) while the timelines given for completion of the services are over-ambitious. so if you want interoperability with EGEE within say the next 6-12 months, there are not many options... it's really not the lack of willingness but simply the lack of means and of time. so that's all there is to it, no political or religious reasons whatsoever. anyway, i will hand over the 'defense of the EGEE viewpoint' to others in the new year as i'll move to a new position at the swiss supercomputing center near Lugano (see cscs.ch). i'll be responsible for the swiss national grid programme. so i'll certainly be still quite involved, but you may hear very different concerns from me in the near future :-) best regards to sunny australia, have a great holiday and i wish you a happy new year peter (i'll be out of email contact until jan.9th) -- CERN IT-Grid Middleware ________________________________ Von: Ian Foster [mailto:foster@mcs.anl.gov] Gesendet: Do 22.12.2005 08:42 An: Peter Kunszt; allcock(a)mcs.anl.gov; Hiro Kishimoto Cc: dmis-bof(a)ggf.org Betreff: RE: [dmis-bof] Comments on the charter? Peter: (I'm online very briefly in Australia, not back until January 3rd ...) I am always trying to understand the concerns that motivate the "WS-I vs. WSRF" debate, so I'd be very grateful if you could help elucidate the concerns that underlie your email below. In DMI, we want to be able to request the creation of transfers, monitor the status of those transfers, and control their progress (e.g., cancel them). Thus, we need (as is often the case) constructs in our interface for "naming" transfers, for requesting information about their state, and for performing control operations. WSRF standardizes some operations for doing these things: WS-Addressing EPRs for naming transfers, WS-ResourceProperties operations for accessing state, and WS-ResourceLifetime operations for control. We also have the option of using WS-Notification mechanisms for notification of state changes, if desired. Modulo the use of EPRs, these operations are all WS-I compliant. Thus, two questions: * When you say you want a "WS-I" interface, do you mean that you don't want to use EPRs to name things? If so, can you explain the reasons why? * If you are ok with EPRs, but don't want to use WSRF interfaces for state access and control operations, can you explain the reason for this? It seems to me that you're just saying that you want to use different operation names than those defined in the WSRF specifications. I don't understand the advantages of substituting different names for what will be essentially the same operations. Regards -- Ian. At 03:30 PM 12/14/2005 +0100, Peter Kunszt wrote: hi bill here it comes - my dreaded comments ;-) > - I changed the name to OGSA-DMI i don't like that. having my EGEE hat on, please consider that we cannot adapt and use OGSA in any of the near future (next year) as everything is set up for production pretty much now. there is no time for us to migrate to OGSA quickly and to deploy and use it. there are lots of question marks concerning especially the security infrastructure and how that will interoperate with classical transport-level security. so to recap: we would very much appreciate a pure WS-I interface standardization first, where we can talk cleanly about interfaces and semantics and we would not clog our discussions about which semantics of WSRF should be applied to what. we could focus on the transfer specs. then someone can take the spec and 'ogsafy' it. so please consider to keep this just as DMIS-WG. (sorry hiro - i have to be pragmatic here) > - we need to address naming. What will we accept as source > and destination names? URLs? URIs? any string? EPRs? URL seems like a good choice, this would probably suit all use cases. this is what we use in the GSM-WG. we have storage URLs. an EPR is nothing more than a decorated URL so a simple URL would suit that too. > - There is a general issue which will affect a lot of this > and that is just extensible WSDL. How do we allow parameters > to change when options in the WSDL change. the pragmatic approach is to increase the minor version number for compatible changes and the major one for incompatible changes. however, there are alternatives that we have investigated also in the GSM-WG: it is possible to leave an extensibility hook in the WSDL, so that new functionality can be tried on existing services, before it is migrated into the mainstream WSDL. this is a good idea also for interoperating between versions. > - I think we all agree that this needs to be transport > agnostic, but we need to figure out how best to implement > that (related to the WSDL question) unless i'm mistaken, doc/literal should just do the trick..? > - what statement do we want to make (and does the OGSA data > architecture > need) about delivery semantics i think we need to make as detailed statements as possible/reasonable! we need to define what states the transfer service exposes to the client and what failure modes the client has to expect. > - what about scheduling / planning aspects? Do we want to > include elements in this WSDL that specify rate (bandwidth), > quantity (file size), and timing (START BY, FINISH BY, etc) our experience: individually for each transfer job: no. that is very complicated and of questionable use. on the scale of the service itself as a service parameter/configuration: yes. > - everybody's favorite: security. I hope we can basically > punt on this and say we will do whatever OGSA does well.. please see http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf and the discussion here on transport and message-level security. GT4 currently supports both in parallel. together with my comment on top, i think for this essential service we need to at least task the OGSA security group to give us a clear path of how both can interoperate and what are the migration paths. this is highly nontrivial and until it is not given, it will not be practical for us to talk about message-level security at all. we don't have the effort available to do what GT4 did and to run both everywhere. > - A sort of pet project of mine is monitoring / > troubleshooting. I would like to potentially include > elements in the WSDL or state that is exposed that would > enable better/easier monitoring and troubleshooting. For > instance, some sort of unique job identifier that can be > passed down to children, so that you can trace the chain back > when you have a failure. yes, statistics gathering is another one. very important to have - i already sent the wsdl's we have today to this list.. > - groups that we need to be aware of to one extent or > another include OGSA, OGSA-D, info-d, gsm, byte-io, naming, > grid file systems, authz (other security groups), > ws-agreement (GRAAP?). are there others? how should we > liaise with those groups? some will require more work than others. :-) the best thing to have is if there are individuals participating in both who can act as liaisons. i am happy to take gsm and parts of ogsa-d, together with you of course. > > Let me know what you think. keep'em coming ;-) cheers peter _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

1 0

FW: BOUNCE dmis-bof@ggf.org: Non-member submission from [Ian Foster <foster@mcs.anl.gov>]
by William E. Allcock 22 Dec '05

22 Dec '05

A mail from Ian Foster bounced... -----Original Message----- Date: Thu, 22 Dec 2005 01:42:31 -0600 To: "Peter Kunszt" <Peter.Kunszt(a)cern.ch>, <allcock(a)mcs.anl.gov>, "Hiro Kishimoto" <hiro.kishimoto(a)jp.fujitsu.com> From: Ian Foster <foster(a)mcs.anl.gov> Subject: RE: [dmis-bof] Comments on the charter? Cc: <dmis-bof(a)ggf.org> Peter: (I'm online very briefly in Australia, not back until January 3rd ...) I am always trying to understand the concerns that motivate the "WS-I vs. WSRF" debate, so I'd be very grateful if you could help elucidate the concerns that underlie your email below. In DMI, we want to be able to request the creation of transfers, monitor the status of those transfers, and control their progress (e.g., cancel them). Thus, we need (as is often the case) constructs in our interface for "naming" transfers, for requesting information about their state, and for performing control operations. WSRF standardizes some operations for doing these things: WS-Addressing EPRs for naming transfers, WS-ResourceProperties operations for accessing state, and WS-ResourceLifetime operations for control. We also have the option of using WS-Notification mechanisms for notification of state changes, if desired. Modulo the use of EPRs, these operations are all WS-I compliant. Thus, two questions: * When you say you want a "WS-I" interface, do you mean that you don't want to use EPRs to name things? If so, can you explain the reasons why? * If you are ok with EPRs, but don't want to use WSRF interfaces for state access and control operations, can you explain the reason for this? It seems to me that you're just saying that you want to use different operation names than those defined in the WSRF specifications. I don't understand the advantages of substituting different names for what will be essentially the same operations. Regards -- Ian. At 03:30 PM 12/14/2005 +0100, Peter Kunszt wrote: >hi bill > >here it comes - my dreaded comments ;-) > > > - I changed the name to OGSA-DMI > >i don't like that. having my EGEE hat on, please consider that we cannot >adapt and use OGSA in any of the near future (next year) as everything >is set up for production pretty much now. there is no time for us to migrate >to OGSA quickly and to deploy and use it. there are lots of question marks >concerning especially the security infrastructure and how that will >interoperate >with classical transport-level security. > >so to recap: we would very much appreciate a pure WS-I interface >standardization >first, where we can talk cleanly about interfaces and semantics and we >would not >clog our discussions about which semantics of WSRF should be applied to >what. we >could focus on the transfer specs. then someone can take the spec and >'ogsafy' it. >so please consider to keep this just as DMIS-WG. (sorry hiro - i have to >be pragmatic here) > > > - we need to address naming. What will we accept as source > > and destination names? URLs? URIs? any string? EPRs? > >URL seems like a good choice, this would probably suit all use cases. >this is what we use in the GSM-WG. we have storage URLs. >an EPR is nothing more than a decorated URL so a simple URL would >suit that too. > > > - There is a general issue which will affect a lot of this > > and that is just extensible WSDL. How do we allow parameters > > to change when options in the WSDL change. > >the pragmatic approach is to increase the minor version number >for compatible changes and the major one for incompatible changes. >however, there are alternatives that we have investigated also in >the GSM-WG: it is possible to leave an extensibility hook in the WSDL, >so that new functionality can be tried on existing services, before >it is migrated into the mainstream WSDL. this is a good idea also >for interoperating between versions. > > > - I think we all agree that this needs to be transport > > agnostic, but we need to figure out how best to implement > > that (related to the WSDL question) > >unless i'm mistaken, doc/literal should just do the trick..? > > > - what statement do we want to make (and does the OGSA data > > architecture > > need) about delivery semantics > >i think we need to make as detailed statements as possible/reasonable! >we need to define what states the transfer service exposes to the client >and what failure modes the client has to expect. > > > - what about scheduling / planning aspects? Do we want to > > include elements in this WSDL that specify rate (bandwidth), > > quantity (file size), and timing (START BY, FINISH BY, etc) > >our experience: individually for each transfer job: no. that is very >complicated and of questionable use. >on the scale of the service itself as a service parameter/configuration: yes. > > > - everybody's favorite: security. I hope we can basically > > punt on this and say we will do whatever OGSA does > >well.. please see >http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf > >and the discussion here on transport and message-level security. >GT4 currently supports both in parallel. > >together with my comment on top, i think for this essential service >we need to at least task the OGSA security group to give us a clear >path of how both can interoperate and what are the migration paths. >this is highly nontrivial and until it is not given, it will not be >practical for us to talk about message-level security at all. we don't >have the effort available to do what GT4 did and to run both everywhere. > > > - A sort of pet project of mine is monitoring / > > troubleshooting. I would like to potentially include > > elements in the WSDL or state that is exposed that would > > enable better/easier monitoring and troubleshooting. For > > instance, some sort of unique job identifier that can be > > passed down to children, so that you can trace the chain back > > when you have a failure. > >yes, statistics gathering is another one. very important to have - >i already sent the wsdl's we have today to this list.. > > > - groups that we need to be aware of to one extent or > > another include OGSA, OGSA-D, info-d, gsm, byte-io, naming, > > grid file systems, authz (other security groups), > > ws-agreement (GRAAP?). are there others? how should we > > liaise with those groups? some will require more work than others. > >:-) the best thing to have is if there are individuals participating >in both who can act as liaisons. i am happy to take gsm and parts of >ogsa-d, together with you of course. > > > > > Let me know what you think. > >keep'em coming ;-) > >cheers >peter _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org --=====================_7827395==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Peter: (I'm online very briefly in Australia, not back until January 3rd ...) I am always trying to understand the concerns that motivate the "WS-I vs. WSRF" debate, so I'd be very grateful if you could help elucidate the concerns that underlie your email below. In DMI, we want to be able to request the creation of transfers, monitor the status of those transfers, and control their progress (e.g., cancel them). Thus, we need (as is often the case) constructs in our interface for "naming" transfers, for requesting information about their state, and for performing control operations. WSRF standardizes some operations for doing these things: WS-Addressing EPRs for naming transfers, WS-ResourceProperties operations for accessing state, and WS-ResourceLifetime operations for control. We also have the option of using WS-Notification mechanisms for notification of state changes, if desired. Modulo the use of EPRs, these operations are all WS-I compliant. Thus, two questions: * When you say you want a "WS-I" interface, do you mean that you don't want to use EPRs to name things? If so, can you explain the reasons why? * If you are ok with EPRs, but don't want to use WSRF interfaces for state access and control operations, can you explain the reason for this? It seems to me that you're just saying that you want to use different operation names than those defined in the WSRF specifications. I don't understand the advantages of substituting different names for what will be essentially the same operations. Regards -- Ian. At 03:30 PM 12/14/2005 +0100, Peter Kunszt wrote: <blockquote type=cite class=cite cite>hi bill here it comes  - my dreaded comments ;-) >  - I changed the name to OGSA-DMI i don't like that. having my EGEE hat on, please consider that we cannot adapt and use OGSA in any of the near future (next year) as everything is set up for production pretty much now. there is no time for us to migrate to OGSA quickly and to deploy and use it. there are lots of question marks concerning especially the security infrastructure and how that will interoperate with classical transport-level security. so to recap: we would very much appreciate a pure WS-I interface standardization first, where we can talk cleanly about interfaces and semantics and we would not clog our discussions about which semantics of WSRF should be applied to what. we could focus on the transfer specs. then someone can take the spec and 'ogsafy' it. so please consider to keep this just as DMIS-WG. (sorry hiro - i have to be pragmatic here) >  - we need to address naming.  What will we accept as source > and destination names? URLs? URIs? any string? EPRs? URL seems like a good choice, this would probably suit all use cases. this is what we use in the GSM-WG. we have storage URLs. an EPR is nothing more than a decorated URL so a simple URL would suit that too. >  - There is a general issue which will affect a lot of this > and that is just extensible WSDL.  How do we allow parameters > to change when options in the WSDL change. the pragmatic approach is to increase the minor version number for compatible changes and the major one for incompatible changes. however, there are alternatives that we have investigated also in the GSM-WG: it is possible to leave an extensibility hook in the WSDL, so that new functionality can be tried on existing services, before it is migrated into the mainstream WSDL. this is a good idea also for interoperating between versions. >  - I think we all agree that this needs to be transport > agnostic, but we need to figure out how best to implement > that (related to the WSDL question) unless i'm mistaken, doc/literal should just do the trick..? >  - what statement do we want to make (and does the OGSA data > architecture > need) about delivery semantics i think we need to make as detailed statements as possible/reasonable! we need to define what states the transfer service exposes to the client and what failure modes the client has to expect. >  - what about scheduling / planning aspects?  Do we want to > include elements in this WSDL that specify rate (bandwidth), > quantity (file size), and timing (START BY, FINISH BY, etc) our experience: individually for each transfer job: no. that is very complicated and of questionable use. on the scale of the service itself as a service parameter/configuration: yes. >  - everybody's favorite: security.  I hope we can basically > punt on this and say we will do whatever OGSA does well.. please see <a href="http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf" eudora="autourl">http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Ove rview.pdf</a> and the discussion here on transport and message-level security. GT4 currently supports both in parallel. together with my comment on top, i think for this essential service we need to at least task the OGSA security group to give us a clear path of how both can interoperate and what are the migration paths. this is highly nontrivial and until it is not given, it will not be practical for us to talk about message-level security at all. we don't have the effort available to do what GT4 did and to run both everywhere. >  - A sort of pet project of mine is monitoring / > troubleshooting.  I would like to potentially include > elements in the WSDL or state that is exposed that would > enable better/easier monitoring and troubleshooting.  For > instance, some sort of unique job identifier that can be > passed down to children, so that you can trace the chain back > when you have a failure. yes, statistics gathering is another one. very important to have - i already sent the wsdl's we have today to this list.. >  - groups that we need to be aware of to one extent or > another include OGSA, OGSA-D, info-d, gsm, byte-io, naming, > grid file systems, authz (other security groups), > ws-agreement (GRAAP?).  are there others? how should we > liaise with those groups?  some will require more work than others. :-) the best thing to have is if there are individuals participating in both who can act as liaisons. i am happy to take gsm and parts of ogsa-d, together with you of course. > > Let me know what you think. keep'em coming ;-) cheers peter </blockquote> <x-sigsep></x-sigsep> _______________________________________________________________ <tt>Ian Foster           &nbs p;        <a href="http://www.mcs.anl.gov/~foster" eudora="autourl">www.mcs.anl.gov/~foster</a> Math & Computer Science Div.  Dept of Computer Science Argonne National Laboratory   The University of Chicago    Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A. Tel: 630 252 4619             Fax: 630 252 1997         Globus Alliance, <a href="http://www.globus.org/" eudora="autourl">www.globus.org</a> </body> </html> --=====================_7827395==.ALT--

1 0