Re: DN->DNS mapping in draft-ietf-ldapext-locate-05.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:47 AM 3/26/01 -0800, RL 'Bob' Morgan wrote:
>David:
>
>> Can you give us more details about how this migration path is supposed
>> to work. And also why creating low down dc branches is more beneficial
>> than creating dc branches from the root. I would like to understand
>> how and why they want this change in the locate ID to be made, and if
>> there is a sensible technical reason for choosing the method they are
>> proposing, rather than one that conforms to the existing locate ID.
>
>Well ... because with an already-deployed directory it's (perceived as)
>easier to change names of lower nodes rather than top ones.
>
>But I have to think that the burden of proof goes the other way.  What is
>the "sensible technical reason" for having the mapping the way it is in
>-05?  Why is a mapping that imposes more limitations on naming better than
>one that permits more options, however unsightly they may seem to some?
>So far there has been a lot of hand-wringing but not a single substantive
>reason that I can see.

As long as folks don't start asking us to walk up the DN/DNS tree to
find their SRV records, I don't have a significant objection to the
proposal.  What?

Say you have a DN "dc=foo,dc=com,ou=domains,dc=bar,dc=net" and there
is no DNS SRV information for "foo.com.bar.net".  However, the admin
actually has all of "dc=bar,dc=net" in held by one server and doesn't
want to administrate SRV records for all DNs which contain DC values
under her context point as this change would require.

Anyways, my point here is that the mapping change is not necessarily
"more flexible" in that it hinders other uses of DCs for naming as it
requires all DCs used for naming to also be used for location.

Kurt