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

["Slone, Skip" <skip.slone@lmco.com>]

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.

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 know that getting the TLD administrators to take on the task will be a
steep uphill climb, but I also recognize that much of the global TLD
infrastructure has already been commercialized. This means that if there's a
suitable business case (such as one founded on increasing opportunities for
TLD registration authorities to charge new fees), there is a reasonable
chance of pursuading them to give it due consideration.  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.  That's why I'd
like to focus on the technical issues in this forum.  That is, what are
LDAPext's requirements in this space, and does this approach provide a
satisfactory technical solution to those requirements.  The administrative
and operational issues discussion should really be held in a forum populated
by DNS experts.

Having said all that, I'll fade into the background and continue to develop
the I-D so we can really formalize this discussion.

 -- Skip


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Monday, March 26, 2001 10:54 AM
To: Slone, Skip
Cc: 'Bruce Greenblatt'; ietf-ldapext@netscape.com
Subject: RE: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's
p roposal for using DNS to locate LDAP servers)


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

At 08:33 AM 3/26/01 -0500, Slone, Skip wrote:
>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:bgreenblatt@directory-applications.com]
>Sent: Sunday, March 25, 2001 12:57 AM
>To: ietf-ldapext@netscape.com
>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/TD3044R1LDAPali
g
>n
>> >ment2ndWD.doc
>> >
>>
>>ftp://ftp.bull.com/pub/OSIdirectory/Geneva2001/TD%20Output/TD3044R1LDAPali
g
>n
>> >ment2ndWD.pdf
>> >
>> > -- Skip Slone
>
>==============================================
>Bruce Greenblatt, Ph. D.
>Directory Tools and Application Services, Inc.
>http://www.directory-applications.com