Re: alternate "dc" naming conventions

[Michael Helm <helm@fionn.es.net>]

Thanks for responding & discussing the issues.

"Kurt D. Zeilenga" writes:
> > 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.
>
> 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).

Well of course I'm not asking for "all" or "multiple" dc lookups.
They're altogether in one sequence.  It's just the order
of rdn's is different than the locator draft's. 

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

Has anyone (ITU?) actually implemented that? 
(x500.in-addr.arpa)
In the United States at least we would have the additional problem
that no one really owns or manages c=us (unless there
is some recent change), but it's  not clear to me how
that problem maps to that draft SRV  deploymen in 
any event. 

> 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.

That's quite a good objection and one that has been raised by
the architects of this grid service.

I took for an example windows 2000 AD, where you have a complex
NOS - type service taking over that name space (dc=biguni, dc=edu).
(Maybe "horning in" is a better way of putting it than taking over.)

Isn't co-existence going to require looking in the DSE and looking
in the DIT anyway to see if you're in the right place?  One part
of the dilemma is, the need to distinguish the grid services from
any other ldap services, so that you can assemble a reasonable
map of what's available in some well-known server or assemble a reasonable
map  of what's available from an uninformed and unconfigured
grid client; and the other part is the overlap that these services will have
with whatever else might be in dc=biguni,dc=edu (your white pages, 
or your AD domain; or, at another level, the management of these
resource directory servers).

I think what may happen, instead of  dealing with DNS SRV or the
above issues, is an altogether different kind of registration mechanism
will be developed.  

If anyone is interested in helping us with this issue let me know.
Thanks, ==mwh