RE: [ldapext] draft-ietf-ldapext-locate

["Alexis Bor" <alexis.bor@directoryworks.com>]

I proved to myself and others (while I was at Boeing doing R&D work in
Directory) back in 1992 that putting any meaning into a DN is not a good
practice.  We took the example of a company of 100,000 and looked at the
different approaches for DN's - Geographic, Political, Hybrid and
others.  

It became clear that it would be a maintenance headache and cause lots
of stress on the overall infrastructure.  It was very hard to convince
most people for a long time until some work that Jeff Hodges did at
Stanford got a lot of attention in the late 90's.

A real hard piece of work to put forward is a best practices document.
The number of opinions will typically exceed the number of people
working on the document.  What we learned in the mid 90's was that such
a document evolves faster than the review cycle (part of an EMA effort
to write a white paper on directory best practices), making it out of
date before you even finish the review of it.  However, with all of the
experience that everyone is getting, it may be worth resurrecting the
idea again.  

Perhaps an industry group can step up to the challenge - any takers?

-- Alexis

Alexis Bor
Directory Works, Inc.
www.directoryworks.com


-----Original Message-----
From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org] On Behalf
Of Liben, Michael (GTS)
Sent: Tuesday, August 13, 2002 5:32 PM
To: 'Patrik Fältström'
Cc: ldapext@ietf.org
Subject: RE: [ldapext] draft-ietf-ldapext-locate

In general, divining any meaning from a distinguished name is not good
practice (my $.02). The implications are that your app will likely
break. The SHOULD NOT allows you impart meaning to your
distinguished name if you so choose. A MUST NOT would be an absolute
prohibition.



-----Original Message-----
From: Patrik Fältström [mailto:paf@cisco.com] 
Sent: Tuesday, August 13, 2002 5:54 AM
To: micharm@microsoft.com; paulle@microsoft.com; levone@microsoft.com;
rlmorgan@washington.edu
Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se
Subject: [ldapext] draft-ietf-ldapext-locate

Comments from the IESG:
-------
The document says:
      If there are no
      matching SRV records available for the converted DN the client
SHOULD
      NOT attempt to 'walk the tree' by removing the least significant
      portion of the constructed fully qualified domain name.

The meaning of "SHOULD NOT" is "don't do this unless you understand the
implications". Well, I don't know where to look to understand the
implications.
Thus I think it would be useful to either make it a MUST NOT, or explain
something about the implications of using shorter labels.

Alternatively specify SHOULD NOT do this in general, but MUST NOT ever
use this with just one label (i.e. MUST NOT look for _ldap._tcp.<TLD>)
or something similar.

-------
The document is unclear (see next note) on:

(a) When this is to be used (only when not having the foggiest clue
where a
record with a specific DN is, or every time a record is to be accessed?)

(b) How to handle the case when one have a DN which have both dc and
non-dc
components. Example of this is when two records stored on two different
servers share the same dc components. IF those records per definition
(of
this document) have to be stored on the same server, or referrals have
to
be stored on them to point to the other, then this document has a scope
which is larger than at first glance. I.e. part from stating how to
locate
a record using DNS, it also has an implicit result that DC is _the_
naming
convention for the Internet. Please explain.

-------
This document define a conversion that is over-restrictive.

        The output domain name is initially empty. The DN is processed
in
        right-to-left order (i.e., beginning with the first RDN in the
        sequence of RDNs). An RDN is able to be converted if it (1)
        consists of a single AttributeTypeAndValue; (2) the attribute
type
        is "DC"; and (3) the attribute value is non-null. If it can be
        converted, the attribute value is used as a domain name
component
        (label). The first such value becomes the rightmost (i.e., most
        significant) domain name component, and successive converted RDN
        values extend to the left. If an RDN cannot be converted,
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        processing stops. If the output domain name is empty when
        ^^^^^^^^^^^^^^^^^
        processing stops, the DN cannot be converted into a domain name.

The underscored text should be removed and replaced with text that
states the non-DC RDN's are skipped over. So for example the DN:

        cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit,
        dc=edu

Can be unambiguously translated into:

        lees.mit.edu

Yet the underscored words make this translation invalid. With the
Underscored rule in place this DN would convert to just 'mit.edu'
which is not the desired result.

The additional flexibility offered will permit us to convert existing
PKI systems to make use of this feature without requiring all
certificates to be re-issued. It will also permit us to create DIT's
that can be delegated at more points rather then requiring all
structure to be at the very top where the DC components are, prior to
any non-DC component.

For example if MIT had a DIT with a top level name of:

      o=MIT,c=US

and a subordinate lab wanted to use this document, they could have a
delegated subtree like:

      ou=Lab for X,o=MIT,c=US

and then add a DC component below this as:

      dc=labx,dc=mit,dc=edu,ou=Lab for X,o=MIT,c=US

Under my more flexible approach this would work. Without the
flexibility they would be SOL until MIT redid its entire DIT to
be:

      o=MIT,c=US,dc=mit,dc=edu

and then they would have to be jointed in as:

      o=MIT,c=US,dc=labx,dc=mit,dc=edu

Ned: I have three concerns here:

(0) It isn't clear when this approach is supposed to be used. DNs are an
        integral part of *every* LDAP operation. Is it the intent that
an
LDAP
        client check every DN it sees for DC fields and if it finds them
use
        this approach. Or is it only appropriate in specific situations?

(1) This document specifies two things: How to translate a DN to a DNS
        name and how to use a DNS name to locate a corresponding LDAP
server.
        The document seems to imply that the latter is only used when a
DNS
        name is produced by the former. I wonder if this restriction is
a
good
        idea: Isn't the ability to use SRV records to locate more
generally
        useful than this limited context?

        The answer to this may be no, but if so, the rationale for that
answer
        should be part of the specification.

(2) I don't see any provision for fallback to A records if SRV records
        don't exist. I can easily see this being a Bad Idea, if so,
there
        should be an explicit prohibition of it in the document along
with
        some explanation of why it is a bad idea.



-------
References should be split in normative and non-normative.
-------
I wonder about the reference to RFC1700, which has been obsoleted
by RFC3232, and that RFC actuallt talks about a DB that contains
the info. So How should this doc refer to that?
-------
Needs better abstract; doesn't even use the word "SRV". (and the rfc
editor will surely complain when they get it...)

Might be good to use SRV in the title as well, as opposed to just
"DNS". But this I'm less concerned about, as there are two steps, and
only the second step is SRV records.

E.g., maybe change:

            Discovering LDAP Services with DNS

To something like:

            Discovering LDAP Services with DNS SRV Resource Records

However, the rfc editor probably won't like the abbreviation
"SRV". Unfortunately, I don't think the acronym expands into anything
useful.
-------
I have three concerns here:

(0) It isn't clear when this approach is supposed to be used. DNs are an
    integral part of *every* LDAP operation. Is it the intent that an
LDAP
    client check every DN it sees for DC fields and if it finds them use
    this approach. Or is it only appropriate in specific situations?

(1) This document specifies two things: How to translate a DN to a DNS
    name and how to use a DNS name to locate a corresponding LDAP
server.
    The document seems to imply that the latter is only used when a DNS
    name is produced by the former. I wonder if this restriction is a
good
    idea: Isn't the ability to use SRV records to locate more generally
    useful than this limited context?

    The answer to this may be no, but if so, the rationale for that
answer
    should be part of the specification.

(2) I don't see any provision for fallback to A records if SRV records
    don't exist. I can easily see this being a Bad Idea, if so, there
    should be an explicit prohibition of it in the document along with
    some explanation of why it is a bad idea.





_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext