Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!emory!att!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: news.config Subject: Re: Unregistered-but-referenced sites (was Re: deleted UUCP sites) Summary: Rebuttal to opinion Message-ID: <1990Jan3.164811.5457@ddsw1.MCS.COM> Date: 3 Jan 90 16:48:11 GMT References: <4195@convex.UUCP> <30273@mcdchg.chg.mcd.mot.com> <43496@improper.coherent.com> Reply-To: karl@mcs.MCS.COM (Karl Denninger) Distribution: news Organization: Macro Computer Solutions, Inc. - Mundelein, IL Lines: 126 In article <43496@improper.coherent.com> dplatt@coherent.com (Dave Platt) writes: >In article <30273@mcdchg.chg.mcd.mot.com> heiby@chg.mcd.mot.com (Ron Heiby) writes: >> When I received similar email, I sent the following message. Am I way >> off base here? Thanks. >> ----- >> Excuse me, but just because a site does not choose to continue to maintain >> a map entry is no reason to delete it from *my* map entry. My site still >> talks with ilmss. I still forward news and mail to and from them. Removing >> them from the maps is not the right thing to do. Delete *their* entry, sure! >> But, don't pull them out of everyone else's. You don't have a map entry >> for "falkor", do you? Yet, it's a real machine that I talk with almost >> every day. Falkor just chooses not to have a map entry. I keep my map >> entry pretty current. If you think a change (other than a simple typo) >> needs to be made, you should consult me first. If I've committed a typo, >> I'd like to at least be informed. Thanks. Ron. > >Ron... I wouldn't say you are "off base"... but I do disagree with you. And I disagree with you, and agree with Ron... I will explain below. >If your neighbors, such as "ilmss" and "falkor", choose not to bother >maintaining map entries, that's their right. And, you have a perfect >right to maintain connections to them... and to have them listed in a >path-file that's fed into pathalias at _your_ site. > >However, the pathalias map file that your site broadcasts to the world >should _not_ list these nodes. > >The reason is this: if ilmss and falkor aren't maintaining entries in >the global map files, then (according to the rules of the game) their >node-names are up for grabs. If they aren't registered, they don't have >"dibs" on the names that they are using. Reserving names, and avoiding >namespace conflicts, is one of the two primary purposes of the map files >(listing connectivity data is the other, of course). As a USENET deity >has commented, "The good names are all taken." > >So... consider what happens if some new site comes on line, and chooses >a name for itself... say, "ilmss". That name isn't reserved, it's up >for grabs, and they take it. They publish a map-file, reserving this >name for themselves. The new "ilmss", however, can't tell that their choice of name is ALREADY TAKEN, since you would have mcdchg delete the declaration from their map entry! >All of a sudden, there are two "ilmss" sites on the net... the official >one, and your neighbor who chose not to bother keeping dibs on the name. >Pathalias can't tell the difference between them. That's correct. >Everybody loses... you, your neighbor, the folks at the officially- >registered "ilmss", and the folks trying to reach "ilmss". It's a bad >scene. It's possible for large amounts of mail to end up being routed >to the wrong continent, in severe cases of double-name-binding. Yep, absolutely right again. >So... it's absolutely your right to keep "ilmss" listed in the >map file that you maintain locally. It's not your right, I feel, to >insist that your private connection to an unregistered host be >propagated into the pathalias data all across the network. To do so is >to demand that the "ilmss" name be reserved for use by a site that >isn't willing to play by the rules. Is it? Wait a second. What about the other side of the coin, to whit: Site "ilmss" doesn't register EXCEPT with mcdchg -- and mcdchg keeps that link "private". Now, mail gets to mcdchg for "ilmss" without a complete source-route (ie: it's received as "user@ilmss"). Let's say someone else has taken the name and REGISTERED it. Now where does the mail go? You get a star if you say "to the machine just off mcdchg". Which is the wrong routing. Worse yet, there is no way to know that this is about to or has happened, since you can't tell that "ilmss" is declared anywhere until AFTER you start losing mail! IF mcdchg declares the link, then anyone wanting to use the name "ilmss" can check the routing tables and quickly see that the name is already taken somewhere else. If mcdchg does NOT declare the link, there is no way to prevent the problem from occuring! >There are polite and effective ways to support sites which choose not to >post individual map entries. Any neighbor who has a registered >domain-name can act as a forwarder... in effect, "hiding" the >unregistered site as a subdomain of the registered name. This way, the >unregistered site's machine-name doesn't "pollute" the global namespace >for the .uucp subdomain, and doesn't confuse pathalias. If a site which wants to register -- either by being entered into one person's routing table (but not posting a map entry), or by sending a map entry checks FIRST to see if the name is in use, this problem could vanish. You see, if I do a "smail -bt test@ilmss", I will see that I can get there from here. So I won't use that name, and will refuse to accept a connection from there UNLESS the requester can verify that he is the one who talks to "mcdchg" already (which means that it is the same site!) Problem solved. >So... to sum it up, I think that your area map-coordinator did an >appropriate thing by removing the names of unregistered sites from the >copy of your map entry that was added to your area's distributed map-file. Your suggestion makes it impossible for me to verify that a name is available. If people have "private" connections to sites which aren't in the maps, mail WILL fall into a black hole sooner than later. Internet (or re-routing) sites are the worst, of course, since if they take on a "undeclared" connection you can virtually guarantee that mail will soon disappear or get misrouted. In short, I agree with Ron -- people should be able to declare connections to sites which aren't in the maps, and if they do it SHOULD be honored -- it should reserve the name which is declared (preventing that site name from being registered later by anyone else.) This way a little common sense before you accept a site (and show a connection there) can avoid the misrouting problem entirely. Sure, people will still have misrouting problems. But at least you aren't designing it into the process in such a way that it is inevitable! -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"