: 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)
: 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? Its not very clear. |
Phrased differently |
|
11 |
22 |
4.3 |
I dont 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 doesnt 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.