[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: alternate "dc" naming conventions

At 10:21 AM 7/5/2001, Michael Helm wrote:
>Thanks for responding & discussing the issues.
>
>"Kurt D. Zeilenga" writes:
>> > I'm working with a directory implementation that needs something
>> > like DNS SRV records and the locater draft to scale.  But the
>> > current locater  draft doesn't fit well with this implementation.
>>
>> The current locate mechanism was specifically designed for
>> those using RFC 2047 naming.  It's simple and doesn't require
>> significant operational overhead.  (Supporting all dc's
>> will lead to requiring multiple DNS lookups to locate services
>> for a DN).
>
>Well of course I'm not asking for "all" or "multiple" dc lookups.

I thought your approach was, like the PKI suggestion, to use
all the DC RDNs contained in the DN.

>They're altogether in one sequence.  It's just the order
>of rdn's is different than the locator draft's. 

So, your approach is to use the first (when looking right
to left) adjacent set of RDN containing DCs.  This is interesting,
but I'd still be concerned that DNs held in different servers
would have to share the same SRV RRs.

>> Assuming O=Globus,C=US is properly registered, the services
>> can be located using <draft-zeilenga-ldap-x500-locate-01.txt>.
>
>Has anyone (ITU?) actually implemented that? 

No.

>> Problem in using one mechanism is that "dc=biguni,dc=edu" and
>> "dc=biguni,dc=edu,vo=Internet,o=Grid" may be managed by
>> separate entities or managed by one entity on different sets
>> of servers.  I suggest using a private mechanism for locating
>> such DNs (using different RRs than the standard mechanism)
>> or for automating knowledge information management in the
>> superior service.
>
>That's quite a good objection and one that has been raised by
>the architects of this grid service.
>
>I took for an example windows 2000 AD, where you have a complex
>NOS - type service taking over that name space (dc=biguni, dc=edu).
>(Maybe "horning in" is a better way of putting it than taking over.)
>
>Isn't co-existence going to require looking in the DSE and looking
>in the DIT anyway to see if you're in the right place?

I believe co-existence requires the server which SRV points the
client at to hold either the entry or knowledge information to
where the entry is held.