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

From: Michael Armijo <[email-masked]>
Date: Thu, 6 Jan 2000 11:46:36 -0800

Internet-Drafts Editor:
Please replace draft-ietf-ldapext-locate-00.txt with the updated version
draft-ietf-ldapext-locate-01.txt.

LDAPEXT DL Members:
I have updated the Locate document.

It now includes a reference to RFC 2052, per WG request.

A sentence has been added referring to 'Assigned Numbers' for the use of
'ldap' in the SRV record.

	Note that "ldap" is the symbolic name for the LDAP service in 
	Assigned Numbers [7], as required by the SRV Protocol[6].

There were a few other minor editorial changes.
I would like to submit this version for WG last call.  WG chairs, please
advise.

thanks,
Michael

 <<draft-ietf-ldapext-locate-01.txt>>

---

From: Luke Howard <[email-masked]>
Date: Sat, 8 Jan 2000 11:57:34 +1100

>P.S. As an aside, who in California has the personalized license plate LDAP???

I believe it's Leif Hedstrom, who works at Netscape.

-- Luke

--
Luke Howard
PADL Software Pty Ltd
http://www.padl.com

---

From: James Kempf <[email-masked]>
Date: Mon, 10 Jan 2000 08:00:34 -0800 (PST)

Ryan's draft includes a number of other techniques for locating LDAP
servers. Interoperability using them could benefit by standardization
as well. Is LDAPEXT interested in considering proposals for standarization
of other location methods?

		jak

>Resent-Date: Fri, 7 Jan 2000 17:02:10 -0800 (PST)
>X-Authentication-Warning: perq.cac.washington.edu: rlmorgan owned process doing 
-bs
>Date: Fri, 7 Jan 2000 17:01:38 -0800 (PST)
>From: "RL 'Bob' Morgan" <[email-masked]>
>To: Bruce Greenblatt <[email-masked]>
>cc: Michael Armijo <[email-masked]>, [email-masked], 
[email-masked], "[email-masked]'" <[email-masked]>
>Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP  Services with 
DNS
>MIME-Version: 1.0
>Resent-Message-ID: <"iduLSD.A.dOB.6xod4"@glacier>
>Resent-From: [email-masked]
>X-Mailing-List: <[email-masked]> 
>X-Loop: [email-masked]
>Resent-Sender: [email-masked]
>
>
>On Fri, 7 Jan 2000, Bruce Greenblatt wrote:
>
>> All this draft says is that if you use DC naming, you can look up the
>> appropriate LDAP server using DNS.  Is that right?  Or is there
>> something more?  If there isn't anything more, why do we need to say
>> it here. Shouldn't it go into Ryan and Roland's taxonomy draft, since
>> they already have a section (2.5) on using SRV records?
>
>Because ldapext-locate would become a Proposed Standard, and needs to be
>so to satisfy both common sense and the requirements of
>draft-ietf-dnsind-rfc2052bis-05.txt:
>
>   Applicability Statement
>
>   In general, it is expected that SRV records will be used by clients
>   for applications where the relevant protocol specification indicates
>   that clients should use the SRV record. Such specification MUST
>   define the symbolic name to be used in the Service field of the SRV
>   record as described below. It also MUST include security
>   considerations. Service SRV records SHOULD NOT be used in the absence
>   of such specification.
>
>whereas the taxonomy draft will be Informational only.
>
> - RL "Bob"
>
>

---

From: Paul Leach <[email-masked]>
Date: Tue, 18 Jan 2000 17:33:52 -0800

> -----Original Message-----
> From: Bruce Greenblatt [mailto:[email-masked]]
> Sent: Monday, January 17, 2000 4:36 PM
> To: [email-masked]
> Subject: Re: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
> Services with DNS
> 
> 
> I don't understand (or necessarily agree with) the first two 
> paragraphs of
> this draft.  What difference does it make to this mechanism 
> what a "native"
> LDAP server is?

We needed a word to describe servers whose NCs have DNs that start with a
series of "DC=" components. Ones that don't have such names for their NCs
are using the X.500 naming model with LDAP front ends -- those are
"X.500-ish" LDAP servers.

>  If this mechanism doesn't work for non-native LDAP
> servers, shouldn't the draft explain why this is the case?

Of course it doesn't work -- what DNS name corresponds to "O=Example,C=US"?
The mechanism depends on the DN starting with a series of DC= components;
i.e., that they be "native".
  
> I'd just drop
> this whole notion from the draft.
> 
> Can this same mechanism be used to find an LDAP server from an email
> address? It seems like you should be able to find the appropriate SRV
> record from an email address just as easy as you can from a DN that
> conforms to the DC naming principles.

Sure, but only if the SRV records are registered. Nothing today existing
says they should be. I don't think finding an LDAP server from a email
address is particularly interesting by itself, only in association with a
larger task, such as perhaps finding a certificate for a user given their
email address, or (in general) their directory entry, in order to get their
telephone number or manager's name or whatever. I believee there was some
discussion about that sort of thing, even a draft.

Paul

---

From: Paul Leach <[email-masked]>
Date: Tue, 18 Jan 2000 17:42:18 -0800

-----Original Message-----
From: James Benedict [mailto:[email-masked]]
Sent: Tuesday, January 18, 2000 7:31 AM
To: RL 'Bob' Morgan; Bruce Greenblatt
Cc: [email-masked]
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.

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".

Paul

---

From: Paul Leach <[email-masked]>
Date: Tue, 18 Jan 2000 18:19:47 -0800

> From: RL 'Bob' Morgan [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2000 1:15 AM
> To: Bruce Greenblatt
> > paragraphs of this draft.  What difference does it make to this
> > mechanism what a "native" LDAP server is?  If this mechanism doesn't
> > work for non-native LDAP servers, shouldn't the draft 
> explain why this
> > is the case?  I'd just drop this whole notion from the draft.
> 
> You're right that this method is useful independent of what 
> kind of LDAP
> server is to be discovered (it is of course only defined in 
> the case of
> DNs that map to DNS domain names); hence this text and the 
> "Internet based
> organization" bits are not needed.  Also, this paragraph:
> 
>    This draft defines a way that native Internet LDAP servers 
> can make 
>    use of the DNS's knowledge base to perform the same 
> function, while 
>    still supporting integration with the X.500 directory.
> 
> is misleading since the method can be used by any process, client or
> server, that wants to determine server names from a DN.

I just read the draft again, and I agree that this section seems out of
context. The phrase "the same function" seems to be unbound to any
antecedant. As I looked back at a previous draft, a paragraph got lost. It
used to say:

"A native LDAP server can not rely upon the X.500 directory's knowledge base
to locate the appropriate server to service a request on an object in a part
of the directory tree (DIT) other than the naming context(s) it stores.

This draft defines a way that native Internet LDAP servers can make use of
the DNS's knowledge base (which it stores as "glue" records) to perform the
same function, while still supporting integration with the X.500 directory."

This still isn't great, but at least there's no danglisng reference.

All I was trying to say is that native LDAP servers have a unique problem
that they wouldn't have if LDAP servers were just front ends for the X.500
directory. In that case, a client wanting to resolve a DN could contact any
LDAP server, and if the DN weren't stored in one of that server's NCs, it
could generate a referral to a better LDAP server, which would ultimately
get to the server storing the DN.

Since native LDAP servers have no backing X.500 directory, they can't do
that. What they can do is try to use DNS instead -- by constructing a DNS
name from the "DC=" components.

I don't think this is worth holding up progress for. I can make an editorial
change befre the RFC is published, if people think its really important.

Paul

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 18 Jan 2000 18:49:43 -0800

>"X.500-ish" LDAP servers.

OK.  The draft should drop the use of "native", and just say that it
applies to LDAP servers that have standardiz(s)ed on the "DC" naming RFC.
I liked the words in the original version of the taxonomy draft that said
something to the effect of: "If the directory uses DC naming then you can
do this...".  I'd also mention the sentiments expressed by R. L. "Bob":

>Indeed, if directory objects are named based on DNS names, then this
>method can be used.  Otherwise, there is no defined dynamic discovery
>method.  I know which naming scheme I'll choose.
>

I've also attached my (very) old draft that talks about how to get a
directory entry from an email address.  The locate draft and the taxonomy
draft don't seem to deal with this issue.  Does anyone think that I should
update this and get it moved forward as an Informational Draft?

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: "James Benedict" <[email-masked]>
Date: Tue, 18 Jan 2000 21:57:30 -0500

> From: Paul Leach [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2000 8:42 PM
> To: Benedict, James [CAR:5N41:EXCH]; RL 'Bob' Morgan; Bruce Greenblatt
> Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
> Services with DNS
> 
> 
> 
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.

> incentive to make it be correct will be high. I think this is "a good

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

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 18 Jan 2000 19:24:22 -0800

At 07:12 PM 1/18/00 -0800, Paul Leach wrote:
>
>That's too long and bulky to say everywhere it currently says "native".
>

Maybe not. Attached is a fixed up version of the draft that doesn't use the
term "native", removes some "noise", and says the same thing.

---

From: Paul Leach <[email-masked]>
Date: Tue, 18 Jan 2000 19:30:03 -0800

-----Original Message-----
From: James Benedict [mailto:[email-masked]]
Sent: Tuesday, January 18, 2000 6:58 PM
To: Paul Leach; RL 'Bob' Morgan; Bruce Greenblatt
Cc: [email-masked]
Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services
with DNS

knowledge 
> of the directory service.

It does not require prior knowledge about any one server -- just that enough
servers use the scheme to make it worthwhile to try -- since the alternative
is a _hard_ requirement for prior knowledge -- of the DNS name of the
server.
 
> 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.  

I wasn't making any statement at all in that regard. I was saying that the
fact there was incentive to register the SRV records is a good thing.

> What this solution requires is some sort of agreement around two
> 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
so arrange their DNs. In exchange, it lets them get resolved, without
requiring prior knowledge of the DNS name of the server holding the DN. I
think that that's a powerful incentive, enough to cause its use to be
widespread.

the internet. 
> I just don't think these are all that practical.

Seems easy, to me.

> What I would suggest is to 

Unfortunately, "ldap=" is not a legal DN component. It took RFC 2247 to make
"dc=" a legal DN component. 

We went through these kinds of alternatives in the process of coming up with
the current proposal.

Paul

---

From: Paul Leach <[email-masked]>
Date: Tue, 18 Jan 2000 19:36:59 -0800

I really dislike specs that present solutions without describing the problem
being solved.

> Sent: Tuesday, January 18, 2000 7:24 PM
> To: Paul Leach; [email-masked]

---

From: "James Benedict" <[email-masked]>
Date: Wed, 19 Jan 2000 09:20:41 -0500

> Sent: Tuesday, January 18, 2000 10:30 PM
... 
> 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.

Having said that:  I understand, and accept, the fact that LDAP
directories will always be "slightly" different, and will likely
require a multitude of service discovery methods.

I not sure see this approach as being usefull on the "Internet" as
much as in an "Intranet".  If I use a dc-structure, it is more likely
to reflect my internal domain structure, unless my directory is real
small.  It does raise the question of whether I would *actually* expose
that directory tree to the Internet or not...

I guess my real problem with this particular method is the fact that
the client never really has any confidence until it queries DNS. 

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.

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.

--james
James A Benedict

---

From: Paul Leach <[email-masked]>
Date: Wed, 19 Jan 2000 10:39:27 -0800

> From: Dumitrescu, Teodor [mailto:[email-masked]]
> Sent: Wednesday, January 19, 2000 7:55 AM
> To: Paul Leach; 'Bruce Greenblatt'; [email-masked]
> Paul,
> I wasn't aware that "native" means non-X.500. And for the 
> purpose of this
> discussion the X.500 LDAP front ends do support DC= naming 
> components. In
> fact they are/should be indistinguishable over the wire from "native"
> servers.

It's a fairly typical way of using the term "native" in the computer
industry.

As I noted, there is a difference, at least internally -- a "native" LDAP
directory does not enjoy the advantage of powerful knowledge management
inherent in the X.500 directory. Hence, DN resolution presents a problem --
no X.500 knowledge with which to generate referrals.

On the wire, they would be indistinguishable in the case that the client had
prior knowledge of the DNS name of the server holding the DN it wished to
resolve.

Paul

---

From: Paul Leach <[email-masked]>
Date: Wed, 19 Jan 2000 10:31:49 -0800

-----Original Message-----
From: James Benedict [mailto:[email-masked]]
Sent: Wednesday, January 19, 2000 6:21 AM
To: Paul Leach; RL 'Bob' Morgan; Bruce Greenblatt
Cc: [email-masked]
Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP Services
with DNS

> From: Paul Leach [ mailto:[email-masked]
<mailto:[email-masked]> ] 
... 

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>

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 19 Jan 2000 16:29:34 -0800

> that can be resolved at some point by walking up the tree.  eg. 

I disagree...

The algorithm should be simple and require no LDAP nor DNS
tree walking.

An DN of:

is associated with the domain "us.nortelnetworks.com".  If SRV RRs
are not available at "_ldap._tcp.us.nortelnetworks.com", the
application should not attempt further SRV based discovery.

If walking were to be required (or even allowed) then we must
describe how far up the DNS tree a client should walk...  I
think it's a real bad idea to walk up to national SLD,
TLDs, or .

	Kurt

---

From: Paul Leach <[email-masked]>
Date: Thu, 20 Jan 2000 12:00:23 -0800

> Sent: Thursday, January 20, 2000 10:41 AM
> To: Paul Leach
> Paul:
> So here's the pitch:
>   (1)  you need to glue together DSAs somehow
>   (2)  doing this with records in the DIT is possible, but hasn't yet
>        proven effective globally
>   (3)  DNS SRV records can be used for this
>   (4)  this takes advantage of globally-deployed DNS
>   (5)  it only works (so far) for directory objects with 
> DNS-based names, 
>        but that's OK since we're already familiar with 
> DNS-based names.

I agree with all this.

> 
> I could write this up more formally ... 8^)

I'd be happy for you to do so. 
> 
> I'll note in passing that though this method is only defined 
> for DC-based
> DNs at this point, it's possible to imagine mapping 
> civil-name-style DNs
> to DNS labels (under some traditionally-named domain(s)) and 
> hence using
> SRV records to find them too.

Indeed. I'd be happy if someone made a proposal to do that, as well.

Paul

---

From: Paul Leach <[email-masked]>
Date: Fri, 21 Jan 2000 01:12:00 -0800

> Sent: Thursday, January 20, 2000 6:58 PM
> To: RL 'Bob' Morgan; Paul Leach
> At 10:40 AM 1/20/00 -0800, RL 'Bob' Morgan wrote:
> [snip]
> >So here's the pitch:
> >
> As far as I can tell this isn't correct.  This draft doesn't 
> "glue" LDAP
> servers together.  It presents an algorithm that helps you 
> find one LDAP
> server that will probably have an entry for the DN that you have.  So,
> here's my pitch

If an LDAP server for DC=example1,DC=com got a request for
DC=example2,DC=com, the draft also lets it generate a referall to the right
server. That's the sense in which it glues servers together.

Paul