the locate issue

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

The suggested alternative (using all DCs) is problematic as
it it requires there to be DNS SRV records to be established
for all domain components used irregardless of whether they are
used to name the context.  Consider the DNs
1)  dc=foo,dc=com,ou=hostedDomains,dc=isp,dc=com
2)  dc=com,ou=hostedDomains,dc=isp,dc=com
3)  ou=hostedDomains,dc=isp,dc=com
4)  dc=isp,dc=com

which all refer to entries within the dc=isp,dc=com
naming context held by the server ldap.isp.com.  To
locate these four entries using the suggested alternative
mapping, then three SRV RRs would have to be established
at:
  _ldap._tcp.foo.com.isp.com	[1]
  _ldap._tcp.com.isp.com	[2]
  _ldap._tcp.isp.com		[3,4]

I doubt administrators wish to maintain RRs under multiple
domain names when hosting a single naming context on a
single set of servers.

Consider also the case where a user "uid=mary,dc=example,dc=com"
is allowed at will to create entries subordinate to their entry
without significant restriction (note many servers
don't support optional name form restrictions in LDAP).  For
each of these entries created using DC RDN, the DNS service
for example.com needs to be updated otherwise the entry cannot
be located.

The obvious solution is to change the algorithm such that it
walks the DNS tree.  But this would be a bad thing (as in not
operationally sound).  Besides requiring multiple DNS lookups,
it would cause a huge load upon TLD and root name services.  

In examining the PKI issue, I really don't think they want
to insert DC components into the middle of their DNs... I think
what they want is a mechanism for finding services for entries
named using X.500 conventions. (Note that there are proposals for
such location services.)

I believe it best to stay with the current approach.  Adding
a further note to the last paragraph of section 1 stating that
there is work in progress to define a mechanism for discovery
of services using traditional X.500 naming, possibly with a
non-normative references to Skip's and/or my proposal in this
area, might be appropriate.

Kurt