But, Judy, people want peers NOT because of traffic (as you say this is quite irrelevant when using mail-via=distribute) but for some other IMPORTANT reasons, mainly: * NOTEBOOKs. It is not nice to have to request a notebook from BITNIC when the intercontinental lines are very busy. In fact for some countries this is a REAL problem. For example, in some weeks I will be in charge of the DEARN Listserv. As you probably know, Germany has volume-based line traffic tarifs. This means that we simply CANNOT afford that German users request notebooks from BITNIC -- we will have to create peers (or pseudo-peers) for *every* BITNIC list with a minimum number of subscribers and tell German users to request NOTEBOOks from DEARN, not BITNIC. Please note that this is an economical problem, not a question of technical or metaphysical opinions. * DATABASE. When 1.5m will be distributed, every LISTSERV will automatically offer DATABASE capabilities for each list for which it keeps notebooks. The access rights for open lists (as NODMGT-L, LIAISON, etc) will be = ALL --> this means that every user in the world would be forced to do notebook database searchs on the BITNIC LISTSERV --> a LOT of overhead for the BITNIC server (and I'm not considering the message traffic overhead). It would be much better if every region was served by a near LISTSERV. I will not speak of user-friendliness or about the problems for users that receive mail from a server and have to send it to another one, nor about list reliability when some link goes down. In any case, I don't see what problems could be caused by normal peering. I think that some other LISTSERV postmasters have already made such an offer several times, but anyway I'll repeat it: You can eliminate the irregularities in pseudo-peers by simply creating full peers. You can be, if you so desire, the ONLY owner of all lists that were created at BITNIC, and, at least in my site, I will never touch your lists and headers, so that you can make what you want with them (except for notebooks, of course). I think that most postmasters for listservs that currently have redistributions would agree on such a compromise. On the other hand, I will offer (and probably much more people too) any required technical assistance to set up the lists. I don't think this can be made more reasonable. In any case, please remember that for us having local lists here (as peers or as pseudo-peers) is something we are *forced* to do. Regards, Jose Maria P.S. I'd like to hear the opinions of other involved postmasters. ---------------------------- Text of forwarded message ----------------------- Received: (from DEARN.BITNET for <[log in to unmask]> via BSMTP) Received: (from MAILER@DEARN for MAILER@DBNGMD21 via NJE) (M-RSCS1312-1312; 56 LINES); Wed, 25 Nov 87 11:01:09 CET Received: by DEARN (Mailer X1.24) id 1307; Wed, 25 Nov 87 11:00:44 CET Date: Fri, 20 Nov 87 09:07:49 EDT Sender: BITNIC BITNEWS List <BITNEWS@BITNIC> From: Judith Molka <AKLOM@BITNIC> Subject: Global AFD subscription & Mail-Via Distribute To: Jose Maria Blasco Comellas <BLASCO> *** Irrelevant parts of the message deleted *** BITNEWS...Mail-Via= Distribute....11/20/87 place for further discussion: NODEMGT-L@BITNIC Many of the lists on LISTSERV@BITNIC with a subscription of more than 50 members will be sending contributions using "Mail-Via= Distribute". The distribution function of LISTSERV allows us to use all of the LISTSERVers on the LISTSERV backbone. Therefore mail is distributed locally and only one copy is sent to the next LISTSERV determined by internal algorithms to be a distributor for subscribers in its area. Using the Distribute function also has the advantage of almost no administrative overhead by list owners. Before using Distribute, many sites created local distribution lists for equivalent BITNIC lists. For example, UG-L@UGA was created to send UG-L mail to local subscribers. UG-L@UGA was a subscriber on the UG-L@BITNIC list and all subscribers sent mail to the root of the UG-L list, to BITNIC. One of the primary reasons for doing this was to reduce traffic, which the Distribute function now handles. Although there may be other advantages to retaining a local sub-list, owners of sublists are welcome to send back their subscribers and have them added to the main lists. Last, owners of sub-lists should set "ACK= No" for sub-lists since the numbers will not be all encompassing and many messages are being distributed. --Judith Molka, Network Services Consultant, BITNET Information Center