Re: [ldapext] draft-ietf-ldapext-locate

[ned.freed@mrochek.com]

I'm going to take the liberty of responding directly here.

> >(0) It isn't clear when this approach is supposed to be used. DNs are an
> >integral part of *every* LDAP operation. Is it the intent that an
> >LDAP client check every DN it sees for DC fields and if it finds them use
> >this approach. Or is it only appropriate in specific situations?

> It is intended to be a general mechanism for locating LDAP servers
> having knowledge of directory objects associated with a DN in
> absence of location information.  This DN may have been provided
> to the application via LDAP or other means.  If the DN was provided
> with location information, such as a LDAP URL with host part,
> that information should be used.  Howeer, where the DN is provided
> without any location information, this mechanism provides a means,
> for a subset of DNs (those using RFC 2247 naming), for the
> application to locate servers with knowledge of the DN.

> This application may be an LDAP client or server.  OpenLDAP's server,
> for example, can use this mechanism to generate referrals to clients
> requesting DN which it otherwise has no knowledge of.

This is precisely the sort of thing I'm afraid of. OpenLDAP does this but I
doubt SunOne Directory Server (to pick a specific example) does. And given this
document doesn't spell out when this is supposed to be used you cannot claim
that the issue is Sun's failure to implement this standard.

THe opposite situation is also a concern. Suppose I have an LDAP library that
implements this unconditionally and I try to use that library in a situation
where I don't want it to happen. (Uses of DC DNs that don't expect this to
happen do exist, you know; the product I work on in my day job is an example of
this.)

This can be fixed in a bunch of ways. The most obvious one would be to say that
this should be implemented in the following places and whether or not it is
used needs to be configurable.

> >(1) This document specifies two things: How to translate a DN to a DNS
> >name and how to use a DNS name to locate a corresponding LDAP
> >server.

> I argue that the document specifies one process, to locate LDAP
> servers with knowledge of a particular DN, which has two steps.

> >The document seems to imply that the latter is only used when a DNS
> >name is produced by the former. I wonder if this restriction is a
> >good idea: Isn't the ability to use SRV records to locate more generally
> >useful than this limited context?

> I don't believe this document restricts how DNS SRV records
> can be used.  It also doesn't restrict construction of additional
> processes for locating LDAP servers with knowledge of a particular
> DN.  In fact, draft-zeilenga-ldap-x500-locate suggests a process
> for DNs using geo-political naming.

> Additionally, DNS SRVs could be used to answer questions such
> as "Are there LDAP servers associated with this domain?".

This is the separate case I was thinking of.

> Of course, this would be followed by, "What DN is used by
> the owner of this domain for their objects?".  If a listed
> server provides 100s of namingContext, which one is the right one?
> Luckily, we have RFC 2247 which says how the owner of the
> domain should name objects.

Then you should make it clear that this document specifies a single
process, and that it does not specify a process for locating LDAP 
servers for a given domain.

				Ned


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext