[dmis-bof] Comments on the charter?

[William E. Allcock]

> -----Original Message-----
> From: Michel Drescher [mailto:Michel.Drescher at uk.fujitsu.com] 
> Sent: Friday, December 16, 2005 4:32 AM
> To: allcock at mcs.anl.gov
> Cc: dmis-bof at ggf.org
> Subject: Re: [dmis-bof] Comments on the charter?
> 
> 
> Hi *,
> 
> On 12 Dec 2005, at 16:14, William E. Allcock wrote:
> 
> > FYI, I have requested a single 90 minute session for us.  The plan  
> > would be
> > to review and accept the charter, review some of the existing  
> > interfaces,
> > and begin a discussion of how they do or do not meet our charter /  
> > community
> > needs.
> 
> Good - let's hope we'll get a slot. If possible, can you try 
> to avoid  
> a clash with JSDL, ByteIO and NOMCOM?
> (And possibly a million of other sessions as well ;-) )

I asked that these constraints be added.

> 
> > [...]
> 
> > Comments on your slides.  The first two use cases are standard put  
> > and get.
> 
> Yes. I just wanted to use terms that are as neutral as possible.
> 
> > The third party transfer option is common, but raises some 
> issues.   
> > For
> > instance, your use cases imply some things:
> >
> >  - you can contact the source or the destination
> >  - you contact only one of them.
> 
> If I remember right, I gave examples for a source driven data  
> transfer (3rd party push/put), and a destination driven data 
> transfer  
> (3rd party pull/get). Both use cases must be supported, IMHO. So,  
> depending on the context (i.e. restrictions of a computing site), a  
> client MUST be able to initiate the data transfer from either the  
> source or destination side.

Ok.  I don't associate push/pull with who you are talking to.  I could talk
to the destination and tell him to either push or pull, which looks to be
the opposite to the source.  No problem, just a mis-communication :-).

> 
> I can even think of a scenario where *both* source and destination  
> must be contacted because the transfer request receiving party (in a  
> GET situation this is the source, in a put situation the 
> destination)  
> requires the client to vouch for the requested data transfer.

Right.  Good point, although it might not be the transfer service being
contacted.  For instance, in the Globus model, you would actually contact
the delegation service, delegate a credential (which becomes a resource,
since we use WSRF) and then get the EPR of that resource back, which you
could then pass to the other end of the transfer.

> 
> >
> > Are those requirements?  What if there is system that is always  
> > driven by
> > the source or the destination?  I.e., it specifies you must 
> contact  
> > one or
> > the other?  What if there is system that wants the client to do the
> > coordination and it contacts both ends (which is what standard FTP  
> > does) and
> > a broker trying to do some sort of co-scheduling might do?  
> What about
> > standard HTTP which does not support 3rd party transfers?
> >
> > I would also argue that your final use case is actual just a get  
> > followed by
> > a put.
> 
> Yes, this is one possible implementation - UNICORE will have to  
> provide a different implementation as the UNICORE Gateway is a  
> required intermediate. So it will indeed act as a gateway in the  
> literal sense. That is, it won't most likely stream the requests  
> instead of a staged approach.

Makes sense.  The condor folks have a somewhat similar scenario (what they
call Kangaroo), where it doesn't necessarily come through me, but it make
several "hops" on its way to the destination.

Bill
> 
> Cheers,
> Michel
> 
>