Re: alternate "dc" naming conventions

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

At 09:04 PM 7/10/2001, Michael Helm wrote:
>"Kurt D. Zeilenga" writes:
>> In this setup, which is quite common BTW, the superior service
>> needs to hold a subordinate reference and the subordinate
>> service needs to hold a superior reference.  Then the client
>
>I think what are you saying is, anything that is registered 
>in dns as
>_ldap._tcp.es.net
>  like
>        w2kdomain.es.net
>        whitepages.es.net
>        grid-yellowpages.es.net
>
>must be prepared to provide service or referrals for anything
>with dc=es,dc=net as the (appropriate)  part of its base name,
>is that right?

Yes.  The _ldap._tcp.es.net hold SRV location information for
"dc=es,dc=net".  There may objects subordinate to "dc=es,dc=net"
which are locatable using same SRV information or locatable
via LDAP referrals provided by the services referenced in
the SRV information.

>(If not) please straighten me out!
>
>(If so)
>I didn't realize this level of coherence  was required ... I don't
> think it's that explicit in the locator draft.  Should it be?

Yes.

>(Same applies to forbidding  chasing dns search upwards)

Any locate approach which requires the DNS tree to be walked
(in either direction) will negatively impact the operation
of DNS root, TLD, SLD, and ... servers and should be avoided.

>Something about this level of coherence makes me nervous, but I'm
>not exactly sure what.   I don't think I expect it to work perfectly
>(suppose one of the _ldap._tcp.es.net rr's points to a 
>stupid server that gives out bad or incomplete information).

No solution works well with inappropriately configured or in
poor implementations... just like DNS NS RRs and LDAP "ref"
values.

>I would be
>inclined to  code an ldap client to look up all the servers
>it gets from the  dns lookup and exhaust the list of servers in case the 
>previous ones didn't have the base name it was looking for.

Exhausting a long list of RRs would be expensive.  Each of
the listed services should be "equally capable".

>But maybe that's undesirable behavior in some other context.

Yes, this would require a lot of work in deployments who want to
use multiple RRs to list available replicas.

>Leaving aside the dangling o=grid rdn, it seems like one
>appropriate  way  to use dns srv for grid directory servers
>is to register a referral server that could deal with the
>restriction above  &  that clients could find by the usual
>_ldap._tcp.my.domain query.

That is, this is approach is for locating entries named using
RFC 2047 (and entries subordinate to these).  Yes, this approach
has limited applicability.  Other approaches (such as those
described by Skip and myself) can be used for other applications.

>How or whether the other servers
>would be registered in dns is tbd.  They probably should be
>registered, if at all, as some other service or services.

I'd guess that would likely depends on the approach.