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... 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... 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..."
(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@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@mcs.anl.gov; dmis-bof@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@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@Sun.com