EMI Web>EmiDocuments>EmiDeliverables>DeliverableDJRA122>DJRA122ReviewSA2DD (2011-05-28, PatrickFuhrmann)

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.

N°	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	4.11.3.1	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	4.14.3.2	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	4.15.4.1	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	4.17.3.2	What is this? (What is non-EMI group)	Rephrased
34	34	4.17.3.4	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	4.1.7.4	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	4.26.4.2	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

Topic revision: r6 - 2011-05-28 - PatrickFuhrmann

Public webs

- Cern Search
- TWiki Search
- Google Search
EMI All webs