glue-wg-bounces@ogf.org

[mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field: The minutes from the latest meeting have been added.

"Next Meeting Friday 12 at 16:00 CET"? On the question of specifying the DIT, I don't think we need to constrain it in general, but I think there are two constraints we could require which would be natural and useful: 1) All the component objects of a Service should be somewhere in the subtree below it. For example, if a Service has a Resource then the Resource object should be somewhere in the subtree below the Service object, as opposed to being below a different Service object or detached and floating around somewhere else in the tree. 2) *If* the DN of a Service object has an AdminDomain as its parent, it should be the AdminDomain which is referred to in the ForeignKey of that Service. In other words, Services should be attached to the site they belong to and not some other site. The reason for the "if" is that resource BDIIs might publish DNs like GLUE2ServiceID=xxx,o=GLUE with no AdminDomain at all, but once you start aggregating Services in a site BDII it should be the one for the site they belong to, and any higher-level aggregation should not undo the site-level grouping. Stephen -- Scanned by iCritical.