mark@cbosgd.ATT.COM (Mark Horton) (12/02/86)
There were a few hiccups in the mod.map posting this month.
There was an empty file posted with subject
UUCP map for d.u[a-l]*
due to a shell script typo. The d.* files were also posted twice,
once with a long subject line which causes problems for a few systems.
The 2nd and 3rd batches did not go out on schedule, and are being
sent out currently - these batches have the AT&T maps for nj and il.
Finally, the 7th batch did not go out, due to a crontab problem.
It went out yesterday.
Anyway, when u.usa.il.a.? arrives on your machines (it will leave
cbosgd tonight, Dec 2) you will have the complete map. You can
safely discard the d.u[a-z]* posting, and you should also probably
discard u.Path.? since those files have been replaced.
I apologize for any inconvenience this may have caused. The problems
have been corrected and should not affect next month's posting.
Next month's posting will adopt a minor change; we will no longer
post duplicate information in both the d.* and u.* files. For domains
that are registered and appear in d.*, we will delete their information
from the u.* file. If you have information in only your u.* that you want
to continue to send out, it should go into your d.* file. One side-effect
of this is that the special files for AT&T and Bellcore *.a.* and *.b.*
will no longer be distributed; if you want records of them, save this
month's postings somewhere.
Note that we want to keep the d.* files small. As such, we only want
to know about your domain gateways. There is no need to list the contact
information for all your internal machines; we can go through the domain
contact if necessary. Similarly, domain mail can be delivered through
your gateways; there is no need for information about internal machines
or subdomains. Thus, large companies like AT&T, Tektronix, and HP should
be planning for the elimination of their huge lists of UUCP machines in
the u.* files and replacement by a small domain entry in the d.* file.
We do intend to offer a "we reserve these UUCP names" service, by listing
ONLY the UUCP names in the d. entry, for example:
ATT-NAC = {ihnp4, cbosgd, ... }
cbosgd: ATT-NAC(DIRECT)
which reserves the name and ensures that all such hosts are reachable.
If you need assistance in setting this up (or would like input into the
process) please let us know.
Mark Horton
Director, The UUCP Projectreid@decwrl.DEC.COM (Brian Reid) (12/03/86)
I suppose that it is progress that the u. files are being phased out. To my mind the only real problem with them was the product of size and frequency of posting. The thing that I am wistful about is that I have just finished writing a very elaborate program that can make high-quality geographic maps of USENET, using the #L and #U fields. This information is not present in the d. files, and in the case of the #L field it is often meaningless, since domains do not have a specific geographic location. The u. files, though intended for mail routing maps, serve an immensely valuable purpose as a "white pages" directory; the d. files cannot possibly provide this information. It certainly would be nice if there could be posted, perhaps once or twice a year, files that constitute a "site directory" rather than a "mail routing map", for such ancillary purposes. Brian Reid
avolio@decuac.DEC.COM (Frederick M. Avolio) (12/03/86)
In article <6685@decwrl.DEC.COM>, reid@decwrl.DEC.COM (Brian Reid) writes: > ... > The thing that I am wistful about is that I have just finished writing a very > elaborate program that can make high-quality geographic maps of USENET, using > the #L and #U fields. This information is not present in the d. files, and in > the case of the #L field it is often meaningless, since domains do not have a > specific geographic location. > > The u. files, though intended for mail routing maps, serve an immensely > valuable purpose as a "white pages" directory; the d. files cannot possibly > provide this information. I agree with Brian. While the UUCP `map' is getting (or has gotten) unwieldy, it does provide useful information. The location for each site, is the obvious one. For Brian's purpose, of course, but also it is used to point people to possible UUCP links in their area. Rather than tossing out all entries for all sites in, say, AT&T, excepting cbatt (or whatever), it'd be nice to have a way to eliminate entries for many sites at the same location. This is different than saying "in the same domain." I cannot imagine that the suggestion is really "For all X in X.domain123 remove all entries except where X == domain authority for `domain123'." This would certainly produce terrible routings of mail over the phone lines. I know many folks in the UUCP Project work for AT&T but.... :-). I think clarification is in order. (I believed that I was the only one bewildered, but Brian is a pretty sharp guy, so if *he* doesn't quite get it there must be something wrong. Fred
rs@mirror.UUCP (12/04/86)
Perhaps something like quarterly postings of the "u." files
where only the "#" lines appear is a good idea.
--
Rich $alz "Drug test p**s me off"
Mirror Systems, Cambridge Massachusetts rs@mirror.TMC.COM
{mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!rspiet@mcvax.cwi.nl (Piet Beertema) (12/08/86)
>I agree with Brian. While the UUCP `map' is getting (or has gotten) >unwieldy, it does provide useful information. So do I. And it's information that's often requested and that should be up to date. >...it'd be nice to have a way to eliminate entries >for many sites at the same location. Use the multi-name entries for sites that fall under one "administrative" heading: #N foo, bar, xyz or "hide" them behind some "main" site, so they won't have to show up in addresses (and thus the maps) at all. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl or mcvax!piet)
duncan@vuwcomp.UUCP (Duncan McEwan) (12/12/86)
Various recent articles have suggested that even as the map gets smaller due to "domainisation", it would be nice to retain the "#" lines as a directory of sites. It was suggested that this info could be circulated maybe two or three times per year, but... In article <1444@mcvax.cwi.nl> piet@mcvax.UUCP (Piet Beertema) writes: > > > I agree with Brian. While the UUCP `map' is getting (or has gotten) > > unwieldy, it does provide useful information. > > So do I. And it's information that's often requested and that should be up > to date. The domainisation of the map will reduce the size of the routing info that *has* to be posted regularly, but keeping the "directory" info up to date by frequent postings would defeat the whole purpose of the exercise. We are relatively new to the net so I have not seen this brought up before, though it probably has. Anyway... Would it be possible to post diffs to the directory information, to keep it as up to date as it currently is, while also reducing the volume of posting. Any new sites joining the net should be able to get the whole directory from their neighbour (if the neighbour doesn't get mod.map, the new site wouldn't get the current regular monthly posting anyway...). I guess this may mean more work for the map coordinators in generating the diffs, but this could be reduced by having map updates submitted as diffs to the previous in the first place. There need be little extra work for other sys admins, since the directory postings could be packaged up as shell scripts that automatically applied the diffs via "patch" (or since not everyone has patch - ed). > > ...it'd be nice to have a way to eliminate entries for many sites at > > the same location. > > Use the multi-name entries for sites that fall under one > "administrative" heading: > #N foo, bar, xyz > or "hide" them behind some "main" site, so they won't have > to show up in addresses (and thus the maps) at all. The main problem with this is that all the sites don't get to fully publicise themselves. When we finally get properly domainised, we will only need one entry for our campus for routing purposes. But the map entry #N vuwcomp, vuwisor, dsiramd ... #O Department of Computer Science, Victoria University of Wellington doesn't really say much about vuwisor and dsiramd ... -- Duncan McEwan ACSnet : duncan@vuwcomp.nz UUCP : "...!{alberta, ubc-vision}!calgary!vuwcomp!duncan" "You can always tell when politicians lie ... their lips move!" - Max Headroom