JRA1/SA1 Deliverable Review Form

Attach the reviewed document to the deliverable page, put here a link

General comments/remarks:

We already have a "deeper" internal JRA1 review where Laurence addressed most of my comments.

Section 3.2 A short motivation for the adoption should be provided. It is a general remark: the technical description of the objectives should include at least one motivation sentence and expected outcome (optimally from user perspective).

LF: Added a motivation sentence, Grid interoperability.

3.5.1 "over the WAN was not robust and would fail after a period of time", why is that so?

LF: Added a sentence to say that we need to investigate the reason for this failure.

3.7 "Through this research, the task force chose the existing capabilities of Infrastructure as a Service (IaaS) Cloud model as a reference architecture.", why? It is a general remark: I would expect that the document is either self-contained and complete by either answering such questions or by providing references to documents where the information can be found.

LF: The document is referenced in a previous sentence. I have changed the sentence to explain that a reference archiecture is described in the document.

4.2.2 vs 4.3.2 both tasks are investigations and for one the affected components are listed for the other no. General remark: I don't buy this excuse of not listening components for investigative tasks.

LF: For some objectives which require us to invesitagate which components requrie changing, we can't identify accuratly before we have done the investiagation. In which case what is written is honest and accurate.

Sure we should agree on what "affected/involved" means, but as soon as a component undergoes some examination it is involved IMHO. My general impression is that the lists of affected components are not prepared with the due precision and care. Some examples follow, I would suggest that the whole report should be revised in this regard.

LF: These lists were carfully prepared and aggree with the component list in DNA1.3.2.

4.11 It seams to be one of the most important goals in Infrastructure Area (from EMI perspective). I would expect a more exact description of what is expect to be achieved there.

LF: I agree that it is an important objective. However, the most important aspect is the plan, not the implementation of that plan (4.9).

I cannot find a place where the following technical objective (DJRA1.3.2) is addressed: I11 "Devise a plan for substantial simplification and reduction in the number of infrastructure area CLIs, libraries, internal components and services."

LF: This is addressed by objective 4.9.

Additional recommendations (not affecting the document content, e.g. recommendation for future work)

The technical objective: X17 "Introduce minimal DOS protection for EMI services via configurable resource limits." seems to affect the infrastructure area. It is not included in the workplan.

LF: I did not include it as I disagree with such general objectives, like the software must be secure. These are properties not objectives! How do you know that you have achived your objective?

4.15.4 I wonder why SA/JRA1.7.2 teams are not involved here? Is there a cooperation envisioned?

LF: Are are are not? Area leaders define the objectives but JRA1 is responsible for overseeing the implementation of these workplans.

4.2.3 it is a very tight schedule in my opinion.

LF: I agree but that is the deadline in DNA1.3.2. I think that most of the acctual work has been done, including implementation, so only a report is required.

4.8, 4.9 "this technical objectives is to provide"? not sure myself.

LF: Double-checked with an English expert and this is fine.

Detailed comments on the content

Note 1: The reviewers must list here any observation they want to track explicitly and that require interaction with the authors
Alternatively all changes must be listed in the document itself using Word change tracking features (if you use Word)
Note 2: These comments have to be explicitly addressed by the authors and the action taken must be clearly described

Presentation:

Use official EMI layout (with EMI logo, header, page numbers etc), how could I miss in JRA1 internal... my bad!

N°	Page/Section	Observations and Replies	Is Addressed?
1	ToC	consistent usage of capital letters in ToC e.g *r*eferences, Information *s*ystem ..., GANTT *c*hart, etc. All sections of the same level should follow the same writing convention	yes
2	ToC	sometimes a "-" is put before "Definition of subtask" sometimes not, e.g 4.16.4 vs 4.10.3	yes
3	ToC	sometimes the section "extended technical description of the objective" is omitted and the description (usually not very "extended") follows the section title. I might be a good idea to follow this principle (or the other one) consequently through the report.	yes
4	References	consistent usage of protocol in address, is: "R5 http://cdsweb.cern.ch/record/1277582 R6 www.ogf.org/documents/GFD.147.pdf" should be: "R5 http://cdsweb.cern.ch/record/1277582 R6 http://www.ogf.org/documents/GFD.147.pdf"	yes
5		Tables 1.5 and 1.6 are not "closed" on the left hand side.	yes
6		Text formatting in 3.4 (is left), 3.7 (funny spaces at the end of lines and sentence broken in the middle), some tables have text floating left (e.g. 4.3.3) some have justified (e.g. 4.2.3),	yes

Any other modification, spelling or grammatical corrections, etc must be done directly in the document using tracked changes or similar mechanisms that allows the authors to identify which correction is suggested.

-- FloridaEstrella - 06-May-2011

-- JedrzejRybicki - 19-May-2011