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
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
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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc. 303.395.3801 (x43011) Robert.B.Wood@Sun.com
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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple is not
there.
Does DMI-WG try to have one common transfer protocol at the minimum on both
source and target sites? If yes, why mandating one particular transfer
protocol, instead of discovering the transfer protocols that source and
target sites support, and matching (agreeing) the transfer protocols to move
data?
--Alex
| -----Original Message-----
| From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org]
| On Behalf Of William E. Allcock
| Sent: Tuesday, March 14, 2006 12:29 PM
| To: 'Robert B. Wood'; 'Michel Drescher'
| Cc: dmis-bof@ggf.org
| Subject: RE: [dmis-bof] Updated Charter
|
| 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
| > >>
| > >>
We are not proposing one particular transfer protocol. That is why we have a completely separate document on the transfer protocols, so that different protocols can have the variations necessary for each. I.e., GridFTP based protocols might specify stripe width, but that makes no sense for http. Bill
-----Original Message----- From: Alex Sim [mailto:asim@lbl.gov] Sent: Tuesday, March 14, 2006 3:16 PM To: allcock@mcs.anl.gov; 'Robert B. Wood'; 'Michel Drescher' Cc: dmis-bof@ggf.org; 'Arie Shoshani' Subject: RE: [dmis-bof] Updated Charter
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simp le is not there.
Does DMI-WG try to have one common transfer protocol at the minimum on both source and target sites? If yes, why mandating one particular transfer protocol, instead of discovering the transfer protocols that source and target sites support, and matching (agreeing) the transfer protocols to move data?
--Alex
| -----Original Message----- | From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org] | On Behalf Of William E. Allcock | Sent: Tuesday, March 14, 2006 12:29 PM | To: 'Robert B. Wood'; 'Michel Drescher' | Cc: dmis-bof@ggf.org | Subject: RE: [dmis-bof] Updated Charter | | 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 | > >> | > >>
| > > | > > | > | > -- | > Bob Wood | > Network Storage Architecture Office | > Sun Microsystems Inc. | > | > 303.395.3801 (x43011) | > Robert.B.Wood@Sun.com | > | > |
Bill, et al, Sorry, I was swamped, and only I had a chance to go over the charter in detail yesterday. I saw a couple of items that I'd like to comment on. 1) Regarding the sentence: "Setting up a data movement includes the selection of a transport protocol, for example GridFTP, and parameters for reliability, timing, scheduling, resource usage, accounting, billing, etc. The Working Group will explore existing mechanisms to reach such agreement, e.g. WS-Agreement and use them where appropriate." Thus, in the setup phase, all kinds of services will have to be contacted, such as components that manage resources, components that perform scheduling, keep track of accounting, etc. For example, to reserve storage space, the data movement service may want to interact with SRMs. I think this is a huge undertaking, and too large of a scope. Even if you go through WS-agreement, it will have to interact with various resource managers, accounting, billing, etc. You may want to leave all the setup to a separate component, like WS-agreement, and then focus on the data movement part. 2) A related point, in the "Seven questions: Evaluation Criteria (from GFD.3)" document it says: "The most direct overlap would be with the gsm-wg, but they are participating in this group and will, presumably, use what is developed here for the transport portion of their interface." Yes, it makes sense for SRMs to make use of powerful transport services, since SRMs rely on transport services. But, when a request is made to an SRM, they take care of managing storage space, keeping track of usage and accounting, as well as perform scheduling, so it does not make sense for the transport services to negotiate storage allocations (including lifetime), scheduling, etc, again, as is suggested in the "setup phase" above. 3) In the charter document, it says: "To accomplish 3^rd party data transfer, a uniform, yet abstract naming scheme for resources (data in general, files in particular) is required. This working group will provide such abstract uniform naming scheme." I think this was the goal of the GFS-WG group, to the extent that I understand what they doing. It might be good to coordinate with them. Also, isn't the issue if a uniform name space (also referred to as logical namespace) and its mapping into physical names fall into the RLS domain (and future related activities). Do you really want to keep track of this mapping as part of the data movement service? Perhaps I don't understand the concept. Please clarify. Thanks, Arie
I find the proposed charter fundamentally sound. I do have two small
issues to raise.
I am surprised that it does not address policy control of data movement.
The charter is mute on the subject of Policy so it does not seem to
consider that out of scope. Policy based data movement seems to be an
essential aspect of a data transport mechanism in the evolving grid space.
I expected (hoped?) to find words asserting that management of an
in-progress data transfer was in scope but did not. Is the belief that
existing management mechanisms (e.g., WSDM) are sufficient? Is it
something that will fall out of the work described? Or is it out of
scope? Management of an in flight data movement by the interested parties
seems so essential to me that I am surprised by the silence in the
charter. At the least, I would like to see the charter state whether or
not management issues are in scope or out of scope. (I can not decide if
the "User Management" item in section 2 is about this issue.)
Allen
"William E. Allcock"
-----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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
[attachment "charter-v4.doc" deleted by Allen Luniewski/Almaden/IBM]
_____
From: Allen Luniewski [mailto:luniew@almaden.ibm.com]
Sent: Tuesday, March 14, 2006 3:39 PM
To: allcock@mcs.anl.gov
Cc: dmis-bof@ggf.org; 'Michel Drescher'; owner-dmis-bof@ggf.org; 'Robert B.
Wood'
Subject: RE: [dmis-bof] Updated Charter
I find the proposed charter fundamentally sound. I do have two small issues
to raise.
I am surprised that it does not address policy control of data movement.
The charter is mute on the subject of Policy so it does not seem to consider
that out of scope. Policy based data movement seems to be an essential
aspect of a data transport mechanism in the evolving grid space.
Ummm.... I certainly would not agree that anything not explicitly mentioned
is not considered out of scope. I personally hate the word policy because
every body means something different by it. Right now, my default answer
would be that we didn't explicitly specify it as in scope, so it is out of
scope. If you give me a better idea of what you had in mind, I can try and
comment further.
I expected (hoped?) to find words asserting that management of an
in-progress data transfer was in scope but did not. Is the belief that
existing management mechanisms (e.g., WSDM) are sufficient? Is it something
that will fall out of the work described? Or is it out of scope?
Management of an in flight data movement by the interested parties seems so
essential to me that I am surprised by the silence in the charter. At the
least, I would like to see the charter state whether or not management
issues are in scope or out of scope. (I can not decide if the "User
Management" item in section 2 is about this issue.)
Again, it depends on what exactly you mean by management, but if you mean
things like suspend, cancel, status, etc., I know that RFT has such
functionality, and I suspect the others do as well. I believe such
capabilities are required, as to whether we are WSDM compliant, I have no
idea.
Bill
Allen
"William E. Allcock"
-----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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
[attachment "charter-v4.doc" deleted by Allen Luniewski/Almaden/IBM]
Bill,
By policy I simply mean the ability to specify things such as:
1. When must the transfer complete by
2. How much network bandwidth is it allowed to consume
3. How much is it allowed to load the source (destination) points
4. If we were in a charge back environment, how much am I willing
to spend for the transfer
5. Constraints on routing the in-flight data
There are probably others, and not all of these might be appropriate for a
first transfer specification, but hopefully this gives you the idea of
what I thought needed to be covered.
As for management, yes, I was thinking of things such as cancel, suspect,
resume and status. If these kinds of functions are in-scope, that is what
I think is necessary. It then becomes an item of discussion within the WG
as to how to provide those functions.
Allen
"William E. Allcock"
-----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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
[attachment "charter-v4.doc" deleted by Allen Luniewski/Almaden/IBM]
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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
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@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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
<Charter for OGSA-WG.pdf>
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@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.
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@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,
http://www.ggf.org/Public_Comment_Docs/Documents/Oct-2005/draft-ggf- 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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@Sun.com
<Charter for OGSA-WG.pdf>
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"
-----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@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.
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@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,
http://www.ggf.org/Public_Comment_Docs/Documents/Oct-2005/draft-ggf- 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
-- Bob Wood Network Storage Architecture Office Sun Microsystems Inc.
303.395.3801 (x43011) Robert.B.Wood@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]
Can you use "for example" instead of "i.e." unless you want to tie up the
working group with the particular ones? In particular, these two places:
"Setting up a data movement includes the selection of a transport protocol,
i.e. GridFTP, and parameters for reliability, timing, scheduling, resource
usage, accounting, billing, etc. The Working Group will explore existing
mechanisms to reach such agreement, i.e. WS-Agreement [2] and use them where
appropriate. "
And this link in the charter
http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple is still
not reachable.
--Alex
| -----Original Message-----
| From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org]
| On Behalf Of William E. Allcock
| Sent: Wednesday, March 15, 2006 5:59 AM
| To: 'Michel Drescher'; 'Hiro Kishimoto'; 'Allen Luniewski'
| Cc: dmis-bof@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@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@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
| > >>>>>
| > >>>>>
Ah, you are right. E.g. is the actual Latin abbreviation we should have had there, not i.e., but if we are going to change it, I guess we can use English rather than Latin :-). Bill
-----Original Message----- From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org] On Behalf Of Alex Sim Sent: Wednesday, March 15, 2006 3:55 PM To: allcock@mcs.anl.gov; 'Michel Drescher'; 'Hiro Kishimoto'; 'Allen Luniewski' Cc: dmis-bof@ggf.org Subject: RE: [dmis-bof] Updated Charter
Can you use "for example" instead of "i.e." unless you want to tie up the working group with the particular ones? In particular, these two places: "Setting up a data movement includes the selection of a transport protocol, i.e. GridFTP, and parameters for reliability, timing, scheduling, resource usage, accounting, billing, etc. The Working Group will explore existing mechanisms to reach such agreement, i.e. WS-Agreement [2] and use them where appropriate. "
And this link in the charter http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simp le is still not reachable.
--Alex
| -----Original Message----- | From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org] | On Behalf Of William E. Allcock | Sent: Wednesday, March 15, 2006 5:59 AM | To: 'Michel Drescher'; 'Hiro Kishimoto'; 'Allen Luniewski' | Cc: dmis-bof@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@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@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 | > >>>>> | > >>>>>
| > >>>> | > >>>> | > >>> -- | > >>> Bob Wood | > >>> Network Storage Architecture Office Sun Microsystems Inc. | > >>> | > >>> 303.395.3801 (x43011) | > >>> Robert.B.Wood@Sun.com | > >>> | > >>> | > >>> <Charter for OGSA-WG.pdf> | > | > |
Hi all, sorry for the confusion - it is all my fault with the confusion of "i.e." and "for example". Can somebody explain to me the difference? Alan, the transfer mechanism "http://schemas.ggf.org/byteio/2005/10/ transfer-mechanisms/simple" is not a link - it is a name, constructed according to GFD.58, "Standardised Namespaces for XML infosets in GGF", http://www.ggf.org/documents/GFD.58.pdf (<--- this IS a link! ;-) Cheers, Michel On 15 Mar 2006, at 22:53, William E. Allcock wrote:
Ah, you are right. E.g. is the actual Latin abbreviation we should have had there, not i.e., but if we are going to change it, I guess we can use English rather than Latin :-).
Bill
-----Original Message----- From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org] On Behalf Of Alex Sim Sent: Wednesday, March 15, 2006 3:55 PM To: allcock@mcs.anl.gov; 'Michel Drescher'; 'Hiro Kishimoto'; 'Allen Luniewski' Cc: dmis-bof@ggf.org Subject: RE: [dmis-bof] Updated Charter
Can you use "for example" instead of "i.e." unless you want to tie up the working group with the particular ones? In particular, these two places: "Setting up a data movement includes the selection of a transport protocol, i.e. GridFTP, and parameters for reliability, timing, scheduling, resource usage, accounting, billing, etc. The Working Group will explore existing mechanisms to reach such agreement, i.e. WS-Agreement [2] and use them where appropriate. "
And this link in the charter http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simp le is still not reachable.
--Alex
| -----Original Message----- | From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org] | On Behalf Of William E. Allcock | Sent: Wednesday, March 15, 2006 5:59 AM | To: 'Michel Drescher'; 'Hiro Kishimoto'; 'Allen Luniewski' | Cc: dmis-bof@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@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@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 | > >>>>> | > >>>>>
| > >>>> | > >>>> | > >>> -- | > >>> Bob Wood | > >>> Network Storage Architecture Office Sun Microsystems Inc. | > >>> | > >>> 303.395.3801 (x43011) | > >>> Robert.B.Wood@Sun.com | > >>> | > >>> | > >>> <Charter for OGSA-WG.pdf> | > | > |
Hi again, thanks to Neil, I now seem to understand that difference. Hence a new iteration of the charter document. I attached both the charter and the seven questions even though only the charter has changed. Cheers, Michel On 16 Mar 2006, at 9:31, Michel Drescher wrote:
Hi all,
sorry for the confusion - it is all my fault with the confusion of "i.e." and "for example". Can somebody explain to me the difference?
Alan, the transfer mechanism "http://schemas.ggf.org/byteio/2005/10/ transfer-mechanisms/simple" is not a link - it is a name, constructed according to GFD.58, "Standardised Namespaces for XML infosets in GGF", http://www.ggf.org/documents/GFD.58.pdf (<--- this IS a link! ;-)
Cheers, Michel
On 15 Mar 2006, at 22:53, William E. Allcock wrote:
Ah, you are right. E.g. is the actual Latin abbreviation we should have had there, not i.e., but if we are going to change it, I guess we can use English rather than Latin :-).
Bill
-----Original Message----- From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org] On Behalf Of Alex Sim Sent: Wednesday, March 15, 2006 3:55 PM To: allcock@mcs.anl.gov; 'Michel Drescher'; 'Hiro Kishimoto'; 'Allen Luniewski' Cc: dmis-bof@ggf.org Subject: RE: [dmis-bof] Updated Charter
Can you use "for example" instead of "i.e." unless you want to tie up the working group with the particular ones? In particular, these two places: "Setting up a data movement includes the selection of a transport protocol, i.e. GridFTP, and parameters for reliability, timing, scheduling, resource usage, accounting, billing, etc. The Working Group will explore existing mechanisms to reach such agreement, i.e. WS-Agreement [2] and use them where appropriate. "
And this link in the charter http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simp le is still not reachable.
--Alex
| -----Original Message----- | From: owner-dmis-bof@ggf.org [mailto:owner-dmis-bof@ggf.org] | On Behalf Of William E. Allcock | Sent: Wednesday, March 15, 2006 5:59 AM | To: 'Michel Drescher'; 'Hiro Kishimoto'; 'Allen Luniewski' | Cc: dmis-bof@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@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@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 | > >>>>> | > >>>>>
| > >>>> | > >>>> | > >>> -- | > >>> Bob Wood | > >>> Network Storage Architecture Office Sun Microsystems Inc. | > >>> | > >>> 303.395.3801 (x43011) | > >>> Robert.B.Wood@Sun.com | > >>> | > >>> | > >>> <Charter for OGSA-WG.pdf> | > | > |
participants (7)
-
Alex Sim -
Allen Luniewski -
Arie Shoshani -
Hiro Kishimoto -
Michel Drescher -
Robert B. Wood -
William E. Allcock