Deliverable Review Form

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

General comments

22/05/12 Alex:

AMGA should be added to glossary

Some of the section headings are HUGE, sentences almost.

According to section 1.3, Chapter 2 concerns security plans, but it covers much more than this.

There are a couple of places where the reader is left hanging, expecting some sort of revised plan or action item, e.g. 2.4.2 and 2.5 ended in such a state.

I don't understand the relation between sections 2.7 and 2.8, they are both about the file:// access protocol.

Very short subsection headings like "Status of DPM" should IMO be expanded slightly to put them in context, e.g 2.7.1 could be something like "Status of file:// access protocol in DPM".

There's a sentence in 2.8.3 that says that kerberos support in DPM is already mentioned in the DPM section but I couldn't find that text.

There's the same paragraph in 2.9.2 and 2.9.3.

It seems the work mentioned in 2.9.2 is nearly completed, is it really wise to lose momentum and put it on hold? Or does being put on hold actually mean discontinued (the plan being to develop a different solution based on https/WebDAV)?

24/05/12 Alex:

o Maybe the nomenclature DNA1.3.2-X%, DNA-1.3.2.-D%, DRJA1.2.3-D%, DNA-1.2.3-X% could be explained somewhere?? I am sure they are references to items in various documents but the difference between D and X is not given and there are no references to these documents. In fact, I am confused by the fact that this document is DJRA-1.2.3.

o A general comment about the versions of various objects: The different EMI releases are called e.g. EMI2, EMI 2, EMI-2, I think there should be a uniform format. Ditto for packages: I noticed for example GFAL2, GFAL 2, GFAL-2. The versioning format doesn't have to be global as long as it is consistent for a given object (package, release, standard, etc).

o There isn't much info on the EMI web about what reviewers should look for but one requirement is the date of the document on the first page. It looks like the date is set manually (still 4/30/2012 for the latest draft), so we have to keep an eye on this for the final draft.

o In 2.10.1 there is an unclear sentence "GridHTTPs allows...support that protocols." What does "that protocols" refer to? This is a StoRM-specific paragraph. But is the idea that GridHttps can export to the grid any SE that can be viewed through the local filesystem? At the limit the local disk of a desktop?

o Figure 2.7 (dCache core modules) says that "As with NFSv4.1, WebDAV is sharing all dCache core components...". What does this mean? The same dCache core modules are used in both the NFSv4.1 and WebDAV implementations? This would be consistent with my interpretation of Figure 2-7 and 2-5.

o In 2.15 "Progress...highly divergeds [sic]" sounds very negative. What about something like "Progress on this objective among the storage elements varies strongly:"

o 2.16 The list of features (second list) looks more like a mixed list of demonstrations and transfer states (e.g. 3) rather than features. The first list looks for the most part like a list of features. Perhaps the second list should be a list of demonstrations, with an indication of which of the above features were validated. - No idea what the IE in "IE channel-less..." means.

o 2.17 A question mark in the reference DNA1.3.2-D?

o 2.17.1 "accounting PT" is the "accounting Product Team"?

o 2.20 I think the argument of the last 2 sentences would be improved with an "in the future": "...lifetime of EMI. In the future, however, customer...".

o 2.23 The section is a bit confusing. 2.23.1 is called "Common PT" which I assume means it applies to all the SEs, but only dCache is mentionned. Then dCache is mentioned again in 2.23.3. I understood that DPM provides specific probes while dCache and StoRM provide generic SRM probes which they consider sufficient.

o 3.1.1 I agree with the conclusion, but is there a document summarizing the differences which could be referred to?

o 3.1.2 Is "GSI" GSI (Darmstadt)?

o 4.3 Conclusion is a little unclear. The plan is to take no action?

o 4.4.2 1) Is a specific release targeted (EMI-3)? 2)Is the third paragraph (replica selection) specific to the Unicore data management?

o 4.8.3 Is the "short lived...URL" a feature unique to StoRM, or the other two have already implemented it? What is the motivation?

o 4.11.3 Is there an objective? For e.g. EMI-3?

o 4.29 Will such third-party ports to other platforms be supported by EMI? I.e. will they appear in EMI repositories?

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

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 - 04-May-2012