> -----Original Message-----
> From: Paul Leach [mailto:paulle@Exchange.Microsoft.com]
> Sent: Tuesday, January 18, 2000 8:42 PM
> To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' Morgan; Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
> Services with DNS
>
>
>
> -----Original Message-----
> From: James Benedict [mailto:grunt@nortelnetworks.com]
> Sent: Tuesday, January 18, 2000 7:31 AM
> To: RL 'Bob' Morgan; Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering
> LDAP Services
> with DNS
>
>
> > The problem with this method is that the resolving client
> must already
> > have knowledge about the directory containing the DN.
> Specificly, the
> > resolving client must expect that the DC tree represented by the DN
> > is a valid internet domain.
>
> This isn't strictly true. The client just guesses that the
> "DC=" components
> form a DNS name; if the guess is wrong, it will find out soon enough.
>
Agreed, but the value in making this computation is in having a high degree
of confidence that it will be correct. What I am saying is that there is no
real way of gaining a high degree of confidence without having prior knowledge
of the directory service.
> Since, as Bob points out, one is currently hosed if this
> guess is wrong, the
> incentive to make it be correct will be high. I think this is "a good
> thing".
>
Agreed, to a point. I think that having a domain-based directory tree can be a good thing, in some cases, an OSI-based tree in others. What this solution requires is some sort of agreement around two assumptions:
1) That "Internet" LDAP DNs are arranged by domain component, and
2) The aforementioned domain components can, eventually, be resolved on
the internet.
(a third, and obvious assumption: that this form of discovery is supported)
I just don't think these are all that practical. What I would suggest is to
embed the DNS name of the Internet LDAP server in the DN, maybe as the root.
Something like:
cn=James Benedict, ou=sales, ou=employees, o=nortelnetworks, ldap=ldap.nortelnetworks.com
or
cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com
Where ldap=ldap.nortelnetworks.com is an explicit reference to the DSN record
you are trying to determine, regardless of how the company's actual DNS
is structured.
eg. ldap.nortelnetworks.com could be an alias for a firewall, which in turn,
forwards port 387 to server1.dmz.nortelnetworks.com and server2.dmz.nortelnetworks.com. Both of which are replicas of ldap.us.nortelnetworks.com.
Note that by providing an internal DNS record for ldap.nortelnetworks.com I can also use this discovery technique for internal and external resolution.
This only requires one assumption:
1) The ldap=<server> (or whatever attribute name makes sense) is resolvable
Still a hefty assumption, but far less imposing. It doesn't constrain the DIT as much, and it allows the client to make one simple check (is ldap=<whatever> in the DN) before it decides whether to use this resolution or not.
> Paul
>
Anyways, just my $0.02 (or 0.0133333 $CDN :-)
James A Benedict
Advisor, IP Directory Systems Architecture
Carrier Packet Solutions
NORTEL NETWORKS
Ph: (613) 763-3909