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

From: Patrik Fältström <[email-masked]>
Date: Tue, 13 Aug 2002 05:53:55 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 Aug 2002 21:36:05 -0700

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

I disagree.   I also note that this issue has been discussed
repeatedly on the list and, IMO, consensus has been that the
current specification is appropriately restrictive.

>        values extend to the left. If an RDN cannot be converted,

so would:
        DC=less,DC=MIT,DC=MIT,OU=domains,O=example,c=DE

but one should not reasonably expect servers listed at
_ldap._tcp.less.mit.edu to have knowledge of this DN.  A
user attempting to access DC=less,DC=MIT,DC=MIT,OU=domains,O=example,c=DE
would be astonished if their client connected to servers
listed _ldap._tcp.less.mit.edu.

>which is not the desired result.

This IS the desired result.  Domain components have two common
uses are used together (or separately).  1) naming prefixes,
2) naming of objects associated with domain.  For example,
consider the DN.
        dc=example,dc=com,ou=domains,dc=example,dc=net

This is, the organization owning example.net has an entry
holding information about the domain example.com.  The mapping
suggested by Jeff would require the owner of example.net
maintain DNS SRV records associated with com.example.net
and example.com.example.net.  This is not desirable.

Consider the DN, dc=example,dc=com,ou=domains,o=ISP,c=UK where
the entry represents services (not necessarily DNS services)
which the ISP provides domain name example.com.  It would
be reasonable to presume _ldap._tcp.example.com referred to the
LDAP server holding "dc=example,dc=com,ou=domains,o=ISP,c=UK".
This is not desirable.

Or, more to the point, it is only reasonable to assume that
that _ldap._tcp.example.com refers to server with knowledge
of dc=example,dc=com.

>certificates to be re-issued.

Converting from existing naming to DC naming doesn't require
this flexibility.  Switching from one naming practice to
another should be done directly.  That is, switching from
  cn=Jeffrey Schiller,ou=LEES Laboratory,o=MIT (or whatever)
to
  cn=Jeffrey Schiller,dc=lees,dc=mit,dc=edu

should be done without creating intermediate naming practices,
such as:
  cn=Jeffrey Schiller,ou=LEES Laboratory,dc=lees,o=MIT,dc=mit,dc=edu

Intermediate naming practices are evil and should be avoided.

>It will also permit us to create DIT's

No.  They would establish a server with knowledge of
"dc=labx,dc=mit,dc=edu".

They could treat "ou=Lab for X,o=MIT,c=US" and
"ou=Lab for X,o=MIT,c=US" as independent subtrees
or relate these subtrees using aliases or referrals.

>flexibility they would be SOL until MIT redid its entire DIT to

No.  See above.

>LDAP client check every DN it sees for DC fields and if it finds them use

It is intended to be a general mechanism for locating LDAP servers
having knowledge of directory objects associated with a DN in
absence of location information.  This DN may have been provided
to the application via LDAP or other means.  If the DN was provided
with location information, such as a LDAP URL with host part,
that information should be used.  Howeer, where the DN is provided
without any location information, this mechanism provides a means,
for a subset of DNs (those using RFC 2247 naming), for the
application to locate servers with knowledge of the DN.

This application may be an LDAP client or server.  OpenLDAP's server,
for example, can use this mechanism to generate referrals to clients
requesting DN which it otherwise has no knowledge of.

>name and how to use a DNS name to locate a corresponding LDAP

I argue that the document specifies one process, to locate LDAP
servers with knowledge of a particular DN, which has two steps.

>good idea: Isn't the ability to use SRV records to locate more generally

I don't believe this document restricts how DNS SRV records
can be used.  It also doesn't restrict construction of additional
processes for locating LDAP servers with knowledge of a particular
DN.  In fact, draft-zeilenga-ldap-x500-locate suggests a process
for DNs using geo-political naming.

Additionally, DNS SRVs could be used to answer questions such
as "Are there LDAP servers associated with this domain?".
Of course, this would be followed by, "What DN is used by
the owner of this domain for their objects?".  If a listed
server provides 100s of namingContext, which one is the right one?
Luckily, we have RFC 2247 which says how the owner of the
domain should name objects.

>answer should be part of the specification.
>

It is a bad idea.  A short explanation would be appropriate.

>"SRV". Unfortunately, I don't think the acronym expands into anything

SRV is not an abbreviation, but IANA-registered DNS RR Type.
http://www.iana.org/assignments/dns-parameters

>I have three concerns here:

see above.

Kurt

---

From: [email-masked]
Date: Thu, 15 Aug 2002 09:57:16 -0700 (PDT)

I'm going to take the liberty of responding directly here.

> requesting DN which it otherwise has no knowledge of.

This is precisely the sort of thing I'm afraid of. OpenLDAP does this but I
doubt SunOne Directory Server (to pick a specific example) does. And given this
document doesn't spell out when this is supposed to be used you cannot claim
that the issue is Sun's failure to implement this standard.

THe opposite situation is also a concern. Suppose I have an LDAP library that
implements this unconditionally and I try to use that library in a situation
where I don't want it to happen. (Uses of DC DNs that don't expect this to
happen do exist, you know; the product I work on in my day job is an example of
this.)

This can be fixed in a bunch of ways. The most obvious one would be to say that
this should be implemented in the following places and whether or not it is
used needs to be configurable.

> as "Are there LDAP servers associated with this domain?".

This is the separate case I was thinking of.

> domain should name objects.

Then you should make it clear that this document specifies a single
process, and that it does not specify a process for locating LDAP 
servers for a given domain.

				Ned

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Aug 2002 11:30:36 -0700

>that the issue is Sun's failure to implement this standard.

OpenLDAP supports a particular experimental service, described
in RFC 3088, which uses this location mechanism.

What I think you asking us to clarify is when should this mechanism
be implemented/used.  My answer to this is, the mechanism should be
implemented/used as detailed in the technical specification for the application (or protocol) requiring its use.

That is, I agree that implementations should not use this mechanism
unless they implement a particular technical specification which
prescribes use of the mechanism.  This should be clarified.

>used needs to be configurable.

I don't the IETF should attempt to draw lines of what belongs in
the application-specific code versus a library implementing an API.
Requirements should be placed upon the "implementation".  It is
implementor's choice on wether to use libraries or not, which
libraries to use, etc..  But regardless of the choices made, the
resulting implementation needs to meet all implementation
requirements.

Now, in a technical specification for an LDAP API, that specification
should clearly state where the location is to be used in
implemented by providers of the API.

---

From: [email-masked]
Date: Thu, 15 Aug 2002 12:32:55 -0700 (PDT)

> be implemented/used.

Exactly.

>  My answer to this is, the mechanism should be

That's a very reasonable answer.

> prescribes use of the mechanism.  This should be clarified.

Good. The addresses the issue as far as I'm concerned.

				Ned