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@uk.fujitsu.com>
Michel Drescher <Michel.Drescher@uk.fujitsu.com> Sent by: ogsa-dmi-wg-bounces@ogf.org 11/05/2007 08:35 AM
<ecblank.gif>
To <ecblank.gif>
Mario Antonioletti <mario@epcc.ed.ac.uk> <ecblank.gif>
cc <ecblank.gif>
OGSA-DMI <ogsa-dmi-wg@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
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
DTF as the two are logically dissociated. Is there an expectation
supported the 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@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/ ~mario/ |
+---------------------------------------------------------------------
--+ -- ogsa-dmi-wg mailing list ogsa-dmi-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
(See attached file: PGP.sig)-- ogsa-dmi-wg mailing list ogsa-dmi-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg <graycol.gif> <pic23039.gif> <ecblank.gif> <PGP.sig>