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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Mar 2001 12:56:35 -0600

Just thought of another issue....  dc has uses outside of
the naming of the context prefix.  I believe some applications
create 'domain' and others (using dc names) entries under an
ou to manage DNS RR.  In particular, in service provider
environments where a provider using dc=example,dc=com as their
naming context, might have a container
  ou=domains,ou=consumer,ou=customers,dc=example,dc=com
and desiring to add entries under this:
  dc=consumer,dc=com,ou=domains,ou=consumer,ou=customers,dc=example,dc=com
to manage the DNS RR for that consumer.  The existing DN to
domain mapping would produce "example.com", the new mapping
would produce "consumer.com.example.com".

Defining a "loose" DN to domain mapping might limit other uses
of 'dc'.  It might be appropriate for those who are engaged in
service provider forums could look into whether the mapping
change would have a significant impact upon their current use
of 'dc'.

Kurt

---

From: [email-masked]
Date: Thu, 22 Mar 2001 14:26:29 -0500

I've run across the need to do exactly what is mentioned below (although the
acutal implementation is slightly different)...the ability to use
dc=customer,dc=com,o=customers,dc=mycompany,dc=com becomes very powerful when
managing/maintaining lots of customer DNS RRs.

That being said though, as an SP we are not managing DNS RRs that way but
instead doing something like fqdnATTR=customer.com,o=customers,
dc=mycompany,dc=com.  Although this probably isn't quite as scalable as 
grouping domains based on their gTLD, it became a tossup between scalability 
and buisiness requirements/ease of use.

I would like to see a common DN structure defined which would allow easier
interoperability with other DITs...however I can also see where this 
could potentially limit companies with different business models from being
able to use this structure (and therefore lose the ease of integration).
I therefore think it should be kept as loose as possible even though the
integration point could be lost.

Just my $0.02.

-jkk

-- 
		"Be normal, and the crowd will accept you. 
	Be deranged, and they will make you their leader." --Titus

---

From: [email-masked] (Mark C Smith)
Date: Thu, 22 Mar 2001 14:32:27 -0500

To me, your point is just a reminder that we do not fully understand the
ramifications of the proposed change.  Of course other variants of the
basic algorithm are possible as well, such as:

a) Scan from the right of the DN until you find the first dc component.
b) Consume the dc components to form the DNS name, stopping when you see
a non-dc component.

In other words, don't use ALL of the dc components but just the most
significant set of adjacent ones.  If the above algorithm is followed,
each of these DNs would map to an example.com SRV lookup:

dc=consumer,dc=com,ou=domains,ou=consumer,ou=customers,dc=example,dc=com
uid=bjensen,dc=example,dc=com,o=Example Industries,c=US.
dc=bogus,uid=bjensen,dc=example,dc=com,o=Example Industries,c=US.

But again, what new issues will arise that we have not yet considered? 
And what flexibility have we given up that someone will want?

I don't strongly disagree with any of the points made so far, but I am
skeptical about one thing:  the value of making any changes to the
current algorithm.  It seems unlikely to me that PKI deployers will
really issue certificates that contain DNs like this:

    uid=bjensen,ou=accounting,dc=example,dc=com,o=Example
Industries,c=US

Given the fact that they will need to issue new certs, why wouldn't they
just add another directory naming context and use DNs like this:

    uid=bjensen,ou=accounting,dc=example,dc=com

They will want to make that transition someday anyway.  No?

-Mark Smith
 Netscape

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 22 Mar 2001 12:05:24 -0800

At 02:32 PM 3/22/2001 -0500, Mark C Smith wrote:
>ramifications of the proposed change.

I agree!

>Of course other variants of the

This has always been my favorite mechanism.

> > change would have a significant impact upon their current use

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

---

From: Michael Ströder <[email-masked]>
Date: Thu, 22 Mar 2001 21:59:15 +0100

> ramifications of the proposed change.

I'm glad that I'm not the only one who is skeptical.

Ciao, Michael.

---

From: Michael Helm <[email-masked]>
Date: Thu, 22 Mar 2001 14:11:40 -0800

>     uid=bjensen,ou=accounting,dc=example,dc=com,o=Example

See subject "alternate "dc" naming conventions".
The Grid community is very close to this and some
similar variations, if it hasn't happened already.
I think it is very likely something like
cn=host.lab.org,dc=lab,dc=org,o=grid or
cn=host.lab.org,dc=lab,dc=org,o=grid,c=us  & other variants
will be in common use.

> They will want to make that transition someday anyway.  No?

It's not clear ... it may still be early enough in the policy
development period to fix this in the Grid.