[ogsa-dmi-wg] Potential problem
Michel Drescher
Michel.Drescher at uk.fujitsu.com
Mon Nov 5 11:50:08 CST 2007
Good explanation, thanks.
I was probably too imprecise by simply declaring it as an
implementation detail. In fact, in hindsight I realise that I came to
the conclusion that, after thinking along the lines Allen laid out as
option 2, the only solution in the current situation is to make it an
implementation (issue | detail).
But Allen's definitely right in that we should describe this in a non-
normative section somewhere.
And I agree that a dynamic negotiation would have elegantly solved
this solution. But we should stick now with with what e agreed on,
and move on.
Cheers,
Michel
On 5 Nov 2007, at 17:17, Allen Luniewski wrote:
> I think that there is a problem here and it is not an
> implementation one.
>
> In Mario's example, the sink might very well support ftp within the
> firewall. But for security reasons it is not allowed to cross the
> firewall. At the same time one might conjecture that some other
> protocol was valid across the firewall. Since the DTI is created to
> execute a particular protocol, all it can do in this case is report
> failure when the FTP fails. The DTI has no means to negotiate
> another protocol that might work - that is the job of the DTF. So
> reporting failure is all that it can do.
>
> At this point the client is in a difficult position. If it just
> reinvokes the DTF, we will just go around this loop again since
> nothing has changed. If the error reported by the DTF has enough
> information, the client could edit the DEPRs to remove the protocol
> that does not work. This will eventually lead to a successful
> transfer (assuming that the transfer is possible) but seems to
> obviate one of the key reasons that DMI exists - ease of use/
> simplicity for the client. So, I regard this as an unacceptable
> solution.
>
> So what might work and retain the desirable properties of DMI?
>
> 1. The DTF could test the protocol to see if it works. I am nervous
> about this as it raises questions about what data is transferred,
> where is it stored, how is the test undone, are there security
> issues, etc.
>
> 2. One could take a tact that says that when the DTF does protocol
> negotiation, it informs the source (sink) as to the identity of the
> other party involved in the transfer. This then puts the onus on
> the source (sink) to declare a protocol as unworkable.
> Unfortunately, this reintroduces protocol negation into DMI which
> is something that we have gotten away from (as I understand things,
> right now we basically assume that the DTF just does matches based
> upon what it finds in the DEPRs). This becomes, I think, just an
> implementation issue (assuming that we were to choose to not
> architect the negotiation process) but one that we would need to
> comment on in the document.
>
> 3. We could have the DTI go back to the DTF to choose a different
> protocol. The problem with this is that this will result in a new
> DTI (since DTIs are protocol specific) and there is no way to
> communicate this new DTI back to the client who requested the
> transfer.
>
> I lean towards option #2. It addresses the problem at DTF time
> which is when it seems most appropriate to address. It is a natural
> part of protocol negotiation (which I have always felt was the
> proper way to architect this and not via the current DEPR based
> approach). It is also something that is easy to explain to DMI
> clients.
>
> Allen Luniewski
> IBM Cross Brand Services
> IBM Silicon Valley Laboratory
> 555 Bailey Ave.
> San Jose, CA 95141
>
> 408-463-2255
> 408-930-1844 (mobile)
>
> <graycol.gif>
> Michel Drescher <Michel.Drescher at uk.fujitsu.com>
>
>
> Michel Drescher <Michel.Drescher at uk.fujitsu.com>
> Sent by: ogsa-dmi-wg-bounces at ogf.org
> 11/05/2007 08:35 AM
>
> <ecblank.gif>
>
> To
> <ecblank.gif>
>
> Mario Antonioletti <mario at epcc.ed.ac.uk>
> <ecblank.gif>
>
> cc
> <ecblank.gif>
>
> OGSA-DMI <ogsa-dmi-wg at ogf.org>
> <ecblank.gif>
>
> Subject
> <ecblank.gif>
>
> Re: [ogsa-dmi-wg] Potential problem
> <ecblank.gif>
> <ecblank.gif>
>
> Hi all,
>
> quick shot at face value:
>
> I don't see a problem - I see this as an implementation detail.
>
> Primarily, I see this problem as a fault of the sink not DMI, as the
> sink returns an available protocol that effectively is impossible to
> use (setting temporal skews aside).
>
> Naïve DMI implementations may simply go forward and trust the
> information supplied by source and sink, while more advanced
> implementation may be able to solicit that information with
> heuristics, statistical/historical information and active probing as
> you described.
>
> Cheers,
> Michel
>
>
> On 5 Nov 2007, at 16:04, Mario Antonioletti wrote:
>
> >
> > Hi,
> > Last week we were discussing comments to the OGSA Data document
> > and
> > something came up that is pertinent to DMI (Alle pitch in).
> >
> > Basically, suppose that the source and sink publish a set of
> supported
> > transport protocols. Then, if client wants to effect a transfer
> > between the source and sink, they would talk to a DTF. The DTF would
> > negotiate a protocol supported at both ends and create a DTI to
> manage
> > the transfer for the user. The issue is that there may be other
> > factors that preclude that transfer from taking place - for instance
> > as a simple example, if active ftp was chosen as the protocol of
> > choice a firewall could stop this transfer from successfully
> > completing. The DTI would not be able to communicate this back to
> the
> > DTF as the two are logically dissociated. Is there an expectation
> that
> > the DTF, would not only protocol match but also test out that the
> > transfer protocol actually works between source and sink before
> > creating the DTI? I'm not sure if this is an implementation thing or
> > whether there is a deeper potential problem here - thoughts?
> >
> > Mario
> >
> >
> +---------------------------------------------------------------------
> > --+
> > |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9
> > 3JZ. |
> > |Tel:0131 650 5141|mario at epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/
> > ~mario/ |
> >
> +---------------------------------------------------------------------
> > --+
> > --
> > ogsa-dmi-wg mailing list
> > ogsa-dmi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
>
> (See attached file: PGP.sig)--
> ogsa-dmi-wg mailing list
> ogsa-dmi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
> <graycol.gif>
> <pic23039.gif>
> <ecblank.gif>
> <PGP.sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/863d7660/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071105/863d7660/attachment-0001.bin
More information about the ogsa-dmi-wg
mailing list