Subject: Re: alternate "dc" naming conventions

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Jul 2001 23:06:27 -0700

Applogies for the delayed response...

> 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.
> I think it is in our interest to ask that the locator draft
> be extended to include some other well-structured cases
> beyond the current right-most dc= list.  If that's done, then
> our standards process can reference the IETF's work & hopefully
> interoperate.   Alternatively, I can produce a knock-off of the
> current locator that would describe our requirement.  (How
> useful would this be?)

As there are so many different naming conventions, it is
unlikely that one mechanism will satisfy the needs of all.

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

> The DIT in the directory software supporting Grids
> (see http://www.gridforum.org and www.globus.org)
> has a number of conventions in its history.  The original one,
> which still exists in some large deployments, looked like
> this:
>
> (grid dn components), o=Your Name Here, o=Globus, C=us
> that is, a non-conformant X.500 style of naming.

Assuming O=Globus,C=US is properly registered, the services
can be located using <draft-zeilenga-ldap-x500-locate-01.txt>.

> The current implementation supports names like this:
> (grid components), dc=biglab, dc=org, o=grid

Provding location services for unmanaged name spaces
(such as o=grid) is not manageable.

> The planned implementation wants dn's to look like this:
> (grid components), dc=biguni, dc=edu, vo=Internet, o=Grid
> and
> (grid components), vo=MyOrg, o=Grid

> The assumption here is that whoever is querying the directory
> service (whatever directory service) somehow "knows" where the
> server that supports the suffix "vo=MyOrg, o=Grid" is ab initio.
>
> But no such asssumption about "dc=biguni, dc=edu, vo=Internet, o=Grid"
> is made for the benefit of this server.  Ideally the server deals with
> this by a referral.   The nature of the software supporting the grid
> architecture requires a large number of referrals as the mesh grows,
> and maintenance of these records individually won't scale well.
> Thus the utility of DNS SRV.

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.

> It's likely that Grid certificate authorities will issue certificates
> with these kinds of names in the near future.  The security services
> are evolving requirements for directory, and probably also will
> have to interoperate with existing PKI's that may have adopted
> X.500-type naming conventions such as Tim Polk described.

For those using X.500-type naming conventions, location should
be based on that naming, not DCs placed subordinate to the
naming context.  (This is the crux of the problem, folks want
to abuse DC naming to solve a problem which is better solved
by providing a separate mechanism).

> (NB: I would appreciate any comments on this, but please
> separate your comments & reaction on the architecture from those  related
> to the request to extend  the locator draft :^)  Thanks, ==mwh

Sorry, I kind of mixed them up a bit...

---

From: Michael Helm <[email-masked]>
Date: Thu, 05 Jul 2001 10:21:35 -0700

Thanks for responding & discussing the issues.

> will lead to requiring multiple DNS lookups to locate services

Well of course I'm not asking for "all" or "multiple" dc lookups.
They're altogether in one sequence.  It's just the order
of rdn's is different than the locator draft's. 

> can be located using <draft-zeilenga-ldap-x500-locate-01.txt>.

Has anyone (ITU?) actually implemented that? 
(x500.in-addr.arpa)
In the United States at least we would have the additional problem
that no one really owns or manages c=us (unless there
is some recent change), but it's  not clear to me how
that problem maps to that draft SRV  deploymen in 
any event. 

> or for automating knowledge information management in the

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?  One part
of the dilemma is, the need to distinguish the grid services from
any other ldap services, so that you can assemble a reasonable
map of what's available in some well-known server or assemble a reasonable
map  of what's available from an uninformed and unconfigured
grid client; and the other part is the overlap that these services will have
with whatever else might be in dc=biguni,dc=edu (your white pages, 
or your AD domain; or, at another level, the management of these
resource directory servers).

I think what may happen, instead of  dealing with DNS SRV or the
above issues, is an altogether different kind of registration mechanism
will be developed.  

If anyone is interested in helping us with this issue let me know.
Thanks, ==mwh

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Jul 2001 11:42:54 -0700

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

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

>Has anyone (ITU?) actually implemented that? 

No.

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

---

From: Michael Helm <[email-masked]>
Date: Thu, 05 Jul 2001 12:55:30 -0700

> to left) adjacent set of RDN containing DCs.  This is interesting,

Yes

> would have to share the same SRV RRs.

Understood. 

Is there any reason to think this might not be a problem in
other infrastructures anyway (eg the Active Directory - based
W2K domain)?  Suppose a simpler example: one
directory that manages authentication, with basename ou=users,
dc=es,dc=net, & another that manages a phone book, basename
ou=staff,dc=es,dc=net; these two are only loosely coordinated
(or not).
Sure, the clients of these servers could get confused.
They would have to be smart enough to rotor thru the 
DNS SRV RR's they get back (unlikely).

> client at to hold either the entry or knowledge information to

Is it "requires"?  I'm hoping for that actually (this is my 
personal agenda, not nec. the grid community's), that the
grid directories would blend in to other available directories;
this is because nothing currently requires separating grid directories
from others, & separation (in the long run) places
an operational burden on the wrong people in my opinion.
But I think current trends suggest this "separate management" scenario
is what will happen as a side effect of a separate discovery
mechanism.

In the whitepages/auth dbms example above I would hope
that the two servers would give out knowledge references to
each other; I could use their DNS SRV entries and a little
indexing service to make sure that happened (convergence).
But would everyone want that?

---

From: Michael Ströder <[email-masked]>
Date: Thu, 05 Jul 2001 22:11:00 +0200

> DNS SRV RR's they get back (unlikely).

No, the LDAP clients will have to follow referrals. Multiple SRV RRs
should always point to servers holding the same dc-style naming
context. If this naming context is partitioned the server has to
direct the client to the right server by sending a referral.

One open question for me is if a client is allowed to walk upwards
the DNS tree to search for SRV RRs.

E.g. when requesting dc=subdomain,dc=es,dc=net a client might try to
lookup 

_ldap._tcp.subdomain.es.net

and if that failed go ahead with looking up 

_ldap._tcp.es.net

although the client is still solely interested in getting
dc=subdomain,dc=es,dc=net.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Jul 2001 14:08:48 -0700

>DNS SRV RR's they get back (unlikely).

No.  In the absence of knowledge information in the servers
holding these two contexts, the client would either
        1) success
        2) noSuchObject

both are definitive answers.

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
gets either
        1) success
        2) referral

and things work.

I guess my concerns are restricted to a subcase of the case
I described.

When there are two DNs:
        ou=foo,dc=example,dc=com
        ou=bar,dc=example,dc=com

which may likely held on two different servers and it is
generally expected (and required for "locate" I-D to work)
that the server holding "dc=example,dc=com" holds knowledge
information regarding its subordinates.  To avoid the referral,
dc should be used for the subordinate contexts (which allows
for independent SRVs).

However, if one has two DNs:
        ou=foo,dc=example,dc=com,o=X
        ou=bar,dc=example,dc=com,o=Y

which are likely held on two different servers, it generally NOT
expected that there be a superior service holding knowledge
information for its subordinates.  It should not be assumed
from these entries related in any particular way to entries
at:
        dc=example,dc=com

or to domain example.com.

>Is it "requires"?

IMO, yes.  Because the knowledge cannot be held in DNS (using
dc-based DNS SRV RRs), it needs be held in LDAP.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 05 Jul 2001 14:33:28 -0700

>the DNS tree to search for SRV RRs.

Walking the tree (up or down) would cause significant load
upon TLDs and root DNS servers and hence MUST be disallowed.

Kurt

---

From: Michael Helm <[email-masked]>
Date: Tue, 10 Jul 2001 21:04:06 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 15 Jul 2001 07:48:03 -0700

>with dc=es,dc=net as the (appropriate)  part of its base name,

Yes.  The _ldap._tcp.es.net hold SRV location information for
"dc=es,dc=net".  There may objects subordinate to "dc=es,dc=net"
which are locatable using same SRV information or locatable
via LDAP referrals provided by the services referenced in
the SRV information.

> think it's that explicit in the locator draft.  Should it be?

Yes.

>(Same applies to forbidding  chasing dns search upwards)

Any locate approach which requires the DNS tree to be walked
(in either direction) will negatively impact the operation
of DNS root, TLD, SLD, and ... servers and should be avoided.

>stupid server that gives out bad or incomplete information).

No solution works well with inappropriately configured or in
poor implementations... just like DNS NS RRs and LDAP "ref"
values.

>I would be

Exhausting a long list of RRs would be expensive.  Each of
the listed services should be "equally capable".

>But maybe that's undesirable behavior in some other context.

Yes, this would require a lot of work in deployments who want to
use multiple RRs to list available replicas.

>_ldap._tcp.my.domain query.

That is, this is approach is for locating entries named using
RFC 2047 (and entries subordinate to these).  Yes, this approach
has limited applicability.  Other approaches (such as those
described by Skip and myself) can be used for other applications.

>How or whether the other servers

I'd guess that would likely depends on the approach.