It is all very well to explain why BITNIC's servers *had* to be shut down
to alleviate the backlog at critical network links, but that doesn't
address the issue I raised, namely, that LISTSERV, in particular, need
not place an appreciable load on any of the critical links.  Surely, in
view of the evident crisis, this would be a very propitious time to link
the BITNIC LISTSERV with the many available peer servers throughout the
network.  The advantages are obvious:
 
 1. BITNIC could immediately shift subscribers to the peer servers.
 2. Mail to one of the BITNIC lists would generate only *one* copy over
    each of the critical links.
 3. Mail sent originally to one of the peer servers (i.e., mail other
    than a reply to a previous message) would already have been
    distributed to subscribers downward of the corresponding critical
    link to BITNIC and so would not generate any return traffic at all.
 4. BITNIC could legitimately delegate the responsibility for archiving
    list traffic to one or more of the peer servers, thereby cutting off
    another source of load on the critical links, namely, file requests.
 5. BITNIC could automatically assign new subscribers to their nearest
    peer server, thereby avoiding the necessity of close human scrutiny.
 6. BITNIC could even legitimately restrict the file server aspects of
    its LISTSERV.  For example, the usual memo files describing all the
    aspects of LISTSERV could be replaced by short messages listing the
    peer servers and suggesting that requests be referred to the nearest
    one.
 
Naturally, all this might take some negotiation, but it shouldn't take
long to put into effect.
                                       JFC