[dmis-bof] Updated Charter

Tue Mar 14 23:03:00 CST 2006

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-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 at ggf.org [mailto:owner-dmis-bof at ggf.org] On 
>>> Behalf Of Robert B. Wood
>>> Sent: Tuesday, March 14, 2006 10:07 AM
>>> To: Michel Drescher
>>> Cc: allcock at mcs.anl.gov; dmis-bof at 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 at 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 at Sun.com
>>>
>>>