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

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

> -----Original Message-----
> From: Bruce Greenblatt [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2000 6:50 PM
> To: Paul Leach; [email-masked]
> Subject: RE: draft-ietf-ldapext-locate-01.txt - Discovering LDAP
> Services with DNS
> 
> 
> At 05:33 PM 1/18/00 -0800, Paul Leach wrote:
> >
> >
> >> -----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.
> >
> 
> 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.

That's too long and bulky to say everywhere it currently says "native".

I don't see what's wrong with "native" -- it means that they aren't a front
end to X.500. Hence they can't use X.500 capabilities, and clients can
expect service that requires those capabilities. In some cases, that means
both clients and servers are out of luck -- clients have to apriori know the
DNS name of the server that stores a given DN, and a server that recieves a
request for a DN in an NC it doesn't store can't generate a referral.

However, if the DN starts with "DC=", then things can be better if they
follow the proposal in the draft: the client can get to a server, or a
server given a request for such a DN can generate a referral. All the server
has to do is get SRV records registered for the NCs it stores -- ones that
are resolvable by all the clients it cares to serve.

Paul

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 20 Jan 2000 10:40:55 -0800 (PST)

Paul:

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

Sure, but you have to define the "problem" at the right level.  A problem
description that spends two paragraphs on issues that need a lengthy
document to adequately describe them creates more confusion than
enlightenment.  RFC 2247, as one example, scopes its problem description
appropriately IMHO.

This doc is about a particular method to determine servers based on DNs.  
Presumably this method is interesting to the extent that other methods
don't meet particular requirements.  I suggest that a description of the
range of requirements and possible solutions, so as to explain how this
one fits in, is way beyond the scope of this doc.  Even the taxonomy doc,
which attempts to cover more of this territory, doesn't do enough IMHO.
This is why there still needs to be a LSD working group ...

> I don't see what's wrong with "native" -- it means that they aren't a
> front end to X.500. Hence they can't use X.500 capabilities, and
> clients can expect service that requires those capabilities. In some
> cases, that means both clients and servers are out of luck -- clients
> have to apriori know the DNS name of the server that stores a given
> DN, and a server that recieves a request for a DN in an NC it doesn't
> store can't generate a referral.

This use of "native" may be useful for some purpose, but I think it's not
particularly relevant to the mechanism being specified.  What the doc is
trying to express by "a front end to the X.500 directory service" is more
precisely the use of the method of embedding knowledge references in the
DIT to glue together DSAs.  The DNS-based mechanism is obviously being
offered as an alternative to this.

But this really isn't a X.500/not-X.500 distinction.  In practice there is
no worldwide X.500 Directory based on civil naming or any other naming, so
real X.500 DSAs are glued together into communities of only local scope
(possibly national in some cases; can any X.500-knowledgable people
comment on the status of this?).  So even a X.500-capable DSA that uses
some DIT-based glue might find the DNS-based mechanism useful if it allows
it to discover servers for NCs that it couldn't otherwise.  Conversely,
despite the methods not really being standardized, in practice people do
use embedded knowledge references to glue together LDAP-only DSAs; the
DNS-based method might appeal to them also.

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 could write this up more formally ... 8^)

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.

 - RL "Bob"

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 20 Jan 2000 18:58:21 -0800

At 10:40 AM 1/20/00 -0800, RL 'Bob' Morgan wrote:
[snip]
>       but that's OK since we're already familiar with DNS-based names.

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

(1) Sometimes you get a DN from places other than the LDAP server in which
the DN lives
(2) You need to find the LDAP server to get some other information about
the entry to which
    the DN refers, e.g. email address
(3)-(5) see above...

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