Hi, I'd like to summarise my views on what aspects of the LDAP DIT should be specified: o The base DN is o=glue. o Extension objects must be immediately below the object they extend (below meaning further from the base DN) because they are logically part of that object. o Service grouping: if there is a Service object, any component objects that relate to it must be somewhere below it in the tree, and no other objects must be there. That means for example that you can remove a Service by deleting the Service object and its subtree. o Site grouping: Services relate to exactly one AdminDomain object which represents the concept of a Grid site (possibly distributed). Similarly to the Service grouping, the tree below an AdminDomain should normally contain all the objects related to it and not objects that relate to other AdminDomains. However, it may be that that can't be an absolute requirement because distributed sites might need a more complex publishing scheme. o Object existence: in general objects are not required to exist in a given server even if references to them exist. For example it may be useful to have a specialised server which only contains some types of object, and an implementation may choose not to publish some types of object at all. However, LDAP does require that all objects whose IDs are used in DNs must exist. This is one argument for not specifying the DIT more than necessary. o Site information: an LDAP server which publishes information for a single site should use a base DN of DomainID=<site-name>,o=glue. That follows naturally from the site grouping principle. o Grid information: an LDAP server which collects information from a range of sites across the Grid should use a base DN of GLUE2GroupID=grid,o=glue. That allows, for example, a single server to provide both site-level and Grid-level information. o Other information: any other information grouping should be published under a base DN of GLUE2GroupID=<group-name>,o=glue, where the group-name is defined by the implementation. o Anything else is free for an implementation to choose. In particular the number of nodes in the tree between any two objects is not defined (other than for Extensions), because it may be convenient to insert grouping objects. I would also like to explain my view on what the LDAP rendering document should and should not specify. Essentially I see it as specifying the LDAP schema and some aspects of the DIT construction as described above. I do not think it should specify anything about a particular implementation technology, notably the BDII, because we want to be free to evolve that technology without breaking compatibility with external clients, by which I mean any software which queries LDAP servers for GLUE 2 information. It also leaves it open to other Grid projects, e.g. OSG or Nordugrid, to develop a different technology which can be interoperable as long as they use the same schema. Stephen -- Scanned by iCritical.