Re: alternate "dc" naming conventions

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Applogies for the delayed response...

> I'm working with a directory implementation that needs something
> like DNS SRV records and the locater draft to scale.  But the
> current locater  draft doesn't fit well with this implementation.
> I think it is in our interest to ask that the locator draft
> be extended to include some other well-structured cases
> beyond the current right-most dc= list.  If that's done, then
> our standards process can reference the IETF's work & hopefully
> interoperate.   Alternatively, I can produce a knock-off of the
> current locator that would describe our requirement.  (How
> useful would this be?)

As there are so many different naming conventions, it is
unlikely that one mechanism will satisfy the needs of all.

The current locate mechanism was specifically designed for
those using RFC 2047 naming.  It's simple and doesn't require
significant operational overhead.  (Supporting all dc's
will lead to requiring multiple DNS lookups to locate services
for a DN).

> The DIT in the directory software supporting Grids
> (see http://www.gridforum.org and www.globus.org)
> has a number of conventions in its history.  The original one,
> which still exists in some large deployments, looked like
> this:
>
> (grid dn components), o=Your Name Here, o=Globus, C=us
> that is, a non-conformant X.500 style of naming.

Assuming O=Globus,C=US is properly registered, the services
can be located using <draft-zeilenga-ldap-x500-locate-01.txt>.

> The current implementation supports names like this:
> (grid components), dc=biglab, dc=org, o=grid

Provding location services for unmanaged name spaces
(such as o=grid) is not manageable.

> The planned implementation wants dn's to look like this:
> (grid components), dc=biguni, dc=edu, vo=Internet, o=Grid
> and
> (grid components), vo=MyOrg, o=Grid

> The assumption here is that whoever is querying the directory
> service (whatever directory service) somehow "knows" where the
> server that supports the suffix "vo=MyOrg, o=Grid" is ab initio.
>
> But no such asssumption about "dc=biguni, dc=edu, vo=Internet, o=Grid"
> is made for the benefit of this server.  Ideally the server deals with
> this by a referral.   The nature of the software supporting the grid
> architecture requires a large number of referrals as the mesh grows,
> and maintenance of these records individually won't scale well.
> Thus the utility of DNS SRV.

Problem in using one mechanism is that "dc=biguni,dc=edu" and
"dc=biguni,dc=edu,vo=Internet,o=Grid" may be managed by
separate entities or managed by one entity on different sets
of servers.  I suggest using a private mechanism for locating
such DNs (using different RRs than the standard mechanism)
or for automating knowledge information management in the
superior service.

> It's likely that Grid certificate authorities will issue certificates
> with these kinds of names in the near future.  The security services
> are evolving requirements for directory, and probably also will
> have to interoperate with existing PKI's that may have adopted
> X.500-type naming conventions such as Tim Polk described.

For those using X.500-type naming conventions, location should
be based on that naming, not DCs placed subordinate to the
naming context.  (This is the crux of the problem, folks want
to abuse DC naming to solve a problem which is better solved
by providing a separate mechanism).

> (NB: I would appreciate any comments on this, but please
> separate your comments & reaction on the architecture from those  related
> to the request to extend  the locator draft :^)  Thanks, ==mwh

Sorry, I kind of mixed them up a bit...