BITNIC made the decision to add the DISTRIBUTE option to the NODMGT-L list because NODMGT-L could immediately take advantage of the entire Revised LISTSERV server network for relaying contributions. This was a system solution. If it worked on one list it would be tried on others. An advantage to this over peering was to not have to worry about peer linking to the wrong list and possibly creating a loop. For one list reducing this chance of error is nice, for 40 lists this is worthwhile. We chose the NODMGT-L list in particular because at BITNIC it was not already "PEER" linked with any other list, so delivery performance could only improve on that list. (The LIAISON list is the only BITNIC list with a true peer to RUTVM1.) We were asked if the pseudo-peer lists which appear as individual subscriptions on the list (NODMGT-L@XXX) would cause a problem. Our answer was, it would see pseudo-peers as any other subscription and it would be the decision of the psuedo-peer list maintainer to continue to maintain their lists or to subscribe their users to the main list. So adding DISTRIBUTE to a list that never had real peers will not worsen the way subscribers of pseudo-peers interact with the list and access to notebooks would be the same as before. The real question, as Jose Maria pointed out, is not peering versus distribute. Rather it is, should we use peers in addition to distribute. At this time, BITNIC lists will not be peered. The primary objective was to improve mail distribution, and DISTRIBUTE does this. If the DISTRIBUTE jobs prove to be large and slow, then peering should be reconsidered. The security aspect of peering is not favorable, it is possible to create loops. With DISTRIBUTE only the contribution end is centralized, meaning, once the job is relayed to the next node it doesn't matter if the central node is down. --Judith Molka BITNET Network Information Center