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