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

Re: alternate "dc" naming conventions



"Kurt D. Zeilenga" writes:
> In this setup, which is quite common BTW, the superior service
> needs to hold a subordinate reference and the subordinate
> service needs to hold a superior reference.  Then the client

I think what are you saying is, anything that is registered 
in dns as
_ldap._tcp.es.net
  like
        w2kdomain.es.net
        whitepages.es.net
        grid-yellowpages.es.net

must be prepared to provide service or referrals for anything
with dc=es,dc=net as the (appropriate)  part of its base name,
is that right?

(If not) please straighten me out!

(If so)
I didn't realize this level of coherence  was required ... I don't
 think it's that explicit in the locator draft.  Should it be?
(Same applies to forbidding  chasing dns search upwards)

Something about this level of coherence makes me nervous, but I'm
not exactly sure what.   I don't think I expect it to work perfectly
(suppose one of the _ldap._tcp.es.net rr's points to a 
stupid server that gives out bad or incomplete information).  I would be
inclined to  code an ldap client to look up all the servers
it gets from the  dns lookup and exhaust the list of servers in case the 
previous ones didn't have the base name it was looking for.  
But maybe that's undesirable behavior in some other context.

Leaving aside the dangling o=grid rdn, it seems like one
appropriate  way  to use dns srv for grid directory servers
is to register a referral server that could deal with the
restriction above  &  that clients could find by the usual
_ldap._tcp.my.domain query.  How or whether the other servers
would be registered in dns is tbd.  They probably should be
registered, if at all, as some other service or services.