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

[RL 'Bob' Morgan <rlmorgan@cac.washington.edu>]

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"