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

From: "Paul Leach" <[email-masked]>
Date: Tue, 13 Aug 2002 14:50:56 -0700

I'm goin to respond to small numbers of sections at a time...

Comments inline.

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]] 
> Sent: Tuesday, August 13, 2002 2:54 AM
> To: Michael Armijo; Paul Leach; Levon Esibov; [email-masked]
> Cc: [email-masked]; Ned Freed; [email-masked]
> Subject: 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.

I don't feel like I really know the considerations. That seems like it's a pretty good reason to make it a SHOULD NOT, I would think. But we couldn't think a good reason to disallow it, either. One I can think of is to avoid demands on the DNS service close to the top of the DNS naming hierarchy. That would suggest not looking up SRV records for "_ldap._tcp.com" or "_ldap._tcp.co.uk" -- so the depth may vary. Within an organization, DNS lookup traffic may or may not be a major factor.

> 
> -------
> 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?)

I would say that this is currently the only standardized way to find the authoritative LDAP server for a DN that contains DC components. And that it is not meant to disallow non-authoritative servers, proxies, or caching at the client or at non-authoritative servers. However, in the absence of any other proposals for how to find an LDAP server (authoritative or not) given a DN that contains DC components, I find it rather difficult to say when this should be used as opposed to some alternative.

> 
> (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.

It isn't _the_ naming convention for the Internet. It isn't even _the_ naming convention for LDAP. If you want to think of it this way, I guess one could say that it is _the_ convention for LDAP DNs that contain DC components, but not for ones that don't. Thus, for example, we deliberately say nothing at all about DNs such as "CN=John Smith, OU=Marketng, O=ExampleCorp, C=US" or (say) "CN=John Smith, E=[email-masked], O=ExampleCorp,C=US" or "CN=John Smith, S=ldap.example.com, O=ExampleCorp, C=US" -- the latter two being examples intended to suggest other ways of deducing the DNS name of an LDAP server from the DN. We deliberately tried to restrict the set of DNs that the convention applied to so as to not preclude other conventions from being developed.

Paul

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 14 Aug 2002 15:11:39 -0400

--On 2002-08-13 14.50 -0700 Paul Leach <[email-masked]> wrote:

> It isn't _the_ naming convention for the Internet. It isn't even _the_
> naming convention for LDAP. If you want to think of it this way, I guess
> one could say that it is _the_ convention for LDAP DNs that contain DC
> components, but not for ones that don't.

Good, I am happy with that, but, this probably have to be spelled out
explicitly.

Example of a problem:

Take the domain name issues, and the project which try to have LDAP access
to Whois data.

We have whois data both at the registry and the registar about a domain
name. In the project, both records, the referral thing in the registry and
the actual whois info at the registrar use the same DN, and that is exactly
the dc components of the domain name itself. And, then the user himself
probably want/will have an LDAP server himself for the same DN.

Example, my domain paf.se with "dc=paf, dc=se" might exists on three
different locations.

The registry, the registrar and myself.

    paf

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 15 Aug 2002 08:46:55 -0700

>The registry, the registrar and myself.

Well, the owner of the domain paf.se owns dc=paf,dc=se.  The
others (the registry and registrar) have hijacking namespace.
Luckily, you are the source of authority for _ldap._tcp.paf.se.

Kurt

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 15 Aug 2002 08:45:57 -0700 (PDT)

On Wed, 14 Aug 2002, [ISO-8859-1] Patrik Fältström wrote:

> Example of a problem:
>
> Take the domain name issues, and the project which try to have LDAP
> access to Whois data.
>
> name. In the project, both records, the referral thing in the registry
> and the actual whois info at the registrar use the same DN, and that is
> exactly the dc components of the domain name itself. And, then the user
> himself probably want/will have an LDAP server himself for the same DN.
>

The entry naming you propose for this application raises the question of
the information model for the directory, and for this application, and
whether they are consistent.

The traditional information model for the X.500 directory is that a DN
names a distinct entry, and that entry provides the same information
regardless of the physical server it resides on; this is the same
information model as the DNS.  In practice, due to the lack of a global
view of an X.500 DIT, it is common for different DSAs to contain entries
with identical DNs but which contain different information; this puts the
burden on the client (or application) to know the difference between the
entries held by different servers.

If the Whois application you describe intends to have exactly the same
info in each of the DC-named entries, regardless of whether it is held by
the registry, the registrar, or the domain name holder, then its
requirements are perfectly well met by the draft-ldapext-locate scheme.
The SRV record would contain pointers to each of the locations, and it
wouldn't matter which the client went to.

If, in this application, the information provided by the different servers
for the same DN is different, then there's a problem.  Either you've
designed a case where SRV-record lookup won't work, so it's up to your
application to figure out how to map from names to servers, and to
distinguish the different kinds of servers; or you need to change your
entry naming to reflect the fact that the logical entry held by the
different servers about the same DNS name is a different entry.

So which is it?

 - RL "Bob"