[glue-wg] Summary of changes in LDAP GLUE2 rendering as requested in last meeting

[Florido Paganelli]

Dear all,

Here is the requested summary for the latest changes in the LDAP 
Realization draft.
(see meeting notes 
http://redmine.ogf.org/projects/glue-wg/wiki/29_August_2012)
We really would like to progress with this document and reach an 
agreement for the document ready to be submitted to the ogf procedure in 
one month.

The LDAP document was tracked for changes to the purpose of making it 
easy to check differences between previous versions.

Version 6.0:  http://redmine.ogf.org/dmsf_files/123?download=264

The document also contains open questions that we would like the group 
to discuss. These are recorded as comments in the draft.

We strongly recommend to go through all the changes and give feedback if 
some of the changes is questionable. Below we list the major structural 
modifications:


C1) Rewrite of Section 3.7: Directory Information Tree
The old document contained a proposed DIT that was incomplete and not 
followed by any of the actual implementations. We almost completely 
rewrote the section on DIT, introduced three-level information 
structuring and provided three detailed pictures that correspond to 
actual implementation apart from minor proposed changes.
This is the section that actually contains most of the changes and 
should be read.

C2) Section 3.5 Datatypes
We corrected the datatypes to match the current LDAP schema used by EMI.

C3) All over the document: followed the RFC4512 terminology, e.g. 
renamed "ldap objects" to "ldap entries".



The following open questions arised during the review, and we would like 
the group to discuss them:

Q1) Section 3.4, Object Class types and Inheritance
Choice of structural/auxiliary should be revised.
Seems too restrictive to allow only the first child of the Entity to be 
structural.
For example: ComputingService is not structural.

Q2) Section 3.4, Object Class types and Inheritance
The strange and complex choice on the LDAP attribute names selected to 
form DNs is not motivated and explained.
We would like to discuss a major simplification that makes 
implementation straightforward.
For example, What is the benefit not to have GLUE2Endpoint instead of 
GLUE2ComputingEndpointID or GLUE2ServiceID instead of 
GLUE2StorageServiceID, while all the less important entities such as 
Benchmark have their own GLUE2BenchmarkID?

Q3) Section 3.8, OID assignments
The used OID allocation mechanism is not extensible when it comes to 
adding attributes to entry. Furthermore, the choice is strange, it is 
not applied consistently and its benefits are unclear.
Explaining this in a email is not easy, one really needs to read the 
section and come back for discussion.

Regards,
-- 
Florido Paganelli
Lund University - Particle Physics
ARC Middleware
EMI Project