Subject: RE: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's p roposal for using DNS to locate LDAP servers)

From: "Slone, Skip" <[email-masked]>
Date: Mon, 26 Mar 2001 08:33:00 -0500

I expect to have an I-D on this ready to go in a few days (depending on the
number of outside interrupts).  In the meantime, I'll try to address the
"what happened to the discussion on SRV records?" question:

If you already know the applicable domain name (as is the case when there
are dc RDNs sprinkled throughout the DN), you can do a SRV record look-up
directly.  However, if you have a DN with no clues regarding the applicable
domain name (as is the case with "traditional" X.521-style names), where do
you go to query for SRV records?  The concept of the AVA record is to be
applied BEFORE doing the SRV record lookup -- it provides a mechanism for
determining the domain name. Once you have the domain name, then the SRV
record approach works just fine.  Until then, you're dead in the water with
an unresolvable DN.

As for Kurt's comment regarding "insurmountable technical, operational, and
administrative issues," can we take these one at a time?  That is, let's
look at the technical issues first. What are they? Can they be adequately
adequately addressed or are they truly "insurmountable?"  I believe that the
technical issues can be dealt with.  If we can get past that hurdle, we can
THEN look at administrative and operational issues.  Remember, there was a
time when today's concept of how we manage .com would be considered utterly
absurd.  Let's not discount things too quickly -- there is a real world
requirement for this...

 -- Skip

-----Original Message-----
From: Bruce Greenblatt [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 12:57 AM
To: [email-masked]
Subject: Re: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's
proposal for using DNS to locate LDAP servers)

At 04:08 PM 3/24/2001 -0800, you wrote:
>Frankly, I believe the approach is not viable due to numerous
>insurmountable technical, operational, and administrative
>issues of adding such RRs to the "." and TLDs.

I concur with Kurt.  I don't see the AVA resource record being added to the 
root or all top level domains.  I note that early in the document, it says: 
"We believe name resolution is a critical enabler to the ability to build 
cooperative directory systems. We see benefit in alignment work that 
addresses the following: ...
  -* allowing distributed name resolution to extend through X.500, LDAP, 
and DNS (most notably the SRV record) namespaces without the user having to 
know or care"

Yet later on, in Annex B where it talks about name resolution using DNS, 
the SRV record is not used or mentioned.  What happened?

>Kurt
>
>At 01:36 PM 3/22/01 -0500, Slone, Skip wrote:
> >As promised in the LDAPext meeting earlier this week, I am sending a set
of
> >links to the X.500 group's working document that outlines the group's
> >proposal for extending DNS to facilitate the location of LDAP servers
based
> >on the DN.  The document is the LDAP/X.500 alignment draft. The
background
> >concepts are presented in Annex A, and the proposal itself is found in
Annex
> >B.  The links below are to the Word and PDF versions of this WD,
> >respectively:
> >
>
>ftp://ftp.bull.com/pub/OSIdirectory/Geneva2001/TD%20Output/TD3044R1LDAPalig
n
> >ment2ndWD.doc
> >
>
>ftp://ftp.bull.com/pub/OSIdirectory/Geneva2001/TD%20Output/TD3044R1LDAPalig
n
> >ment2ndWD.pdf
> > -- Skip Slone

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Mar 2001 07:54:05 -0800

My suggestion would be to use some approach which didn't rely on information
at the root and TLDs.  One approach would be to place mapping information
under some other domain.  You likely can avoid having to introduce new
RRs.  Off the cuff, one could have a domain like "o-example.c-us.x.itu.int"
hold location information for "o=example,c=us".

I think you need to look at technical, operational, and administrative issues
concurrently.  It's pointless to spend time on a technical approach which
cannot be deployed for operational and administrative reasons.

 -- Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 Mar 2001 07:32:05 -0800

At 09:51 AM 3/27/01 -0500, Slone, Skip wrote:
>Kurt,
>
>A couple comments related to your most recent response...
>
>First, if we back up and look at the requirements (which haven't yet been
>fully articulated), we see a need to do lossless (or at least nearly
>lossless) mapping between RDNs and FQDNs. Even if we limit the set of RDNs
>we consider to, say, the subset that PKIX requires (not even the larger
>subset permitted by PKIX), we find that the currently defined RR types
>(namely A and CNAME) are insufficient, since those RRs are limited to the
>character set specified by RFC 1123.  (For reference, that set includes "A"
>through "Z", "a" through "z", "0" through "9" and the hyphen. Periods are
>permitted, but are treated as label separators.) Looking at what we might
>choose to call "reasonably well-constructed RDNs," I think it's reasonable
>to assume we will need, at a minimum, a character set that also permits
>apostrophes, periods, commas, and spaces. In order to do lossless mapping,
>it is necessary to EITHER define an RR type with a compatible character set
>OR define an escaping mechanism.  Since I'm hard pressed to even find a
>reasonable escape character in the RFC 1123 set, I'm led to the conclusion
>that it would be simpler to define a new RR type for this purpose.

Look at IDNa work.  I would suspect one of the numerous ascii
compatible encodings which likely could be used... likely base32
is usable.

>Second, regarding where this thing gets rooted, I again look at the
>requirements. One such requirement is the availability of a suitable (i.e.,
>scalable, distributable) registration infrastructure.  By this I mean a
>(mostly non-technical) set of supporting structures including registration
>authorities, processes, rules, administrators, and so on. Given that we need
>such an infrastructure, we have a choice between (1) defining a new
>infrastructure and (2) using an existing one.  If we define a new one, we
>can either define a new one rooted somewhere under the DNS structure (as
>you've suggested), or we can define one external to DNS (as X.500 suggested
>back in 1988).  Since the X.500 suggestion never took root (pardon the pun!)
>in the past thirteen years, I'm led to the conclusion that we're not likely
>to succeed if we go down that path.  That leaves option 2 (using an existing
>infrastructure) as the most viable. The only existing registration
>infrastructure that I know of is the TLD-rooted DNS registration
>infrastructure.  

I think you really need to look at this from who "owns" what
information.  ITU "owns" the X.500 root.  They should control
the DNS mapping "root" which maintains glue for the X.500. They should
be able to delegate control to RDNs under the root to appropriate
parties.  For example, they should be able to delegate the 
approrpriate subdomain under the DNS mapping root to ANSI for
"c=US".  ANSI should be able to delegate the appropriate subdomain
for "o=Example,c=US" to whoever "owns" it.

Your root approach doesn't delegate authority properly.  It
delegates control to add top level RDNs to ICANN, and second
(and third and fourth?) level RDNs to the TLD registries.  This
is, I think, not the appropriate delegation model.  These
registries have zero clue on how to ensure proper assignment.

I believe an approach similar to what I offer can be delegate
the control to the vested parties, the same parties which
already have infrastructure to register X.500 context prefixes.

Now, if you are actually try to deal with unregistered X.500
context prefixes, I think you would have a VERY hard time
getting the IESG, IAB, ICANN to take on yet another registration
rat hole.

>Having said that,
>I'll say that I don't think LDAPext is the appropriate forum for discussing
>whether the TLD operators are likely to take on the task.

You should discuss introduction of new RR and other DNS extensions
in DNSext.

You should discuss introduction of operational considerations in
DNSops.

Kurt

---

From: "Slone, Skip" <[email-masked]>
Date: Thu, 29 Mar 2001 15:01:02 -0500

Kurt,

Sorry to go silent for the last couple days -- I've been in all-day meetings
all week.  You've raised some interesting points that I think will be
valuable for the discussion of issues.  I'll try to incorporate those
thoughts into the I-D to stimulate discussion.

 -- Skip

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, March 27, 2001 10:32 AM
To: Slone, Skip
Cc: 'Bruce Greenblatt'; [email-masked]
Subject: RE: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's
p roposal for using DNS to locate LDAP servers)

Kurt