RE: A philosophical question about large directory structures
"James Benedict" <[email protected]> Fri, 23 Jul 1999 11:24:51 -0400
| Newsgroups | gmane.ietf.lsd |
|---|---|
| Message-ID | <[email protected]> |
> -----Original Message----- > From: Andrew Probert [mailto:[email protected]] > Sent: Friday, July 23, 1999 11:09 AM > To: Benedict, James [CAR:5N41:EXCH] > Cc: Erik Skovgaard; [email protected]; Michel, Ian [FITZ2:8M52:EXCH] > Subject: Re: A philosophical question about large directory structures > > > I think you are omitting scenarios for larger companies like: > > [email protected] > > Large corporations need to subdivide their name space so as to effect > routing of messages within their own networks, which are > geography-based. > > If they happen to have Joe as a unique entry in an internally > addressable directory they may allow [email protected] and resolve > the routing > by an internal lookup. > > This example is real. Your example is real for Nortel as well, although we still generate external email addresses that are [email protected] (allows us to move email servers internally without having to reprint business cards :) What I am trying to do is present a model that provides the easiest intuitive route to guess a DN. If a company decides to subdivide their namespace to effect geographic routing then that is fine as well. Whether they provide directory services at dc=us or not, they will still have the dc=hp, dc=com. If we take the top-down model of directories, I get dc=us, dc=hp, dc=com dc=ca, dc=hp, dc=com dc=it, dc=us, dc=nortelnetworks, dc=com dc=it, dc=ca, dc=nortelnetworks, dc=com dc=hr, dc=ca, dc=nortelnetworks, dc=com dc=hr, dc=us, dc=nortelnetworks, dc=com which presents a tree like: com +--hp | +--us | | +--joe | +--ca | +-nortelnetworks +--us | +--it | +--hr +--ca +--it | +--grunt +--hr I think this tree is more intuitive than: o=hp, c=us o=hp, c=ca ou=hr,o=nortelnetworks, c=us ou=hr,o=nortelnetworks, c=ca ou=it, o=nortelnetworks, c=us ou=it, o=nortelnetworks, c=ca ca +--hp +--nortelnetworks | +--it | +--grunt | +--hr us +--hp | +--joe +--nortelnetworks +--hr +--it As to whether I can discover LDAP services at ldap.us.hp.com or at ldap.hp.com or both is also up to the company. > > > James Benedict wrote: > > > > Erik, > > > > You are right about the size of dc=com, but I think its > size is caused > > as much by the fact that we tried to divide DNS up by > country as well. > > > > When you talk in internet terms, I don't think that > countries make much > > sense. This has always been a problem for large > enterprises like Nortel > > Networks. > > But, today, even smaller companies (less than 60 employees) > have a global > > presence. > > In a location-oriented scheme, where do we put companies like this? > > > > The internet itself transcends geographical boundries, I > think its naming > > contexts need to as well. > > > > I'de like to re-visit the dc-naming model from an end-user > perspective. > > > > DNS, LDAP & email Alignment > > > > The idea here is that my DNS entry maps to the RHS of my > email address, > > and that they > > both map to the dc components of my DIT. > > > > (eg) > > rfc822 = [email protected] > > DNS = nortelnetworks.com > > dc=nortelnetworks, dc=com > > > > What can I do with this: > > > > If I know a user's email address, I can guess that his > PKI cert will be > > somewhere in the > > subtree of dc=nortelnetworks, dc=com. I could go out on > a limb and either > > try > > [email protected], dc=nortelnetworks, dc=com > > or > > DN=userid=grunt, dc=nortelnetworks, dc=com > > > > Failing that, I could try to do some sort of search > filter with email or > > userid. > > > > I could always take a chance that ldap.nortelnetworks.com > is a valid > > LDAPv3 server > > and ask for its schema attribute. > > > > Chances are, if I know anything about an organization > (besides its name) > > it will be either > > an email address (with a DNS name) or a web-page (which > also has a DNS > > name). Anything else, > > I will have to do a search which will likely result in one of the > > previously mentioned pieces > > of information. > > > > Overall, I think that modeling DNS does quickly reduce > the search set in > > most cases. I can > > also see cases where browsing a country-oriented tree > might confuse more > > than help: Which country > > do you think Nortel is in? What if I want to lookup > someone at my local > > IBM office? > > > > Personally, I like the "Keep It Simple" principle. DNS could have > > benifited from a little better > > organization (didn't they try country as well), but "If > you can't beat > > 'em... join 'em" > > > > James A Benedict > > Advisor, IP Directory Systems Architecture > > Carrier Packet Solutions > > NORTEL NETWORKS > > Ph: (613) 763-3909 > > > > > -----Original Message----- > > > From: Erik Skovgaard [mailto:[email protected]] > > > Sent: Thursday, July 22, 1999 12:31 PM > > > To: alexis.bor; 'Tim Howes' > > > Cc: 'Thomas Lenggenhager'; ietf-lsd > > > Subject: RE: A philosophical question about large > directory structures > > > > > > > > > Alexis, > > > > > > I still feel very strongly that the dc= naming is a bad > > > thing. Look at the > > > number of entries immediately under dc=com! > > > > > > The correct thing to do is to reduce the search set quickly > > > (CS 101 as I > > > recall) and the best way we currently have is to use the > division by > > > country. In practice, that is what is done many places > > > around the world. > > > > > > Certainly, we can agree that not all directories will be > > > interconnected, > > > but to make the assumption that none of them will, is > plainly a bad > > > assumption. I think PKI will drive a lot of the > interconnection or at > > > least coordination. > > > > > > Cheers, ....Erik. > > > > > > ------------------------------------ > > > Erik Skovgaard > > > GeoTrain Corp. > > > Enterprise Directory Planning Services > > > http://www.geotrain.com > > > > > > At 16:37 99/06/28 -0400, Alexis Bor wrote: > > > >Tim, > > > >I agree with you that domain names are what people are good > > > at guessing > > > >these days. I think that we learned that lesson at least > > > twice, once with > > > >email and once with the web. > > > > > > > >I have been preaching the idea of the DN as just a pointer > > > to an entry since > > > >the early 90s and have always hid them from all of my > > > applications. I'm > > > >glad that others are seeing the value in that, but it has > > > been a long road. > > > > > > > >Naming has always been an ugly thing and it has caused lots > > > of grief to all > > > >of us in the directory space, as well as others. Everyone > > > seems to take > > > >names very seriously - and understandably so. The real > > > question is how to > > > >do we get past that. I think that dc naming gets us part of > > > the way there. > > > >What we need is a mechanism where if we don't know the dc, > > > to go out and > > > >find it - and hopefully we can do that with protocol most of > > > the time. > > > > > > > >You made an interesting comment early on in this thread that > > > 4 years ago you > > > >realized that directories wouldn't be all connected and that > > > it was probably > > > >a bad thing if they were. I tend to disagree with that. I > > > think that you > > > >were right 4 years ago that the current method of doing it > > > was not workable > > > >for both social and technical reasons. However, that > > > doesn't remove the > > > >need for doing it some day. If you think of DNS as a form > > > of directory, > > > >then it is possible and is useful. I think that there are > > > many applications > > > >that are currently disabled because they can't get to > > > information that could > > > >be stored in directories. > > > > > > > >We are on the verge of having directories deployed in almost > > > every company > > > >with an IT department on the planet, many of them will > have multiple > > > >directories from multiple vendors. At that point, it will > > > be clear that we > > > >need to quickly figure out how to do it, and the rewards > > > will be great. > > > >Just think back of what it was like to maintain HOSTS tables > > > for every > > > >system running IP, and that wasn't very long ago. I think > > > that twenty years > > > >from now, we'll be talking about the good 'ol days when > > > business to business > > > >communication that uses directories was just a dream that > > > many of us were > > > >saying would never happen. And noone will believe that they > > > made routers > > > >and hubs that didn't use DEN... > > > > > > > >-- Alexis > > > > > > > > > > > >Alexis Bor > > > >Directory Works, Inc. > > > >P.O. Box 470276 > > > >Celebration, FL 34747-0276 > > > >407-566-9250 > > > >407-566-9251 (FAX) > > > >[email protected] > > > >http://www.directoryworks.com > > > > > > > > > > > >> -----Original Message----- > > > >> From: [email protected] > > > >> [mailto:[email protected]]On Behalf Of > > > >> Tim Howes > > > >> Sent: Wednesday, June 23, 1999 6:58 PM > > > >> To: Erik Skovgaard > > > >> Cc: Thomas Lenggenhager; [email protected] > > > >> Subject: Re: A philosophical question about large > > > directory structures > > > >> > > > >> > > > >> Just an opinion, but I don't think anybody wants to > > > >> guess at distinguished names. I actually think it's > > > >> likely to be significantly less effective than trying > > > >> to guess domain names, which people seem to be guessing > > > >> or otherwise figuring out today without too much > > > >> trouble. And I don't think any respectable user agents > > > >> will support guessing except possibly as some last > > > >> resort mode of operation. We've seen directory clients > > > >> moving more and more toward hiding DNs from users, and > > > >> I think that's a very good thing and one we're likely > > > >> to see increasingly. -- Tim > > > >> > > > >> Erik Skovgaard wrote: > > > >> > > > > >> > Thomas, > > > >> > > > > >> > I agree that namespaces have to be unique, but I *also* > > > >> believe they should > > > >> > make sense to users. Granted, *some* host names are > > > >> user-friendly, but > > > >> > many are not. > > > >> > > > > >> > In the specific example you mention, I would suggest > that {o=Sun > > > >> > Microsystems, c=ch} is a reasonable and guessable > > > >> namespace. I would not > > > >> > venture to guess what your hostname is. > > > >> > > > > >> > Cheers, ....Erik. > > > >> > > > > >> > ----------------------------------- > > > >> > Erik Skovgaard > > > >> > GeoTrain Corp. > > > >> > Enterprise Directory Engineering > > > >> > http://www.geotrain.com > > > >> > > > > >> > At 23:41 99/06/23 +0200, Thomas Lenggenhager wrote: > > > >> > >On Wednesday, 23 Jun 1999, Erik Skovgaard writes: > > > >> > >> The DC namespace is poorly suited for the Directory > > > >> since the Internet host > > > >> > >> names are not all guessable. For instance, if I were to > > > >> look up Canadian > > > >> > >> Airlines, I would have to *know* that the hostname is > > > >> 'cdnair.com'. > > > >> > > > > > >> > >We are going a bit off track with these messages about > > > namespace. > > > >> > > > > > >> > >The namespace should mainly be unique. That would be > > > >> provided by DC. > > > >> > >Finding something should not be tried to achieve by > > > >> guessing the right > > > >> > >name, but by searching for it (index/directory). > > > >> > > > > > >> > >> Since the Directory name registration is closely tied to > > > >> the legal names of > > > >> > >> companies in most countries, I think that makes for a > > > >> much better choice. > > > >> > >> I would rather find Canadian Airlines as {o=Canadian > > > >> Airlines, c=ca} than > > > >> > >> the somewhat cryptic {dc=cdnair, dc=com}. > > > >> > > > > > >> > >And how about the official name of Canadian Airlines in > > > >> French and the > > > >> > >DN you proposed? > > > >> > > > > > >> > >What is the official name of a company? > > > >> > > Acme or Acme Inc. or Acme, Inc. > > > >> > > > > > >> > >Just as an example of quite ugly and non-guessable names, > > > >> the official > > > >> > >name of Sun in Switzerland: > > > >> > > Sun Microsystems (Schweiz) AG > > > >> > > > > > >> > >Thomas > > > >> > > > > > >> > > > > > >> > > > >> -- > > > >> Tim Howes > > > >> Vice President, Technology > > > >> Office of the CTO > > > >> America Online, Inc. > > > >> > > > > > > > > > > > > > > > >Attachment Converted: "d:\Program Files\Eudora\Attach\Alexis Bor > > > (E-mail)3.vcf" > > > > > > > >