[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] RE: draft-ietf-ldapext-locate
I'm goin to respond to small numbers of sections at a time...
Comments inline.
> -----Original Message-----
> From: Patrik Fältström [mailto:paf@cisco.com]
> Sent: Tuesday, August 13, 2002 2:54 AM
> To: Michael Armijo; Paul Leach; Levon Esibov; rlmorgan@washington.edu
> Cc: ldapext@ietf.org; Ned Freed; ietf-ldap@paf.se
> 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=smith@example.com, 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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext