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