SA1 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: Björn Hagemeier Affiliation: JUELICH EMI Activity/External project or Institute: JRA1

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

Attach the reviewed document to the deliverable page, put here a link: 2010-10-09_EMI_DJRA1.5.1_v4_bh.doc

General comments

  • In section 2, you often mention "all WS-based services" when some of them have already been mentioned before.

-- BjoernHagemeier - 10-Nov-2010

The purpose is to emphasize some of them for which most information is/was available.

-- AleksandrKonstantinov - 19-Nov-2010

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

  • I think Alberto already mentioned the formatting and sticking to the document template. Please be sure to do so.

-- BjoernHagemeier - 10-Nov-2010

Implemented by rewriting document using newest template.

-- AleksandrKonstantinov - 19-Nov-2010

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 Is Addressed?
1 9 Table 3 SOAP based WS are also used in the infrastructure area, e.g. UNICORE Registry. -- BjoernHagemeier - 10-Nov-2010
-- AleksandrKonstantinov - 19-Nov-2010
2 9 Table 3 It is not obvious why REST should affect security and why it should not affect other areas. -- BjoernHagemeier - 10-Nov-2010
Only identified component which was planning support for REST is VOMS.
-- AleksandrKonstantinov - 19-Nov-2010
3 9 Table 3 JSDL defines data staging and thus affects data. See Oxana’s slides from OGF 30, page 10, #143: Data Staging MUST support an agreed set of protocols in PGI, e.g. HTTP(S), scp, gridftp, mailto, RNS/ByteIO ( -- BjoernHagemeier - 10-Nov-2010
JSDL is not accepted by any dervice doing data management as its primary task. So JSDL relates to data staging only indirectly. Intentaiton was to avoid inderect reference. Otherwise every mentioned standard would have all areas listed.
-- AleksandrKonstantinov - 19-Nov-2010
4 11 2.5 REST isn't standardized at all, it's an architectural pattern -- BjoernHagemeier - 10-Nov-2010
I'm aware of that. It is mentioned in document that REST is weakly standardized. Unfortunately currently there is no more definitive information available.
-- AleksandrKonstantinov - 19-Nov-2010
5 12 2.11 I think gLite would also be affected by LDAP. What are gLite's plans on this? -- BjoernHagemeier - 10-Nov-2010
Did not get that information during survey. It will definitely be in next deliverable.
-- AleksandrKonstantinov - 19-Nov-2010
6 12 2.12 "... XACML as one of ...". Why only "one of", wouldn't that just add complexity? Can legacy authorization languages be phased out instead? -- BjoernHagemeier - 10-Nov-2010
XACML is quite complex and not human-friendly. And it is rather internal decison of PT and corresponding JRA. But not this one. Have UNICORE droped UAS with adoption of BES? :)
-- AleksandrKonstantinov - 19-Nov-2010
7 15 Table 4 The separation of components is weird. For instance, you mention "UNICORE components" and then further down "UNICORE-BES" and "UNICORE Atomic Services". However, "UNICORE components" adopt XACML and SAML, but UNICORE Atomic Services and UNICORE-BES don't. -- BjoernHagemeier - 10-Nov-2010
I think Morris could explain that.
-- AleksandrKonstantinov - 19-Nov-2010
8 15 Table 4 If you agree to the changes of attributions I mentioned for Table 3, then please change this table accordingly. -- BjoernHagemeier - 10-Nov-2010
See above.
-- AleksandrKonstantinov - 19-Nov-2010
9 17 3.2 "releases the same set of attributes". Are these attributes really released or is this just about how things are stored in the server? -- BjoernHagemeier - 10-Nov-2010
Here "releases" means that VOMS is returning some assertion as result of request. So here "releases" indeed is about something that is released out of service.
-- AleksandrKonstantinov - 19-Nov-2010
10 18 3.4 "designing a computing job description language" this contradicts the JSDL activities or at least needs a good explanation for the two-pronged approach. Design new, fine. Extend JSDL, also fine. But doing both doesn't seem like the best option. -- BjoernHagemeier - 10-Nov-2010
Document does not state that this language is designed from scratch. It depends on internal decision of corresponding group. JSDL is long term activity, so relying completely on JSDL is most probably will not work due to time constraints. As particpant of that group I can say that new design is actually based on JSDL.
-- AleksandrKonstantinov - 19-Nov-2010
11 18 3.5 Aren't the information services also affected by the XML rendering? I would think they provide the information in an XML format. -- BjoernHagemeier - 10-Nov-2010
Document says that activity is driven by infrstructure and computing. In my understanding information services belong to infrastructure. Concerning format/protocol of EMI information services, those which I know about are LDAP based. Inofficially I also heard that may change.
-- AleksandrKonstantinov - 19-Nov-2010
12 20 5 If both the newly defined job description language and the extension of JSDL will be pursued, then this is a risk, too. -- BjoernHagemeier - 10-Nov-2010
JSDL extrensions is new language being developed. Here extension is in broader sense. Either it will be new XSD rendering or just new elements will depend of outcome of corresponding group.
-- AleksandrKonstantinov - 19-Nov-2010
13 21 6 "in the field of..." what? -- BjoernHagemeier - 10-Nov-2010
-- AleksandrKonstantinov - 19-Nov-2010
14 21 6 "more than seventeen": not all of the above mentioned standards are OGF standards. All of them may or may not influence OGF standards, but the statement as it stands implies that all standards belong to the OGF body. -- BjoernHagemeier - 10-Nov-2010
Term "open" does not necessary refer to Open Grid Forum. There are other standards which can be considered as "open enough". So document does not relate them to OGF.
-- AleksandrKonstantinov - 19-Nov-2010
15 10 2.1 “Reasons can be found in deliverables of the security area” This is too vague, please reference the deliverables and at least list the reasons given therein.
-- BjoernHagemeier - 10-Nov-2010
Reference to corresponding deliverable added.
-- AleksandrKonstantinov - 19-Nov-2010
16 20 5 ” This interface is used in production” I would rather say “deployed”. As we don’t have any usage data regarding the interfaces, I would assume that users use the UAS interface rather than BES.
-- BjoernHagemeier - 10-Nov-2010
"used in production" is changed to "deployed".
-- AleksandrKonstantinov - 19-Nov-2010
17 21 6 “ of its major outcomes is a common standards roadmap for European projects in the field of “ What?
-- BjoernHagemeier - 10-Nov-2010
Text is fixed. Now it is "... in the fields of Cloud and Grid computing.".
-- 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.

-- FloridaEstrella - 11-Oct-2010

Topic attachments
I Attachment History Action Size Date Who Comment
Microsoft Word filedoc 2010-10-09_EMI_DJRA1.5.1_v4_bh.doc r1 manage 350.5 K 2010-11-10 - 11:09 BjornHagemeierExCern DJRA 1.5.1 v4 reviewd by bjoernh
Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2010-12-02 - 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