Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI Deliverable or milestone identifier: DJRA1.5.1
Title: DJRA1.1.1 – Standarisation Area Work Plan and Status Report Doc. identifier: 2010-10-09_EMI_DJRA1.5.1_v4.doc
Author(s): Aleksandr Konstantinov Due date: __

Identification of the reviewer
Name: Alberto Di Meglio Affiliation: CERN EMI Activity/External project or Institute: NA1

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

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

General comments

The document contains a comprehensive description of the standard relevant to EMI and clear lists of which products are affected by each standard. This is good point.

However, the document doesn't read like a plan, more like a generic assessment. The description of the deliverable in the DoW states that "This deliverable contains the detailed work plan of the standardization activities and objectives compliant with the overall EMI Technical Development Plan" and "The status report at M03 will cover the state-of-the art". The second part is well covered, but the first part is substantially missing. I would add a section where timelines, milestones, checkpoints, etc of implementation of each relevant standard are described. It could be strauctured following the same order as the state of the art section with a summary timeline in form of graph or gantt chart. For example: VOMS has full SAML compliance by? StoRM will support HTTP for data transfer by? The first complete Compute Interface specification from the EMI ES working group will be available for public discussion within PGI by? Etc, etc. There should be links with the EMI release schedule and you should give an idea of what is planned to be included in each release as far as reasonably possible.

The document has a number of deviations from the standard template in terms of structure, paragraph and headings styles.

The document require a revision according to the recommendations above before it can be released.

-- AlbertoDiMeglio - 08-Nov-2010

Regarding plan see below in comment 18.

Regarding deviation from template see below in comment 20.

-- AleksandrKonstantinov - 19-Nov-2010

This version of the deliverable is in my opinion more realistic than the previous version, although it is much shorter. Or probably it is more realistic because it is shorter and to the point. I like the general description of the strategy and the focus on a limited but very relevant number of standards.

I'd like to see the Exec Summary and Conclusion sections, but I think this can eventually be submitted without further modifications. I will update my review page in twiki asap. Please let me know when you have a complete version with exec summary and conclusion.

-- AlbertoDiMeglio - 19-Apr-2011

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

None at this point, first the above recommendations have to be addressed

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

Page Section Observations and Replies. Is Addressed?
1 xx x.y There are no page numbers and no standard header/footer section in this document. Please refer the templates at https://twiki.cern.ch/twiki/pub/EMI/EmiTemplates/EMI-DXXX-CDSREF-TITLE-vX_Y_template_v1.3.doc or https://twiki.cern.ch/twiki/pub/EMI/EmiTemplates/EMI-DXXX-CDSREF-TITLE-vX_Y_template_v1.3.odt
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 20.
-- AleksandrKonstantinov - 19-Nov-2010
 
2   1.1 "The purpose of this plan is to identify common open standards". There are two issues with this statement. The purpose of the plan cannot just be to identify the standards, but also to describe how we plan to implment them. In addition, the reference to "common open" standards is a bit too strong. What is a common open standard? We stive to adopt existing working standards, improve draft standards so they can become workable and at least make sure that within EMI we have common agreement in case no other solution is possible
-- AlbertoDiMeglio - 08-Nov-2010
Regarding description of how standards are going to be implemented I see it as technical details which belond to corresponding deliverables and plans of corresponding PTs and JRA1.xs. Regarding definition of "common open standards" I agree that term is not self-explanatory. I'll try to come with better wording. Do You have any suggestion?
-- AleksandrKonstantinov - 19-Nov-2010
 
3   1.1 "This plan does not aim at defining detailed actions for adopting standards by every involved component. That is a task for the detailed development plan of every component and this report provide guidelines which standards are significant for those". Refer to the general comments section above. This document mist contain some level of planning. No detailed actions, but at least a high-level plan in the form of a plan
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 18.
-- AleksandrKonstantinov - 19-Nov-2010
 
4   1.5 Use standard document amendement statement from template
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 20.
-- AleksandrKonstantinov - 19-Nov-2010
 
5   table 3 and various sections OGSA-BES is correctly mentioned in this document, but I'm not sure there is an agreement within EMI about it. We should make sure that we don't claim or give the impression of claiming something that will not happen. As far as i know, UNICORE has OGSA-BES in production, but ARC and gLite have experimental implmentation which are not used, not maintained and will very likely be dropped as soon as somethinf from EMI itself or PGI is available. The same applies to JSDL, probably to a minor extent
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 22.
-- AleksandrKonstantinov - 19-Nov-2010
 
6   2 "Also the project is involved in activities that might lead to new emerging standards ". Can you provide some example?
-- AlbertoDiMeglio - 08-Nov-2010
Example is provided. It is PGI.
-- AleksandrKonstantinov - 19-Nov-2010
 
7   2.1 (but numbering is wrong, it should be 3.1) "As VOMS does not use the problematic delegation functionality this action is planned for the near future " Try to avoid statements like "is planned for the near future". Either is planned and you can give an estimate or it's not planned and you cannot say that it is planned. By when VOMS will drop GSI. BTW, I thought it was already done
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 26.
-- AleksandrKonstantinov - 19-Nov-2010
 
8   2.2 HTTP for data transfer is only StoRM? In my opinion we can talk about EMI standardization activities if ALL affected products are implementing a standard. If a single product is using a standard, then it's good for them, but it's not an EMI standardization activity
-- AlbertoDiMeglio - 08-Nov-2010
I disagree. As long as any product uses some standard it IMHO belongs to PGI. Otherwise there would be no single standard mentioned in this document except maybe IP.
-- AleksandrKonstantinov - 19-Nov-2010
 
9   2.5 Same as before for VOMS and REST. If every WS uses SOAP and only VOMS uses REST is not really an EMI standardization achievement, although REST in itself is a standard
-- AlbertoDiMeglio - 08-Nov-2010
See above in comment 8.
-- AleksandrKonstantinov - 19-Nov-2010
 
10   2.8 The document doesn’t talk anywhere about the plans to have a simplified version of SRM in production and common to all DM services. I thought this was one of the objectives of the DM area plan
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 32.
-- AleksandrKonstantinov - 19-Nov-2010
 
11   2.11 LDAP is only relevant to ARC? All BDII components in gLite are LDAP-based or I do not understand how it works?
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 34.
-- AleksandrKonstantinov - 19-Nov-2010
 
12   2.17 I know this is know highly controversial, but is it correct to state that all Compute Element services will adopt PGI? I hope it happens, but from a planning point of view it is more likely that the EMI ES will be implemented first and then a migration to PGI is made once the specs are available, but I'd like to hear this clearly spelled out by all Compute PTs before we write it on this plan
-- AlbertoDiMeglio - 08-Nov-2010
Document does not state that all computing services will adopt PGI. Only that PGI activity is relevant. At least this is what I meant.
-- AleksandrKonstantinov - 19-Nov-2010
 
13   3 Is it worth mentioning the work done in the new MSWG managed by the Security Area leader?
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 36.
-- AleksandrKonstantinov - 19-Nov-2010
 
14   5 In my opinion section 5 - Risks is a bit biased. There is only one risk mentioned and it is something that not everybody in the project still agrees with. Someone else may say that the risk is that we do not have any working spec in time for EMi to implement. This is as extreme as thnking that we may have to maintain 4 interfaces. Both are risks and we need to manage the situation. It is not avoidable to have the legacy interfaces and at least one common interface. Achieving this during the project lifetime would already be a success. The rest is all about correct planning and migration strategies (check the additional comments in the document)
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 37. Concerning agreement in a project that kind of information is not propagated to me. At least not through official channels like mailing lists. Also as JRA1.6.1 leader I feel myself as eligible to make some decisions as long as it is not objected by corresponding JRA1.x and PT people. Concerning risk related with PGI and EMI ES activities as participant of both I feel myself capable of evaluating them at least roughly.
-- AleksandrKonstantinov - 19-Nov-2010
 
15   6 there is no real report of the progress of the SIENA project. It may be because there is nothing to report, but in the exec summary it is stated that a report is provided in this document
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 40. Morris can provide more information.
-- AleksandrKonstantinov - 19-Nov-2010
 
16   7 section 7 has more the look and feel of the Conclusions section of the deliverable template and as stated in the general comments section, at this point of the document I miss the actual plan for the first 12 months of the project
-- AlbertoDiMeglio - 08-Nov-2010
See below in comment 41.
-- AleksandrKonstantinov - 19-Nov-2010
 
17 5 1.1 I would remove the word ‘open’. Let’s talk about standards. If a standard is a standard, it is by definition open.
-- AlbertoDiMeglio - 08-Nov-2010
"open standard" is buzword and as such I find it good for this kind of document. If insisted I can removed "open" from "open standard" through whole document. But from my point of view most important attributes of "open standard" are:
1. It is developed in community which is open for proposals from outside as opposed to commercial organizations developing standards for limited set of predefined players.
2. produced result is freely available to unrestricted community.
In my career as professional software developer I had to deal with standards which were not satisfying at least of those criteria. So for me not every standard is open standard.
-- AleksandrKonstantinov - 19-Nov-2010
 
18 5 1.1 I’m not sure I agree with this. The description of the deliverable in the DoW states “This deliverable contains the detailed work plan of the standardization activities”. Note the word DETAILED. This document should indeed describe which standards are relevant and how and when they will be adopted. The development plans of the individual components should then match the agreements set forward in this document and use it as a reference. Of course, if by detailed you mean actual implementation details, then you are right, they shouldn’t be here. But timelines should be.
-- AlbertoDiMeglio - 08-Nov-2010
By detailed I exactly mean detailed description who what and when. At the time of writing of that document according to performed survey that kind of information was not available. Taking into account that actual standardization work is being done by PT I think it is much better not to impose any timing on developers and let them produce realistic timeline. This probably conflicts with your view as I can deduce from "The development plans of the individual components should then match the agreements set forward in this document and use it as a reference". So as soon as such information becomes available and JRA1.6 staff have time to process it it will be propagated to next deliverable. Anyway timing which I was given for this document was not adequate even to coordinate its content with JRA1.x, not speaking about PTs.
-- AleksandrKonstantinov - 19-Nov-2010
 
19 5 1.2 The “plan” part is missing. I’d like to see a description of what actions are going to be taken in the first 12 months of the project, so that the next version of the deliverable can report on the status of that plan. Providing a “glimpse” is not sufficient.
-- AlbertoDiMeglio - 08-Nov-2010
See above.
-- AleksandrKonstantinov - 19-Nov-2010
 
20 8 1.5 Please use the standard description of the Document amendment procedure as found in https://twiki.cern.ch/twiki/pub/EMI/EmiTemplates/EMI-DXXX-CDSREF-TITLE-vX_Y_template_v1.3.doc. The general format of the document also doesn’t seem to follow the template (spacing, alignments, headers, fonts, etc)
-- AlbertoDiMeglio - 08-Nov-2010
It looks like template has changed during processing (different amendment, no table example, etc.). The diverse of tools used for processing of this document also added to formating artefacts. I have completely rewritten document using latest Open Office template and used almost no manual formating. Hopefully formatting is more acceptable now. There are still problems with that document. Template seems to contain pictures which my installation of OO can't recognize. Also I could not find CDSREF for this document which is needed for file naming. And length of file name is definitely too long to fit into header. From here I skip all formating comments.
-- AleksandrKonstantinov - 19-Nov-2010
 
21 9 2 "This document identifies related standards " . Why” related”? This sentence sounds like “standards related to each other”
-- AlbertoDiMeglio - 08-Nov-2010
The word "related" is confusing in that sentence indeed as it can be applied to different parts. I'm removing it.
-- AleksandrKonstantinov - 19-Nov-2010
 
22 9 Table 3 Row 6 OGSA-BES / Compute. This is part of the ongoing long discussion on EMI and PGI, but before this is stated as explicitly as this, I’d like to understand whether there is really commitment to implement OGSA-BES in all relevant production EMI components.
-- AlbertoDiMeglio - 08-Nov-2010
This document does not state that BES is going to be implemented by any component because it is already implemented by CREAM, UNICORE and A-REX. All those services use incompatible extensions to BES and that is the reason for EMI ES specification effort which is planned to be fed back to BES through PGI. This activity is also descriibed in document.
-- AleksandrKonstantinov - 19-Nov-2010
 
23 9 2 “Also the project is involved in activities that might lead to new emerging standards . Quote examples
-- AlbertoDiMeglio - 08-Nov-2010
Those are all in section "EMI driven initiatives for standardization opportunities". I'm adding reference.
-- AleksandrKonstantinov - 19-Nov-2010
 
24 10 1 Numbering error
-- AlbertoDiMeglio - 08-Nov-2010
See above.
-- AleksandrKonstantinov - 19-Nov-2010
 
25 10 2.1 2nd paragraph. A bit unclear to refer to “deliverables of the security areas”. I would either quote a specific deliverable or just write explicitly the most important reasons in the text
-- AlbertoDiMeglio - 08-Nov-2010
I have added a reference to DJRA1.3.1. Text also already contains description of reason - "but the major reason is the incompatibility with open standards like SSL/TLS."
-- AleksandrKonstantinov - 19-Nov-2010
 
26 10 2.1 3rd paragraph Whever possible we should avoid expression like “planned in the near future”. By when it is planned? This year, next year? In EMI 1?
-- AlbertoDiMeglio - 08-Nov-2010
Not know by time of writing of this document. I'll try to find out and if not successful will remove that sentence.
-- AleksandrKonstantinov - 19-Nov-2010
 
27 10 2.2 Only StoRM is planning this? I thought that HTTP base data transfer solutions were foreseen also in other implementation (dCache?)
-- AlbertoDiMeglio - 08-Nov-2010
Information is according to conducted survey. dCache is definitely going to use HTTPS for SRM channel. But I'm not sure if they planning to do that for data channel. I'll try to find out and will add information if suceed before release of document.
-- AleksandrKonstantinov - 19-Nov-2010
 
28 11 2.4 “all WS-based services” The components above are not WS-based? It is not clear why the list contains specific product names and the a generic category for all WS-based services
-- AlbertoDiMeglio - 08-Nov-2010
That was done to explicitely list those components for which information was available. But becuase definitely there are more WS components which did not reply to survey those we put as "all WS-based services". Maybe change to "other WS-based services"?
-- AleksandrKonstantinov - 19-Nov-2010
 
29 11 2.5 This may be interesting, but for me it doesn’t fit in the EMI Standardization plan. Either all relevant components adopt a standard or it remains an isolated decision of a single product team. I would not mention this.
-- AlbertoDiMeglio - 08-Nov-2010
See above.
-- AleksandrKonstantinov - 19-Nov-2010
 
30 11 2.6 See also comment in the Exec Summary. Are we sure that OGSA-BES is indeed being implemented by all CEs in EMI and in the same way? If not, it’s a risk to mention it so explicitly. Make sure this is not interpreted as “we will implement it”.
-- AlbertoDiMeglio - 08-Nov-2010
Yes it is imeplemted by CEs. No, it is not implemented in same way in a sense that extra functionality is through extra extensions. But alter all those services participated in interoperability demos. So not mentioning BES here would be violation of fact.
-- AleksandrKonstantinov - 19-Nov-2010
 
31 12 2.7 Same as OGSA-BES?
-- AlbertoDiMeglio - 08-Nov-2010
Yes, as far as I know.
-- AleksandrKonstantinov - 19-Nov-2010
 
32 12 2.8 The document doesn’t talk anywhere about the plans to have a simplified version of SRM in production and common to all DM services. I thought this was one of the objectives of the DM area plan
-- AlbertoDiMeglio - 08-Nov-2010
I did not get that kind of information from SRM-related PTs. Also simplified SRM would be violation of SRM standard as far as I understand.
-- AleksandrKonstantinov - 19-Nov-2010
 
33 12 2.10 Is PGI going to be also the name of the (set of) standard(s) or is it the name of the working group?
-- AlbertoDiMeglio - 08-Nov-2010
It is name of working group. There are no names for planned standards/profiles defined as far as I know.
-- AleksandrKonstantinov - 19-Nov-2010
 
34 13 2.11 Probably I do not understand how LDAP is used in this context, but it’s not just ARC using it. All the BDII compone nts and info providers in gLite are based on LDAP
-- AlbertoDiMeglio - 08-Nov-2010
I know that. But no PT provided that kind of information. I did not want to put information which I'm not sure about. If You could authoritatively name EMI components I could add that information.
-- AleksandrKonstantinov - 19-Nov-2010
 
35 15 Table 4 Although, it would seem good, it is arguable at this point in time to state that all compute services within EMI will adopt PGI. I’m not saying it is incorrect, but we should be a bit more conservative on the statements until we have a wide agreement within EMI
-- AlbertoDiMeglio - 08-Nov-2010
I would rather leave that to Morris.
-- AleksandrKonstantinov - 19-Nov-2010
 
36 17 3 Add the MSWG?
-- AlbertoDiMeglio - 08-Nov-2010
I have no information about MSWG. This is a first time I see this abbreviation. Maybe I know it by another name?
-- AleksandrKonstantinov - 19-Nov-2010
 
37 20 5 This section is too focused on the Compute Interface. Is this really the only risk in standardization? At the very least I could see another big risk: if open standardization activities do not converge to agreed specifications within a reasonable time and EMI doesn’t have a plan B, then EMI may not have a common Compute Interface within the EMI lifetime. Can you find a more balanced exposition of all risks?
-- AlbertoDiMeglio - 08-Nov-2010
CE is a thing I know most. For next deliverable I hope I will be able to collect more information to extend this section to more risks. Concerning plan B I think there is a misunderstanding. As far as I know actually plan B is plan A because EMI is developing own common interace which is then planned as feedback to PGI (this is why PGI is mostly relevant to EMI). If EMI would have PGI as its plan A I would call section "elevated risks".BR%-- AleksandrKonstantinov - 19-Nov-2010
I don’t understand this risk at least in the way it is expressed here. Clearly a transition from a situation where each middleware has its own interface to a situation where everybody adopts a standard require a period of migration and coexistence of interfaces. This is not a risk, but more a fact of life that we have to manage. Said that, the picture here represent a situation that we should avoid and for which we need a plan. The objection here from external reviewers is that this is a risk only if we do not manage it. If we do manage it then we will only have legacy interfaces and a single standard interface.
-- AlbertoDiMeglio - 08-Nov-2010
I think Morris can anwer better. My undertanding is that picture serves to represent how things can go and options from top to bottom are ranked from worst to best.
-- AleksandrKonstantinov - 19-Nov-2010
 
38 20 5 “Second, the major open standard that is currently in place is the OGSA-BES interface “ Yes, but it’s not really used by everybody, as you point out, I don’t think that there would be problem in dropping it and certainly it doesn’t have to be maintained if other solutions are available
-- AlbertoDiMeglio - 08-Nov-2010
UNICORE is using it in production setup. ARC is planning to deploy it rather soon at least in limited amount.
-- AleksandrKonstantinov - 19-Nov-2010
 
39 20 5 “those two components have to be maintained” I don’t think it is maintained at the moment
-- AlbertoDiMeglio - 08-Nov-2010
Not sure about CREAM. ARC and UNICORE do as far as I know.
-- AleksandrKonstantinov - 19-Nov-2010
 
40 21 6 I guess there is not much too say about SIENA, but the Exec Summary states “This report also summarizes shortly the status of the SIENA standards roadmap progress”. I don’t see such status report here.
-- AlbertoDiMeglio - 08-Nov-2010
"... the initiative just begun and nothing is to report so far, but further reports will update and report on its progress ..."
-- AleksandrKonstantinov - 19-Nov-2010
 
41 21 7 This section according to the template should be called Conclusions. And a section describing the EMI work plan for standardization is missing altogether. I’d like to see a description of which standards are going to be addressed in EMI1, EMI 2, EMI 3 according to the current understanding, a timeline, something that conveys the idea of a plan with milestones and check points
-- AlbertoDiMeglio - 08-Nov-2010
Sections naming changed after application of new template. Concerning detailed plan please see above.
-- AleksandrKonstantinov - 19-Nov-2010
 

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.

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2011-04-19 - unknown
 
    • 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-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback