Subject: Re: LDAP server location and DN->DNS mapping

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 11 Dec 2000 15:34:31 -0800

I asked this same question during the whole DC-naming discussion.  The 
answer that I got was that this was just one way of transforming a DN into 
a DNS host.  It is OK to write a draft that specifies another way of 
transforming a DN that doesn't conform to DC-naming.  So, you (or someone) 
could certainly write a draft that explains how to transform the DNs of 
interest into DNS host names...

Bruce

At 10:12 AM 12/11/00 -0800, RL 'Bob' Morgan wrote:

>draft-ietf-ldapext-locate-04.txt specifies how to use DNS SRV records to
>find an LDAP DS given a DN that has DC components.  This has been mostly
>uncontroversial except for some procedural things (whether to include
>CLDAP, etc).  It has gone thru WG last call but not yet thru IETF last
>call (still waiting on a couple of nits).  However, I'd like to raise a
>fundamental question about how this scheme works, since it was recently
>raised to me while discussing this doc with an IESG member, who said he
>didn't like it the way it is and guaranteed to raise the issue during IETF
>last call.
>
>Section 3 of the draft defines an algorithm for mapping DNs into domain
>names, for purposes of using those domain names for SRV record lookups.
>This algorithm says that only DNs whose most significant components are
>DC= can be mapped, that is,
>
>    cn=John Doe,ou=accounting,dc=example,dc=net
>
>maps to
>
>    example.net
>
>but
>
>    cn=John Doe,ou=accounting,dc=example,dc=net,o=Example Corp,c=us
>
>does not map to any domain name; therefore no use of SRV records to find
>an LDAP DS is defined for such a DN.
>
>The question on the table is:  why does the proposed mapping exclude DNs
>of the second form above?  The mapping algorithm might say: march thru the
>DN from most significant to least significant, gathering DC components as
>you go, ignoring non-DC components; when you reach the end if you have a
>non-empty DNS name use it as input to the SRV record lookup.  This amounts
>to jamming server-location info somewhere in the middle of an existing
>naming scheme.  This looser mapping might be attractive to folks who
>already have deployed directories with non-DC names, or have applications
>that rely on traditional X.521-style civil naming (X.509 PKIs being the
>main case, of course), who could add DC components to some lower levels of
>their naming hierarchy rather than having to change from the top.
>
>Ultimately this raises the deep issue of what kind of interoperability is
>possible and desirable between traditional and DC-style naming.  While
>this is interesting and important, I really don't want to wait until it's
>resolved in order to progress this document.  Given that the looser
>mapping seems trivial for the client to implement, I think the burden of
>proof is on those who advocate the current mapping as to why its
>restrictiveness is important.  While I personally think DNs with DCs
>embedded in them any old place are ugly and I wouldn't design a naming
>hierarchy that way, I don't see any fundamental technical problems that
>should make them illegal (ie, excluded from the SRV-based location
>mechanism).  Maybe others do.
>
>  - RL "Bob"

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 13 Dec 2000 14:09:15 -0800 (PST)

On Mon, 11 Dec 2000, Bruce Greenblatt wrote:

> I asked this same question during the whole DC-naming discussion.
> The answer that I got was that this was just one way of transforming a
> DN into a DNS host.  It is OK to write a draft that specifies another
> way of transforming a DN that doesn't conform to DC-naming.  So, you
> (or someone)  could certainly write a draft that explains how to
> transform the DNs of interest into DNS host names...

Yes, I think this was the consensus at the WG session.

The response of the IESG member I spoke with is that this is an acceptable
point of view for an Informational document, but not for a Standards track
document.

 - RL "Bob"