dplatt@coherent.com (Dave Platt) (01/03/90)
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. 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. 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. All hell breaks lose, because _your_ site lists a connection to "ilmss". Mail destined for the "official" ilmss will tend to end up being routed to your neighbor, via you. The closer you are to a high-connectivity site (nee "backbone"), the more likely this is to occur. If the new "ilmss" has set up connections to a couple of popular sites, thousands of systems across the net may try to use it as a relay... and that mail will end up roaring through your system, passed to your neighbor, and rudely bounced back through you. 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. 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. 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. 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. -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
karl@ddsw1.MCS.COM (Karl Denninger) (01/04/90)
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, <well-connected>!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"
lee@unmvax.unm.edu (Lee Ward) (01/04/90)
In article <1990Jan3.164811.5457@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >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: . . . >> >>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! > Too bad. ilmss didn't go to the trouble of reserving the name. It is pretty easy and not costly to do. Why would they NOT want to do it? If they are lazy it's their tuff luck if someone else DOES want to reserve the name. >>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. I'm afraid not. Read on... > >>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! > Sorry, it's still inevitable UNLESS you guarantee that the "private" connect is an end node only. Addresses that are not source routed SHOULD not go to the site you want to give out stars for :-) The way our mailer is set up here is that: If we see name@host we try to resolve it through the internet. The UUCP hosts that ARE registered will resolve now. We send to their forwarder which WILL source route. If it doesn't resolve, we'll try it as a UUCP site, first as a local link and then through the maps. If we weren't on internet we would bypass the local lookup to force it to a registered site if one exists. The only way to the private site would then be with bang paths. If we see unmvax!private-link, whether registered or not we try to resolve by looking in our L.sys. If not there then try the UUCP maps. We encourage people to use the at-sign syntax so as not to force a particular network. Avoiding the bangs will let us use internet forwarders when possible. If someone wants to route through unmvax to a private link that is unregistered (there are some). They use: private!name@unmvax Even if private is registered their mail goes to the right place UNLESS we don't have the link. This goes whether it is a duplicated name or not. It is also how people with unregistered machines SHOULD be addressed. After all the address does mean the machine private off of unmvax. It sure is nice to tell my friend on the phone that I'm lee@unmvax on any UUCP machine supporting the syntax instead of {gatech,ucbvax,rice,anlams}!unmvax!lee. Gee, try one, I dunno. But then I paid for the priviledge with my time getting (and maintaining) my entry into the maps. If my neighbors don't and the map coordinator deletes them, they aren't unreachable just painful to reach. It seems to me that if a site doesn't want to go to the trouble of registering their name, that name is still up for grabs. Who cares if it shows up as a private link to some site. Just delete that one and register it to someone else. Let the guy who didn't register it deal with the problem. For that reason, blow it out of the map so the coordinator doesn't have to go to the trouble later. -- --Lee (Ward)
dplatt@coherent.com (Dave Platt) (01/04/90)
In article <1990Jan3.164811.5457@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: > 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! I guess this is where we disagree, Karl. As I see it, according to the "rules of the game", the name "ilmss" is NOT ALREADY TAKEN. The site which used to use it, has lost its moral right assert that it is "ilmss", because they decided to drop their map entry. > 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. That's correct. > 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! I guess I disagree, once again. There are ways: register as an individual site, or live within a registered domain. > 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. Again, I acknowledge your point of view, but I disagree. To me, an "available" name is one which nobody has put "dibs" on, using one of the available registration mechanisms. That's why those mechanisms were developed, and why the Net Deities "strongly encourage" all sites to register. > 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. I do see one problem with this. If a site is "mentioned" in the maps, but is not "registered", then it's impossible to tell by examination whether this site [a] is real, but simply unregistered, [b] was once real, has since died, has had its map entry deleted, but has not had its name removed from its neighbors' map-files because their sysadmins aren't staying current, or [c] is a simple typo. > 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! I guess we define the problem differently. To my eyes, the cause of the problem is that some sites don't register... and still expect to receive the same quality-of-service as if they had done so. Sending in a simple map-entry isn't a lot of work. If I set up a connection for a neighbor-site, I _do_ check to make sure that their name isn't in use by any registered or "mentioned" site, just as you do. However, I go further... I check to see whether they've sent out a map-entry, urge them to do so, and assist them in filling it out if necessary. Then, if they don't do so, and if somebody comes along and preempts their name... TOO BAD! I'll sever my link to the neighbor-who-could-not-be-bothered! To sum it all up... I guess both of our approaches have points in favor and points against. It seems that this is one issue on which reasonable people can disagree. Unless there's a really strong collective decision about this issue on the Net, each area map coordinator will probably permit or proscribe the mentioning of unregistered sites in his/her area's official map files. -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
pleasant@porthos.rutgers.edu (Mel Pleasant) (01/04/90)
After seeing all of this discussion on site names for which there aren't any
map entries, I thought I might tell you what the official policy is. This
is the way it is suppose to hapen across the country and indeed around the
world. Mileage varies but, as far as I can tell, the regional co-ordinators
attempt to follow the process when possible. When the process isn't or
can't be followed there's lot of communication and, hopefully, a reasoned
solution for the special situation, to wit:
If a site name appears on a #N line it is considered to be permanently
registered. If pathalias generates a path to a site for which there isn't a
map entry, the sitename is considered to be conditionally registered.
What's the difference? Well, a conditionally registered site may hold on to
its name for as long as no one else wants it and remain without a map entry
for that period of time. However, should some other site want the name
*and* is willing to register it with a map entry *and* insists upon
attempting to steal it, the conditionally registered site is first offered
the opportunity to upgrade its registration to permanent status. We do this
because conditionally registered sites may have picked up quite a few
connections over time. Generally, it is much easier for the new guy on the
block to pick a new name. If the conditionally registered site refuses to
upgrade, we blow'em away and accept the new registration. The procedure has
worked for quite some time now. I'm always open to suggestions for change
but I'd like to see them backed by some fairly strong arguments.
By the way, I recognize that this procedure causes additional work for the
regional co-ordinators but it also avoids the gnashing of teeth that
prevailed before the procedure was put into place. I'd like to have as
friendly a procedure as possible and I think this is about as friendly as
one can get and still maintain some semblance of order.
--
Mel Pleasant
{backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnettneff@bfmny0.UU.NET (Tom Neff) (01/04/90)
I understand Mel's idea of the conditionally registered site being blown away when some site decides to grab a real #N registration of the name. But what I don't get is this: Suppose TWO or more sites conditionally register the SAME name, by being mentioned in two distinct map entries for sites who've never heard of each other. Doesn't pathalias get terminally confused? In fact, won't mail to either site get randomly mixed depending on how the sending site costs-out the path to one map reference versus another? Say, for instance, I feed my brother-in-law's site 'spungg' in NYC, and just mention it on my maps: spungg(DEMAND). Meanwhile someone in Oregon feeds his proctologist's machine which is similarly named 'spungg' and HE says: spungg(DIRECT). Neither machine has a #N entry. Now to pathalias, these are the same machine, right? If someone explicitly routes through mysite!spungg or hissite!spungg and is lucky enough to avoid rabid rerouters, it might work, but otherwise my brother-in-law will get some of the proctologist's mail and vice versa, depending on which path looks cheaper to the sender. That's why I don't think 'conditional registration' ought to be allowed. If pathalias sees a node name mentioned in a neighbor-list, but has no #N entry for it, it ought to report it out separately as an error, methinks. I haven't quite figured out whether smart-host affects this. -- "We must never forget that if the war in Vietnam \ $ Tom Neff is lost... the right of free speech will be X tneff@bfmny0.UU.NET extinguished throughout the world." -- RN 10/27/65 $ \ uunet!bfmny0!tneff
karl@ddsw1.MCS.COM (Karl Denninger) (01/05/90)
In article <Jan.3.23.36.11.1990.7404@porthos.rutgers.edu> pleasant@porthos.rutgers.edu (Mel Pleasant) writes: > >If a site name appears on a #N line it is considered to be permanently >registered. If pathalias generates a path to a site for which there isn't a >map entry, the sitename is considered to be conditionally registered. >What's the difference? Well, a conditionally registered site may hold on to >its name for as long as no one else wants it and remain without a map entry >for that period of time. However, should some other site want the name >*and* is willing to register it with a map entry *and* insists upon >attempting to steal it, the conditionally registered site is first offered >the opportunity to upgrade its registration to permanent status. We do this >because conditionally registered sites may have picked up quite a few >connections over time. Generally, it is much easier for the new guy on the >block to pick a new name. If the conditionally registered site refuses to >upgrade, we blow'em away and accept the new registration. The procedure has >worked for quite some time now. I'm always open to suggestions for change >but I'd like to see them backed by some fairly strong arguments. That sounds quite reasonable, and implements essentially the same setup that I had envisioned. In fact, I think that this policy was called out somewhere before, as it looks awfully familiar. Thanks again to Mel for elucidating a reasoned method behind the madness of uucp mail! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!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"
woods@robohack.UUCP (Greg A. Woods) (01/05/90)
In article <599@unmvax.unm.edu> lee@unmvax.cs.unm.edu (Lee Ward) writes: > In article <1990Jan3.164811.5457@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: > >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: > >>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! Ah, but "ilmss" *isn't* allready taken. The name is only reserved if there is a complete map entry for the site. > If someone wants to route through unmvax to a private link that is > unregistered (there are some). They use: > > private!name@unmvax However, if the private link is mentioned, but not registered, it is liable to end up getting lots of mail for the real "private". The only correct thing to do to entries mentioning private links is to either delete them, or mark them dead. They should NOT be there. -- Greg A. Woods woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET} +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
gil@limbic.UUCP (Gil Kloepfer Jr.) (01/05/90)
In article <Jan.3.23.36.11.1990.7404@porthos.rutgers.edu> pleasant@porthos.rutgers.edu (Mel Pleasant) writes: >What's the difference? Well, a conditionally registered site may hold on to >its name for as long as no one else wants it and remain without a map entry >for that period of time. However, should some other site want the name >*and* is willing to register it with a map entry *and* insists upon >attempting to steal it, the conditionally registered site is first offered >the opportunity to upgrade its registration to permanent status. And further, what this means (for those who can't see into it) is that one should not just blindly stick a site name in their map entry without first checking (either though smail -AR with an _UP_TO_DATE_ pathalias file [how many of you *really* have up-to-date ones???] or by a simple message to your regional coordinator) if the site name exists already! >because conditionally registered sites may have picked up quite a few >connections over time. Very true! By the way, the simplicity of creating a map entry really means it's kind of silly to have a site registered conditionally if that site plans to be around for a while! Do your friend a favor and help him/her make a map entry if he/she doesn't already have one! ---- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | ...ames!limbic!gil
dricejb@drilex.UUCP (Craig Jackson drilex1) (01/05/90)
I have long understood, but not agreed with, this "no links to 'unregistered'
sites" policy. It works against the "don't register your leaf nodes--just
your domain gateway" policy, and tends to increase the size of the maps.
But I can understand that the map coordinators would like to have information
on every node.
This first hit me when another site in another division joined a 'park' domain,
and was no longer listed in the maps because of that. Suddenly, I could
not list a link to that site, either. Of course, this was back in the days
of the 'expensive' domains.
The present brouhaha came about because a map coordinator has decided to
place an 'expire' function on his portion of the maps. Everybody not heard
from in a year is dead. This means that the 'permanent' name reservation
that Mel Pleasant refers to is really only a 'one year' name reservation.
Possibly reasonable, but not expected.
My map entry doesn't change that often, although it's a bit out of date now.
I guess a prudent sysadmin should start learning about the once-a-year
abilities of cron ...
And the map coordinators should probably expect more low-information map
entries, with just enough specified to be accepted. (These would be filed
by the neighbors, not the sites themselves, probably.)
--
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}pjg@autarch.acsu.buffalo.edu (Paul Graham) (01/06/90)
i haven't been a map-coord for a year (despite the fact that my name still appears) but i play one on t.v. you don't (aren't supposed) get two ``ghost'' (the technical term) sites unless they both spring up in the update window because the region co-ord. is supposed to check new sites against the maps before they send them in to mel. doesn't always work but nothing else does either so, so what. there's a policy, it just has the possibility of failure. mel's choice of permanent vs. conditional was for contrast, not to suggest that any name is ever *permanent*. sites come and go all the time. sometimes in the update window itself. if a regional co-ord. ops to purge silent sites after a year that just fine as long as it's not a secret. i've never know it to be a secret and in fact i recently got mail prompting a map update. i'd say that's typical. and if the regional can't find you then you probably don't exist. if no one at the site responds to requests for an update (i used to call) then they shouldn't exist (my opinion). finally: the map project encourages people with definite knowledge about other sites to submit maps or updates on their behalf. oooops (really finally): if a regional deleted a ghost site entry it might be a little heavy-handed but you can always submit a map for the ghost and make it real. or appeal to the map gods.
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (01/10/90)
Mel Pleasant (pleasant@porthos.rutgers.edu) writes: > ... > map entries, I thought I might tell you what the official policy is. > ... > If a site name appears on a #N line it is considered to be permanently > registered. If pathalias generates a path to a site for which there isn't a > map entry, the sitename is considered to be conditionally registered. > ... The way I interpret this, I am entitled to maintain ilmss in my map entry. Before someone other than "my" ilmss successfully registers their site, "my" ilmss will be given one last chance to update their map. In the mean time, I'll be pestering them to update their entry or give me permission to submit an entry for them that just says that they talk to me. I'll also be registering "falkor" the same way. And thanks to Mel for reiterating the policy! -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "It is the province of knowledge to speak & the privilege of wisdom to listen"