brisco@pilot.njin.net (Thomas Paul Brisco) (08/05/88)
] = vixie@palo-alto.DEC.COM (Paul Vixie) <3674@palo-alto.DEC.COM> > = lmb@vsi1.UUCP (Larry Blair) <886@vsi1.UUCP> } = kehres@tis.llnl.gov (Tim Kehres) <22350@tis.llnl.gov> ]This depends on what you mean by "all your routing". What I mean by "all my routing" is all my routing. I only have to say "rutgers!foo!user" and let the rutgers mail look up the path to site foo. So, it literally does *all my routing*. (I don't know how else to say it). >I have NEVER heard a single good >reason for a site to reroute. Rerouting saves the offending site nothing. >In fact, they end up having to process the same mail twice when it bounces! >[That is a perverse justice] This is more than a perverse justice. Isn't it logical to you that if site A talks to site B then we can infer that site B talks to site A? (I've heard rumors that there is a theory stating that they both also talk with the same bandwidth, but I'm not sure that it's been proved yet ;-) I'm not sure what site you mean by ``the offending site'', but I believe that rerouting is a big win for all sites involved. Let's assume that there exists the following links: A -> B (local, 9600 baud, direct) A -> C (long distance, 1200 baud, daily) B -> C (long distance, 9600 baud, hourly) The obvious thing for the casual user (on A) to send a letter to a user on C to do is to route a letter thus: C!user. The routing mechanism should give the route B!C!user. In this case it is not obvious that C!user is not an optimal path. Not only is it not an optimal path, it might be more expensive. Since site A only polls site C on a daily basis, we should assume that site A is unwilling to spend the money for the phone call very frequently. However, site B has stated that it is willing to spend more money on the cause. Since site B is willing to pay the price for a "better" connection (and has advertised it), then it is only logical to use such a path. However, of course, without a routing mechanism that does "stupid" things like this, we would incur a higher cost and slower speed by waiting around at site A for the poll to B, whereas the path via site C is certainly cheaper (from A's point of view). Of course this is a black-and-white example and obviously contrived - but is not unrealistic. ]If I send to <...!rutgers!foo!bar!person>, and rutgers looks in its map ]database and says "oh, site <<<bar>>> can be reached through ...!baz!bar!user", ]IT HAS JUST DONE THE WRONG THING. Since we are arguing here about what *is* the right thing I'm not sure what this statement means. ]<baz!bar!user> is never nec'ily the same person as <foo!bar!user>. <<<bar>>> ]can be contextual: <baz!bar> and <foo!bar> aren't nec'ily the same machine. ] baz!bar!user foo!bar!user ^ ^ | | +-------------------------------+ What the maps and registry are for is to ensure that they *ARE* the same hosts, and consequently the same user. Looks like you've been bit by the people that I was flaming originally. Either baz or foo are advertising a black hole and should fix their maps. According to the maps, it is *not* doing a `wrong thing', but is only reflecting the bogosity in the maps written by either the administrator at site foo or site baz. } o Optimal source routing can be dynamic and the originator/recipient } cannot always determine best routing. } } o Most users are only concerned about getting their mail through, } not how it gets there. When is the last time you specified the } route the postal service should use to get a letter delivered? } How many of your users can tell you the best route to mcvax } without looking through past mail messages or uucp tables? } ... } }These are probably not the only reasons, but enough to make the point. }There is sometimes a tradeoff between best routing and making the use of }electronic mail possible for a wider range of users. Although pathalias }(or the data that gets fed into pathalias) certainly can be improved, it }does help (most of the time) in generating good paths, and provides some }isolation to a wide range of users to routing decisions. (thanks, Tim). The only thing I've seen so far is that if you don't care enough about the net to keep your maps updated, or complain to the people who don't keep their maps updated, OR simply prefer to do the wrote/repetitive tasks that computers were designed for (like figuring out a path between site foo and baz) - then you should not use the routing information available to you. It seems that if we lived in the "best of all possible worlds" (i.e. where all admins kept their maps updated) then the arguments that I've heard would fall to the ground. If you choose to mark rutgers dead (and it sounds like you'll be marking mcvax dead soon, too), I'm sure they'll be very happy to not have your mail passing through their machines. vixie's and lmb's arguments sounds as if they want to cure the symptoms, not the disease. I must infer that if you get a ticket (or whatever) for breaking a law that you don't agree with - then you flame on the cop, not on your government officials. Yes - it is very frustrating to have a letter disappear down a black hole. I do not, however, think that this means that I should do my routing by hand - I tend to blame the person advertising a bogus route. Tp. -- ---------------------------------------- UUCP: ...!rutgers!brisco ...!njin!brisco ARPA: brisco@pilot.njin.net BITNET: brisco@zodiac.bitnet Voice: (201) 932-2351 ---------------------------------------- Ask me about the New Jersey Intercampus Network Pilot Project
lmb@vsi1.UUCP (Larry Blair) (08/06/88)
Excuse my massive editing of the posting I'm responding to; on the other
hand, my original was reduced to an acknowlegement with all lines removed.
In article <Aug.5.11.45.54.1988.16554@pilot.njin.net> brisco@pilot.njin.net (Thomas Paul Brisco) writes:
= Let's assume that there exists the following links:
=
= A -> B (local, 9600 baud, direct)
= A -> C (long distance, 1200 baud, daily)
= B -> C (long distance, 9600 baud, hourly)
=
= The obvious thing for the casual user (on A) to send a letter to a
=user on C to do is to route a letter thus: C!user. The routing
=mechanism should give the route B!C!user.
I have no problem with this. The problem comes when I ask A to do
A!B!C and they send to C~ in Finland. As long as they get it to B, B
can send it to the machine that B calls C.
= baz!bar!user foo!bar!user
= ^ ^
= | |
= +-------------------------------+
=
= What the maps and registry are for is to ensure that they *ARE*
=the same hosts, and consequently the same user. Looks like you've
=been bit by the people that I was flaming originally. Either baz
=or foo are advertising a black hole and should fix their maps.
= According to the maps, it is *not* doing a `wrong thing', but
=is only reflecting the bogosity in the maps written by either
=the administrator at site foo or site baz.
The usual case here is that either foo or baz talks to a machine named bar
which is NOT advertised in the maps. It has been a clear Usenet policy that
every site need not advertise every machine they talk to. It has also been
a clear policy that sites should not list every local machine (heaven help us
if they did). In the perfect world, all machines and users and SOFTWARE
would understand and only use domain routing. The world, currently, is not
constructed that way. As Paul said, rutgers is RUDE.
--
* * O Larry Blair ames-----\
* * O VICOM Systems Inc. pyramid---\
* * O 2520 Junction Ave. uunet!ubvax!vsi1!lmb
* * O San Jose, CA 95134 sun-------/
* * O +1-408-432-8660 +1-800-538-3905lmb@vsi1.UUCP (Larry Blair) (08/06/88)
|n article <891@vsi1.UUCP> I wrote: |= baz!bar!user foo!bar!user |= ^ ^ |= | | |= +-------------------------------+ |= | |The usual case here is that either foo or baz talks to a machine named bar |which is NOT advertised in the maps. Upon reflection, the problem is that the "rerouters" are assuming that baz!bar!user really means baz!bar.uucp!user. If I had specified a domain, the rerouters would be justified (but still rude) in changing the path. In the absence of a domain name, it is not reasonable to assume ".uucp". As I said before, "bar" may be a machine local to "baz". How do users at baz mail to the bar in the maps? Bar.uucp, of course! Btw, I don't mark mcvax as dead because: a) it's the main gateway to Europe; and b) nearly every European address I've seen uses domain addressing (almost to excess). -- * * O Larry Blair ames-----\ * * O VICOM Systems Inc. pyramid---\ * * O 2520 Junction Ave. uunet!ubvax!vsi1!lmb * * O San Jose, CA 95134 sun-------/ * * O +1-408-432-8660 +1-800-538-3905
pleasant@porthos.rutgers.edu (Mel Pleasant) (08/09/88)
In article <891@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: > The usual case here is that either foo or baz talks to a machine named bar > which is NOT advertised in the maps. It has been a clear Usenet policy that > every site need not advertise every machine they talk to. It has also been > a clear policy that sites should not list every local machine (heaven help us > if they did). In the perfect world, all machines and users and SOFTWARE > would understand and only use domain routing. The world, currently, is not > constructed that way. As Paul said, rutgers is RUDE. This is a real interesting set of statements. To it I say, *BULL*. As far as I am concerned, the map files are not really for people to read but for systems to GENERATE PATHS BY. I, as a person who communicates with people all the time about map entry production, do *not* say in an unqualified way that internal links should not be listed in a map entry. My answers to questions pertaining to what should appear in a map entry is consistent with this point of view. The UUCP Mapping Project would love to see all unqualified (without domain) names _appear_ in the map files. By the same token, I would also like to see the files become smaller. I encourage this by saying, "get yourself a domain and USE SMAIL or some home grown equivalent." Along with this, make sure all of your internal nodes generate fully qualified hostnames for themselves. If you do have an unqualified name that escapes into the `network' at large via mail or news headers, that name *should* (verging on `must') appear in a map entry someplace. I run a script periodically that identifies ghost sites (sites that pathalias can generate a path to but which we do not have a map entry for.) I then run another script which sends mail to these sites at both the uucp and root addresses. The message I send explains what the UUCP Mapping Project is and does, and asks for a map entry as registration. I hope that I've cleared a few things up - speaking with the horse's mouth. -- The UUCP Mapping Project -- Mel Pleasant {backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnet
cks@ziebmef.uucp (Chris Siebenmann) (08/10/88)
In article <Aug.5.11.45.54.1988.16554@pilot.njin.net> brisco@pilot.njin.net (Thomas Paul Brisco) writes: > >] = vixie@palo-alto.DEC.COM (Paul Vixie) <3674@palo-alto.DEC.COM> >> = lmb@vsi1.UUCP (Larry Blair) <886@vsi1.UUCP> >} = kehres@tis.llnl.gov (Tim Kehres) <22350@tis.llnl.gov> > >]This depends on what you mean by "all your routing". > > What I mean by "all my routing" is all my routing. I only >have to say "rutgers!foo!user" and let the rutgers mail look >up the path to site foo. So, it literally does *all my routing*. (I >don't know how else to say it). This is a good thing to do. What large numbers of people dislike is sites that take site!a!b!c!d!e!user (when they talk to a) and reroute it to be foo!bar!e!user (rerouting it this way is also evil even if site doesn't talk to a; it should restrict itself to finding a route to a and leave the rest alone). >>I have NEVER heard a single good >>reason for a site to reroute. Rerouting saves the offending site nothing. >>In fact, they end up having to process the same mail twice when it bounces! >>[That is a perverse justice] > > This is more than a perverse justice. Isn't it logical to you >that if site A talks to site B then we can infer that site B talks >to site A? (I've heard rumors that there is a theory stating that >they both also talk with the same bandwidth, but I'm not sure that >it's been proved yet ;-) [A digression:] This depends by what one means by 'talking' and where the ! path is coming from. There used to be a site (I know because I used it) that generated a Path: line on outgoing articles that could not be used for replies (the mailer on the next-hop machine didn't know it by the name it was sticking on the Path: line). > I'm not sure what site you mean by ``the offending site'', but >I believe that rerouting is a big win for all sites involved. > > Let's assume that there exists the following links: > > A -> B (local, 9600 baud, direct) > A -> C (long distance, 1200 baud, daily) > B -> C (long distance, 9600 baud, hourly) > > The obvious thing for the casual user (on A) to send a letter to a >user on C to do is to route a letter thus: C!user. The routing I hope not. The obvious thing to do is to send the letter with an address of user@C.UUCP (or user@C). The mail transport system will then helpfully figure out how to route the letter, and send it to B!C!user. > [proposes A rewrite this as B!C!user, since B advertises cheap > connections with C, and suggests that this is a win.] > ... >]<baz!bar!user> is never nec'ily the same person as <foo!bar!user>. <<<bar>>> >]can be contextual: <baz!bar> and <foo!bar> aren't nec'ily the same machine. >] > baz!bar!user foo!bar!user > ^ ^ > | | > +-------------------------------+ > > What the maps and registry are for is to ensure that they *ARE* >the same hosts, and consequently the same user. Looks like you've >been bit by the people that I was flaming originally. Either baz >or foo are advertising a black hole and should fix their maps. This is only true for registered hosts. There is no requirement for registering all the hosts in a bang path; if there were, we could get rid of bang paths entirely and just use user@site.UUP syntax (except when the maps are outdated). In fact, I can think of a local example. My site, ziebmef, talks to a machine called seeker. It's a local Amiga, and not registered in the maps (the map coordinators have said in the past that they do not want personal computer map entries). Since seeker isn't registered, ziebmef doesn't mention a connection to it in its map entry (a good thing, too). There's also a seeker in Florida, which is in the UUCP maps. Now, you decide you want to send mail to the Toronto seeker, and send it using a bang path (which you have to, since smail sites like ziebmef don't understand the % hack) such as rutgers!uunet!mnetor!lsuc!ncrcan!ziebmef!seeker!wjr (for the sake of argument, assume rutgers has a direct uunet connection) rutgers comes along and says 'aha! by my magic powers of deduction, I know this is going to wjr@seeker.UUCP', looks up seeker, and routes it to Florida, where the Florida seeker will bounce it (if you're lucky -- if you're not, the Florida seeker also has a user called 'wjr'). > According to the maps, it is *not* doing a `wrong thing', but >is only reflecting the bogosity in the maps written by either >the administrator at site foo or site baz. What if foo's map entry doesn't show their connections to bar? This is legal (and might be done, for example, because bar is really bar.hiho.com, and there's already a different bar machine in the maps). >(thanks, Tim). The only thing I've seen so far is that if you don't >care enough about the net to keep your maps updated, or complain to >the people who don't keep their maps updated, OR simply prefer >to do the wrote/repetitive tasks that computers were designed for >(like figuring out a path between site foo and baz) - then you >should not use the routing information available to you. The mail transport agent should use the routing information available to it -- but only when handed an address, not a route. If I know enough to specify a route, I probably have a pretty good reason to do so. Perhaps the message I'm sending to C!user (to use the first example) is sensitive business correspondence, or a large file that B won't appreciate spending LD changes on, or B is down for a few days and the administrator on A hasn't bothered updating the path database yet. Once I specify a route as opposed to an address, by gollee, I don't want it rewritten. Sure, bounce it -- that's fine. But don't reroute my mail for Ontario to Florida. > It seems that if we lived in the "best of all possible >worlds" (i.e. where all admins kept their maps updated) then the >arguments that I've heard would fall to the ground. If >you choose to mark rutgers dead (and it sounds like you'll be marking >mcvax dead soon, too), I'm sure they'll be very happy to not have >your mail passing through their machines. It can take up to two months to have a map change propagate out through the uucp maps in comp.mail.maps. What do you propose we do in the mean time? > Yes - it is very frustrating to have a letter disappear >down a black hole. I do not, however, think that this means that >I should do my routing by hand - I tend to blame the person advertising >a bogus route. This is why people should use addresses, instead of routes. Routes are a last resort when you can't get a working address; when you're on your last resort, it's very irritating to have rutgers bounce your mail because it thought it knew more than you did. In this day of wide smail and sendmail availability, there is no reason why any system can't have a system that uses '@' addresses. There's not even a requirement for uucp-only sites to keep around the full maps (smail will punt unknown addresses to a defined host for you). Given this, we should treat bang paths as what they are, namely routes, instead of a form of addresses. -- "Oh BLESS you, sir! The ANGEL OF DEATH was after me just as SURE as you're standing there, yes he WAS!" Chris Siebenmann uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks
lmb@vsi1.UUCP (Larry Blair) (08/10/88)
In article <Aug.8.21.50.59.1988.4676@porthos.rutgers.edu> pleasant@porthos.rutgers.edu (Mel Pleasant) writes: >In article <891@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: > >> The usual case here is that either foo or baz talks to a machine named bar >> which is NOT advertised in the maps. It has been a clear Usenet policy that >> every site need not advertise every machine they talk to. It has also been >> a clear policy that sites should not list every local machine (heaven help us > >systems to GENERATE PATHS BY. I, as a person who communicates with people >all the time about map entry production, do *not* say in an unqualified way >that internal links should not be listed in a map entry. My answers to >questions pertaining to what should appear in a map entry is consistent with >this point of view. > >The UUCP Mapping Project would love to see all unqualified (without domain) >names _appear_ in the map files. By the same token, I would also like to >see the files become smaller. I encourage this by saying, "get yourself a >domain and USE SMAIL or some home grown equivalent." Along with this, make >sure all of your internal nodes generate fully qualified hostnames for >themselves. If you do have an unqualified name that escapes into the >`network' at large via mail or news headers, that name *should* (verging on >`must') appear in a map entry someplace. It's nice to see that both Mel and Bill, the targets of our recent abuse, have finally gotten into the fray. If I understand what you are saying here, you are saying that all sites must either: a) hide their local systems; b) register the names of their local systems (with _unique_ names); or c) use domain-type names. Since you are using a Sun, you find it pretty easy do either a or c. Others do not have such an easy time of it. On top of that, you are saying, "If you want to mail to a site machine that isn't registered, don't let it route through rutgers". Well, that's been the point of this discussion. Reiterating my main point: when I say rutgers!foo!baz I'm not saying rutgers!baz.uucp. You are entitled to do what ever you want to send it to foo; you might even be justified in rerouting it to baz.uucp IF I had said baz.uucp, but all I've told you about is foo. It is foo's job to send it to their baz, which may or may not be baz.uucp. What I'm still not sure of is why you reroute. What benefit does rerouting provide to rutgers? Passive pouting (as Paul Vixie has called it) would serve completely for your smart-host function. Rerouting can only make a working route break. -- * * O Larry Blair ames-----\ * * O VICOM Systems Inc. pyramid---\ * * O 2520 Junction Ave. uunet!ubvax!vsi1!lmb * * O San Jose, CA 95134 sun-------/ * * O +1-408-432-8660 +1-800-538-3905
lear@NET.BIO.NET (Eliot Lear) (08/10/88)
For those who don't know, Mel Pleasant just left for a well deserved vacation in Europe. While I can, in no way, speak for Mel; I want to respond to Larry Blair's message. In article <901@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: > If I understand what you are saying here, you are saying that all sites > must either: a) hide their local systems; b) register the names of their > local systems (with _unique_ names); or c) use domain-type names. Under all circumstances, you have the ability to to (b). Rutgers encourages all of the above but (b) is the minimum goal. As Mel stated quite clearly, these maps should not be for humans to read. They should be for machines to interpret so that people don't need to remember routes. The thought of losing mail because one is not registered is a great incentive for (a), (b), or (c). Larry then goes on to say how rutgers makes the assumption that a host baz in rutgers!foo!baz... is, in fact, baz.uucp, a host listed in the UUCP maps. This has the side effect that some other baz will wonder where its mail is going, and would, thus, be encouraged to (a), (b), or (c), which is what we want. Larry also goes on to dictate what we are entitled to do with headers. In fact, we are entitled to do whatever we want with addresses in headers. [There is one notable exception that nobody has mentioned, listed in RFC-822, which rutgers does not violate. Look it up.] Next, Larry asks the $64,000 question: why do we reroute? Q: What represents a better route? (1) One that is the shortest path. (2) One that takes the least time. (3) One that is determined by the combined wishes system administrators between me and my destination. A: Left as an exercise to the reader. We reroute for a number of reasons, the first of which is to encourage (a), (b), or (c) [though not necessarily the primary reason]. Furthermore, more often than not, we know a better route than a user will hand us. Let me reiterate my position, as stated to Brian Reid some weeks ago. While there are routes that break, it is important not to throw the baby out with the bath water, as far as these things go. If a route needs fixin, fix it. If a host needs addin, add it. And yes, yell at those who are not registered. Finally, I want to second Paul Vixie's ``Thank you''. A very small group of people rather thanklessly put together the software that we use. ``Thank you'' seems all too small of a gesture. -- Eliot Lear [lear@net.bio.net]
dan@ccnysci.UUCP (Dan Schlitt) (08/15/88)
I have refrained from commenting on this string up until now, even though I have some fairly strong feelings on the subject. I was sort of waiting to hear what Mel Pleasant had to say. Now that he has commented I would like to add my couple of cents worth. We should all appreciate the work that Mel and the others in the mapping project do for making uucp mail more reliable by providing up to date maps. It certainly makes my job of telling people how to address their mail a lot easier. "Use user@site and let our mail system figure out the best route." HOWEVER, that doesn't always work. Bad map entries or missing ones sometimes get in the way. Or sometimes users think they know better how to route the mail than I do. :-) Anyhow, sometimes you need to use a specific route. You can't do that if some intervening mailer is going to mess with the specific bang-path you have given. My goal is to make it possible for userA at my site to send mail to userB at some other site. I can control my map entry, the map entries I use, and my mailer. I cannot control how other people administer their mail systems. Frequently userB has little influence on how mail is administered on their site. Why should my goal of communication between the two users be frustrated by the combination of poor mail administration at one site and the ****** behavior of someone else's "smart" mailer? -- Dan Schlitt dan@ccnysci