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-DJRA1.2.2-CDSREF-DATA_AREA_WORK_PLAN_AND_STATUS_REPORT-v0.7
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 05/28/2011
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. Maybe
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 classify or select 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
29 33 4.1.4 In reality this objective is about testing. Is that a real technical objective? Testing is part of the implementation of any objective, right? The interoperability testing in EMI,right now, has much room for improvement. What we are currently doing in terms of interoperabilty testing is certainly not enough to make sure that a completely new library will be able to replace two established ones.
30 34 4.16.5 This objective is about testing, so I donīt see how testing reduces the number of components. The objective is not the testing. Testeing is the workplan to fullfil the objective. The objective is to complete the migration.As such it reduces the components.
31 34 4.16.5 Can you elaborate more on this? Rephrased
32 34 4.16.5 This is a continuation of section 3.5. I would not repeat the same information. Don't understand ?
33 34 What is this? (What is non-EMI group) Rephrased
34 34 What are the basics, the previous objectives? So now I have to repeat the previous objective. Fixed
35 35 4.17.4 Why is this important? (Importance of modernization) Rephrased
36 35 Which requirements? Rephrased
37 35 4.17.4 I donīt understand this paragraph at all. Rephrased
38 35 4.17.4 Why is there a high risk for this? Rephrased
39 37 4.18.5 So the risk is that the objective may not be finished in EMI? Anyway, in case the new FTS is implemented, What about the co-existence of the old FTS and the new FTS? How is the transition planned? Paragraph completely rephrased
40 37 4.18.5 What does this mean? Paragraph completely rephrased
41 37 4.18.5 I donīt see this consequence, could you please elaborate more? Paragraph completely rephrased
42 37 4.19 Same comments as other finished objectives. Same answer.
43 38 4.20.4 How will this be coordinated? Developers will get in touch with production sites volunteering for this testing exercise? This is up to the product team is might differ between the team.
44 38 4.20.4 Is this objective a requirement from the DCIs? If not, why is it implemented? Why DCIs wonīt use it then? Rephrased. Risk of deployment problem removed as not EMI's problem. Other risk added.
45 39 4.21.4 Why? Who cares ?
46 39 4.21.4 How is the transition from no ARGUS to ARGUS? Remark added.
47 39 4.22.2 So all EMI data components, right? No, AMGA is currently not considering Cloud
48 39 4.22.3 So is EMI data already involved or not? If not, what is EMI data waiting for to decide whether it will be involved? The EMI working group will decide the strategy for cloud in EMI ! So we wait for their results. As said in the next sentence "This objective is a placeholder for findings of the EMI Cloud Strategy Working Group."
49 40 4.23.4 Which one is the software part? What are the other parts of the objective and why EMI Data wonīt contribute on them? Is descibed in the sentence before "Consequently, this objective doesn’t only affect our EMI-Data software stack, it requires the availability of a long term preserved infrastructure.", EMI-data is not involved in infrastructures, so it can't contribute.
50 41 4.25.4 How do you know which probes are missing? Up to the product teams as described in the same sentence.
51 41 4.25.4 Among who? Fixed.
52 41 4.26.3 Where did you get this feedback? Reference needed. Referring to EGI.
53 42 So what is the solution? Fixed
54 42 4.26.5 I think there are risks attached to changing the command line options, as already mentioned above. Therefor we are not planing to change the names.
55 42 4.27.4 Which components? Fixed with reference of appendix 1 of DNA 1.3.2
56 42 4.27.5 I donīt understand this sentence. 4.27.5 and 4.26.5 were mixed up. Fixed.
57 43 4.28.5 Why 4.27.5 and 4.26.5 were mixed up. Fixed.
58 44 4.29.4 This seems to be too generic. How will you check that this objective is achieved? I don't know

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

This topic: EMI > WebHome > EmiDocuments > EmiDeliverables > DeliverableDJRA122 > DJRA122ReviewSA2DD
Topic revision: r6 - 2011-05-28 - PatrickFuhrmann
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