[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS



Title: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services with DNS
 
-----Original Message-----
From: James Benedict [mailto:grunt@nortelnetworks.com]
Sent: Wednesday, January 19, 2000 6:21 AM
To: Paul Leach; 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: Paul Leach [mailto:paulle@Exchange.Microsoft.com]
> Sent: Tuesday, January 18, 2000 10:30 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
>
...
> > What this solution requires is some sort of agreement around two
> assumptions:
> > 1)  That "Internet" LDAP DNs are arranged by domain component, and
>
> No, it does not depend on any such agreement.

> It _allows_some_ people to

These words make me cringe when I hear them.  Anything that is designed
to "allow some" people to do something implies that "other" people will
be doing something else.  This doesn't speak well for convergence of
directory applications.
[Paul Leach] People who choose to use "O=Foo,C=Bar" as their name form have to do _something_ else. If I knew what they could do, I'd make a proposal --e xcept that if I did, I'd run into an incredible political tarpit -- many people have tried in the past, and no one has suceeded. People who choose to use "dc=example,dc=com" and don't want to use the proposed mechanism -- well, I think that's what it was designed for (but you'd have to ask Steve Kille and Mark Wahl to be sure), so I don't know why they wouldn't want to use it. But they don't _have_ to. In fact, for backwards compatibility, the ability to use prior knowledge of the DNS name of the server holding the DN is required -- so in that sense, too, the "native" proposal is only "allowed".

But, to address your fears -- there isn't an alternate way to do the same thing as the draft proposes. But it isn't required that everyone deploy it in order to make it useful.

[Paul Leach] <snip>

 I would suggest an addendum to the draft that "recommends" that "Internet"
directories arranged with a dc-tree provide some sort of LDAP service
that can be resolved at some point by walking up the tree.  eg.

cn=James Benedict, ou=sales, dc=us, dc=nortelnetworks, dc=com

Maybe I don't want to make _ldap._tcp.us.nortelnetworks.com and
_ldap._tcp.uk.nortelnetworks.com, etc. visible to the Internet, but
_ldap._tcp.nortelnetworks.com wouldn't be too bad. It would have for
us a while ago when we went from nt.com to nortelnetworks.com externally
first, then internally.  But that could be solved with an alias.
[Paul Leach] That's what I thought, too. Since it was easy to solve with an alias, I thought "why complicate things? Use the DNS mechansim that exists".

Paul