SA2 Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI Deliverable or milestone identifier: D5.2.2
Title: DJRA1.2.2 - Data Area Work Plan and Status Report Doc. identifier: EMI-DXXX-CDSREF-Title-vx.x
Author(s): P. Fuhrmann Due date: __

Identification of the reviewer
Name: Maria Alandes Pradillo Affiliation: CERN EMI Activity/External project or Institute: SA2

Review date mm/dd/yyyy
Author(s) revision date mm/dd/yyyy
Reviewer acceptance date mm/dd/yyyy

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

General comments

Specific to Chapter 3

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

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 Document is difficult to read: titles are too long! The word “workplan” is used and is redundant. A simpler and shorter title will help to identify the objective.

Page Section Observations and Replies Is Addressed?
1 General x.y Spelling and grammar check is needed Used consistent spelling of 'work plan'  
2 General x.y Font size is not coherent across sections and subsections. Subsections should be always smaller. This makes it difficult to read. Please, improve the layout in that respect. ignored  
3 General x.y Risk analysis needs more work in general. Almost no objectives have any associated risk, which I think itīs too optimistic. Reviewers opinion  
4 General x.y The subsection “Components” could use homogeneous criteria to list the affected components. In general thereīs some lack of homogeneity across section 4.    
5 General x.y Things described in section 3 could just be referenced to avoid duplicated information. Duplication improves understanding  
6 General x.y Document is difficult to read: titles are too long! Titles are given by PTB  
7 General x.y The word “workplan” is used and is redundant. It is part of the objective (can't change it here) and it is a particular subsection.  
8 General x.y A simpler and shorter title will help to identify the objective. Titles are given by PTB
9 General x.y The document lists achieved objective in section 4 For reference. Makes it easier to understand the context (similiar to (5)  
10 22 4.2.4 OK, so clients will be able to consume Glue 1.3 and Glue 2.0 at the same time in EMI-2, and only Glue 2.0 in EMI-3, is this correct? It’s not very clear. Phrased differently  
11 22 4.3 I don’t see the difference between this objective and the previous two. Objectives are defined by Technical Director and PTB  
12 23 4.4.3 So will both SAML and X509 be supported? Fixed
13 23 4.4.3 I find this paragraph dense and hard to understand. Itīs not clear to me what needs to be done exactly. Text says : "To logically complete the work of providing a Grid implementation of SMS, the SRM client still needs to be integrated, as described in 4.5 and Figure 3 3" This is exatly what has to be done. I added a reference to the picture in section 3. Fixed
14 23 4.5 I find it difficult to understand the relationship between this objective and the previous one. Is 4.5 something needed by 4.4? Itīs not clear to me looking at the timeline. I added a link to the picture in section 3 which really explains the relationship between UNICORE LFC and SRM
15 24 4.5.2 Why is it an interesting alternative to be taken into account? As with the LFC API, there are alternatives for the SRM client. It's my job to point to alternatives, but not to clasify them. This is done by the product team.
16 24 4.5.5 Which ones? (She means which prerequisites for the 4.5) Fixed
17 25 4.7 Again,. I donīt understand why this is included in the workplan if itīs finished. Itīs already part of section 3, right? Makes it easier to understand the context (similiar to (5)
18 28 4.8 This sentence sounds a bit strange to me. I think itīs not correct. Fixed
19 28 4.9 Isnīt it a bit the same described in section 3? Maybe you can create an appendix and avoid duplicating this twice. This one is more precise. e.g. there are two pictures instead of one
20 28 4.11 If 4.10 was finished, how is it possible that 4.11 is so difficult to achieve? What prototype was then implemented in 4.10 if the delegation issue is still under discussion? Described in the chapter 'delegation' later in the paragraph, plus link added to section 3
21 28 4.11 Reference? (to OGF 31) Added
22 31 And then, what happens in EMI? This is actually described in the sentence before. However I add what happens outside of EMI
23 29 4.12 This is contradictory. In the previous objective, which aims at using https for the SRM protocol, it seems none of the storage elements support it. Could this be better explained? Maybe I donīt have enough technical knowledge but I guess this should be easy to understand for everybody, right? Please read the technical background in section 3
24 30 4.13 I think this objective also contains duplicated information wrt section 3. It does
25 31 This is difficult to understand for a non technical person not knowing the meaning of SURL and TURL and why this is an issue. Is sufficiently decribed in exactly that section. This is not a text book. This is a technical deliverable
26 32 4.15.3 This type of information is included in section 3.8. Also the technical description is duplicated. Is it necessary? yes
27 32 If this was already started, I guess there are already some results, right? Shouldnīt the workplan define what to do starting from that fact and not as if everything is done from scratch? The paragraph before already contained references to the outcome of the f2f meeting. However, I added it here again
28 33 4.16 Why 4.15 and 4.16 are different objectives? In the end is all about the same, right? I donīt understand very well the rational to split objectives in this way. See DNA 1.3.2

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

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r4 - 2011-05-26 - PatrickFuhrmann
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright &Đ 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback