Subject: Re: Referee Reports on GCE Special Issue of CCPE: C553 From: Dietmar Erwin Date: Sun, 16 Dec 2001 21:50:09 +0100 To: gcf@indiana.edu X-UIDL: )!L"!ZAX"!&5[!!),9!! X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from grids.ucs.indiana.edu (localhost [127.0.0.1]) by grids.ucs.indiana.edu (8.10.2+Sun/8.10.2) with ESMTP id g011Bb618955 for ; Mon, 31 Dec 2001 20:11:37 -0500 (EST) Resent-Message-Id: <200201010111.g011Bb618955@grids.ucs.indiana.edu> Delivery-Date: Sun Dec 16 15:48:48 2001 Received: from mailer.csit.fsu.edu (mailer.csit.fsu.edu [144.174.128.142]) by grids.ucs.indiana.edu (8.10.2+Sun/8.10.2) with ESMTP id fBGKml615542 for ; Sun, 16 Dec 2001 15:48:47 -0500 (EST) Received: by mailer.csit.fsu.edu (Postfix) id AC8BA23A24; Sun, 16 Dec 2001 15:48:46 -0500 (EST) Delivered-To: fox@csit.fsu.edu Received: from snorkel.uits.indiana.edu (snorkel.uits.indiana.edu [129.79.6.186]) by mailer.csit.fsu.edu (Postfix) with ESMTP id BECCB23A1E for ; Sun, 16 Dec 2001 15:48:45 -0500 (EST) Received: from zam197.zam.kfa-juelich.de (zam197.zam.kfa-juelich.de [134.94.172.215]) by snorkel.uits.indiana.edu (8.10.1/8.10.1/IUPO) with ESMTP id fBGKmhM25731 for ; Sun, 16 Dec 2001 15:48:44 -0500 (EST) Received: from zam197.zam.kfa-juelich.de (localhost [127.0.0.1]) by zam197.zam.kfa-juelich.de (8.9.3+Sun/8.9.3) with ESMTP id VAA22329 for ; Sun, 16 Dec 2001 21:48:42 +0100 (MET) Received: from fz-juelich.de (ras114156.zam.kfa-juelich.de [134.94.114.156]) by zam197.zam.kfa-juelich.de (8.9.3+Sun/8.9.3) with ESMTP id VAA22294 for ; Sun, 16 Dec 2001 21:48:21 +0100 (MET) Message-ID: <3C1D0901.9CE4565D@fz-juelich.de> Organization: Forschungszentrum Jülich X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3BD1EBB6.6080003@indiana.edu> Content-Type: multipart/mixed; boundary="------------3139661EA7FAA52C36371731" Resent-To: ccpe Resent-Date: Mon, 31 Dec 2001 20:11:37 -0500 Resent-From: Geoffrey Charles Fox X-UIDL: )!L"!ZAX"!&5[!!),9!! Dear Geoffrey, attached is a pdf version of the revised CCPE paper on UNICORE. I considered the comments of the reviewers and remark on them below on the quote. I am sending a Word version by separate mail (I am sending from home and the ISDN link has problems with big attachments. -- Mit freundlichen Gruessen With best regards Dietmar Erwin Forschungszentrum Juelich Tel: +49-2461-61-6412 ZAM Fax: +49-2461-61-6656 D-52425 Juelich E-mail: D.Erwin@fz-juelich.de Geoffrey Fox wrote: > > I enclose 3 referee reports. I think you can address these straightforwardly > I hope that you will submit a revised version. > > I would like to receive your revised paper by the end > of November. Please return to me by EMAIL > a) PDF version of revised paper > b) Text Word or PDF comment on how referees' comments addressed > c) In spite of what journal says, I do not need at this stage > copyright release. You will send this directly to Wiley in > England after they contact you. > > Please put in subject of EMAIL > CCPE Portal Cabc > where Cabc number of your paper > Thank you for your contribution to this excellent special issue > > Referee 1 ******************************************* > > E: Referee Comments (For Author and Editor) > ------------------------------ > > Good overall description of the Unicore framework. It might be helpful > to provide an example case study of how an application scientist uses > the various Unicore services either as initial motivation or to tie > together the practical benefits of Unicore services at the end of the > overview. > Good explanation of difficulties in using applets in the implementation > section. Also, I'm still shaky on security in Unicore. If it doesn't > implement GSI, how can a process act on behalf of a user? In Globus, > this is done via a proxy which contains a short-lived private key-- I > see from the UUDB description you have a mapping between certs and user > names, so is the UUDB and the NJS and TSI considered "trusted" software > much like the Globus gatekeeper? And are all the connections between > these components secure? You might want to say something more about the > trust model that Unicore follows. I explained the security in more detail - it is indeed different from Globus and does not rely on shortlived certificates but on public keys which have to be known at all UNICORE sites. > In Future plans, do you see web services palying any role in the future > of Unicore? I would be interested to know more about GRIP as well. I added information on GRIP towards the end, although this projet will start on January 1, 2002. > > Referee 2 ******************************************* > > E: Referee Comments (For Author and Editor) ------------------------------ > > This overview paper summarizes nicely some of the development and features of the > UNICORE environment. This paper is very appropriate for the issue and the > paper does only need a couple of minor presentation changes in the reference section. > I very much appreciated the results explained in the implementation Section about Java. > > F: Presentation Changes > > Reference 5, include contact address for order possibilities add (in German) > Done (5 may be obtained in paper only. I added also a reference to a newer Wissenschaftsrat recommendation [6] which is availabel in on the web) > Reference 6, include institution, address and type of presentation. > Avoid the use of et.al. and use full list of authors. > Add (in German) Done > > If possible provide http link to reference 5 and 6 Done > > Use . At end of references. > > Referee 3 ******************************************* > > E: Referee Comments (For Author and Editor) ------------------------------ > > The paper presents high level overview of Unicore system. The project seem to be addressing > all aspects of Grid computing -- from middleware and software tools/user interface. The paper > can be valuable if it can show some Experimental Results or a Application > Case Study that is using Unicode in solving a real world problem. Many places > project refer to future work. I believe it is important to acknowledge current > state of the art in each of the area. For example, you mentioned about > resource broker, it might be worth citing papers such as: > Nimrod-G: http://www.csse.monash.edu.au/~davida/papers/hpcasia.ps.Z > http://www.csse.monash.edu.au/~davida/papers/ecogrid.pdf > that already solve many resource brokering issues. The paper also mentions about > executing repetitive tasks, but it does not say how they are created. Projects > like Nimrod-G already provide a simple scripting language for developing > coarse grained task-farming or data parallel apps. A great way to support > legacy applications. I think UNICORE can consider similar ideas. > I included the reference to the work as it related to the broker work done in context of project EUROGRID by partner University of Manchester. > There is no indication how inter operability between various components will > be achieved. > > F: Presentation Changes > > One page 5/14: In "Support for legacy jobs" section, CHANGE "if existing > techniques work" --> "if existing techniques DO NOT work" I really mean 'if existing techniques work ' > > The paper is good, but looks like all discussion is in Future tense. We > will do this, we will do that etc. But in one place paper says that latest > prototype is released on July 2001. It is important that you > update the paper fully to reflect current implementation. The latest developments up to and including the software releases with were demonststrated in thr November 30 review are included. Developments scheduled for the rest of the project duration need to remain in the future tense. > > Other comments please see section E for review report. I think it will good > change "Current and Future Work etc." section to Focus more on technical derails.