FidoNews is published weekly by the International FidoNet
Association as its official newsletter. You are encouraged to
submit articles for publication in FidoNews. Article submission
standards are contained in the file ARTSPEC.DOC, available from
node 1:1/1. 1:1/1 is a Continuous Mail system, available for
network mail 24 hours a day.
Copyright 1989 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
Fido and FidoNet are registered trademarks of Tom Jennings of
Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and
are used with permission.
We don't necessarily agree with the contents of every article
published here. Most of these materials are unsolicited. No
article submitted by a FidoNet SysOp will be rejected if it is
properly attributed and legally acceptable. We will publish
every responsible submission received.
Table of Contents
1. ARTICLES ................................................. 1
News about the ANEWS echo ................................ 1
SEAlink and Wazoo -- Benchmark Results ................... 2
Save money the EASY way! ................................. 11
Internetwork Gateway Policy Revisited .................... 13
InterNet Relations - A Rebuttal .......................... 15
IBM Offers free system Board to 50Z Owners ............... 16
Notes on proposed Internetwork Policy .................... 18
2. LATEST VERSIONS .......................................... 25
Latest Software Versions ................................. 25
3. NOTICES .................................................. 28
And more!
FidoNews 6-52 Page 1 25 Dec 1989
This is just a short note to inform you about the ANEWS echo.
ANEWS, or News of the US and World, has been in existence for
about 2 months. In that time it has grown considerably.
What is ANEWS? ANEWS, an acronym for alternative news, is a
current events/news related echo. It contains general news
stories and interesting news items that are either skimmed over
by the normal media or which are not covered at all. ANEWS
contains both national and international stories with emphasis
on social, labor and environmental issues. ANEWS stories range
from single-screen news briefs to articles that are several
screens long.
So if you would like some fresh news online, and don't want
the cost or the blandness of the mass-produced USA Today online
newspaper, look into ANEWS. ANEWS averages 40-60 messages per
week and is available in many parts of the country. For more
info contact the ANEWS moderator, Karl Frederick at 1:141/552.
Area Tag : ANEWS
Area Name: News of the US and World
Moderator: Karl Frederick @ 1:141/552
-----------------------------------------------------------------
FidoNews 6-52 Page 2 25 Dec 1989
Thom Henderson, 520/1015@AlterNet
System Enhancement Associates, Inc.
SEAlink and Wazoo
Benchmark Results
We've done many benchmark tests over the years. Obtaining
accurate benchmark data was often an important part of our
consulting practice. In recent years we've done a number of
benchmark tests of FidoNet-related technology, and we've usually
reported the results of those tests in FidoNews. Our previous
reported benchmark compared the SEAlink and Zmodem file transfer
protocols, and were reported in FidoNews volume 5, issue number
19 (9 May 1988).
The purpose of that benchmark was to compare the efficiency of
the actual file transfer protocols themselves. The purpose of
our latest benchmark was for the somewhat different purpose of
comparing two different network mail session protocols: FTS-0007
using adaptive SEAlink Overdrive, and Wazoo using Zmodem.
Since the point of this benchmark was to measure the session
protocols themselves in real-world, high speed file transfers,
our tests all involved shipping files over normal voice-grade
lines using the most recent available models of U.S. Robotics
Courier HST modems ("14.4" models), which were loaned to us by
U.S. Robotics for this test. The software employed consisted of
the latest versions of the two programs most widely considered as
representative of the different techniques (SEAdog 4.51b for FTS
with SEAlink/Overdrive, and Binkley 2.30 for Wazoo).
It was observed that on all trials the software was always able
to quickly saturate the data channel (which can be observed by
noting that the transmitting system is being "paced" by its
modem, while the receiving system is NOT pacing its modem), and
hence limitations of either particular implementation are
minimal. Furthermore, the data transmitted in all tests
consisted of compressed data, which reduced any effects resulting
from data compression performed by the modems, while also more-
actual data transferred was identical between the two different
programs.
The first run consisted of having each program send one file, of
graduating size, and timing the total connect time of the
telephone call. For example, each program was told to transfer
one file of 100 blocks (12,800 bytes), then each was told to
transfer one file of 200 blocks (25,600 bytes), and so on in
increments of 100 blocks up to a maximum size of 2,000 blocks
(256,000 bytes). The following data was collected:
The times are given are the total connect time in seconds between
the sending and receiving system. These numbers are then treated
to linear regression analysis (least-squares method) to produce a
slope and intercept. This treatment assumes that the data is
basically linear, and can hence be expressed with the formula:
y = Ax + B
where "x" is the number of blocks, "y" is the time taken in
seconds, "A" is the slope, and "B" is the intercept. In other
words, "A" is the time in seconds to transmit one block, and "B"
is the overall session overhead in seconds. If the data is truly
linear, then A and B will be constants.
The degree of fit can be measured by the correlation coefficient.
The higher this number is, the better the fit is, with a
coefficient of 1.0 indicating a perfect fit. The correlation
coefficient for this data set is better than 99% in both cases,
so we can be confident that our data truly is linear and that it
matches our calculated formulae quite well. The slightly greater
deviation of the Wazoo numbers can probably be attributed to the
greater complexity of Zmodem causing more variable results.
FidoNews 6-52 Page 4 25 Dec 1989
As can be seen, a SEAlink-based session is slightly faster when
transmitting data (0.002 seconds per block, or 16 seconds per
megabyte) and has considerably less fixed overhead (7 seconds per
session).
For our next run we wished to compare the per-file overhead of
the two protocols. This test consisted of sending files of 100
blocks (12,800 bytes). We told each program to send one file,
then two files, and so on up to twenty files, and obtained the
following data:
As you can see, we again have a reasonable fit of formula to
reality. In this situation the slope is of interest, as it gives
the time in seconds to transfer one file of 100 blocks. From
table 1 we calculate the time required by each protocol to
transfer 100 blocks of data (multiplying the time per block by
100). Subtracting that number from the time required to send one
file of 100 blocks gives us the per-file overhead, as follows:
FidoNews 6-52 Page 5 25 Dec 1989
Wazoo SEAlink
Time per 100 block file: 10.698 9.997
Minus time per 100 blocks: 8.328 8.129
Equals overhead per file: 2.370 1.868
Thus we can see that a SEAlink-based session takes roughly half a
second less to negotiate each file than does a Wazoo-based
session.
For our next benchmark run we tried something a bit unusual that
had not originally been planned for this test. We included it
partly out of curiosity, and partly because we knew that it would
not take long to collect the data. This run was essentially the
same as the previous run, except that the file being transmitted
always existed on the target system in advance. Hence, on each
and every transfer the receiving system immediately "synced to
the end" and refused the file. The following data was collected:
Table 3: Multiple files of 100 blocks each, pre-existing
In this series Wazoo showed slightly better performance than
SEAlink, though with a slightly greater deviation in the data
than we have had thus far. According to this series, it takes
about 0.06 seconds less to not transmit a redundant file when
using Wazoo instead of SEAlink.
We've introduced a new number in this table, dubbed "crossover".
This is the value at which both methods will yield the same
result. In other words, if the formulae are correct, then at 76
such file transfers the greater per-file rate of Wazoo will
overcome its greater session overhead, and it will become faster
overall than a SEAlink-based session.
We have not reported the crossover for earlier benchmark runs
because the data was divergent. That is, the data indicated that
under those conditions Wazoo would never overcome its greater
per-session overhead.
This brings us to our final benchmark series, which tests the one
great strength of Wazoo, and its only practical difference on a
day-to-day basis. That is, Wazoo uses a much more time-efficient
file request mechanism than the file-by-file negotiation of a
SEAlink-based session.
This run was similar to our second run in that each session
involved the transmission of one or more files of 100 blocks
(12,800 bytes) each, except that during this run the files were
requested rather than sent. In other words, we told each program
to request one file, then two files, and so on up to twenty
files. The following data was collected:
Table 4: Requesting multiple files of 100 blocks each
From table 2 we can obtain the time required for the transfer of
one file of 100 blocks, which then by subtraction yields the
following:
Wazoo SEAlink
Time per file request: 11.132 14.091
Minus time per 100 block file: 10.698 9.997
Equals overhead per request: 0.434 4.094
This resulted in our only surprise during this benchmark series.
We knew that Wazoo would have a lower per-request overhead, but
we had not anticipated that the difference would be as much as
3.7 seconds per request.
Even so, one must do five or more requests in a session before
the difference can overcome the greater inherent overhead of a
Wazoo session. We conclude that the difference would be
significant primarily in large GroupMail sessions where StarLink
was not being employed.
Summation
=========
The results of all of this can be tabulated as follows:
Wazoo SEAlink
FidoNews 6-52 Page 8 25 Dec 1989
Session overhead: 18.358 11.342
Time per 100 blocks: 0.083 0.081
Overhead per file: 2.370 1.868
Overhead per file request: 0.434 4.094
Conclusion
==========
Overall, we find a SEAlink-based session to be far more efficient
than a Wazoo-based session, with the sole exception of file
requests. We would further conclude from this data that the most
efficient session of all would be a SEAlink-based session
employing the Wazoo file request mechanism (which is certainly
possible), since it would take advantage of the more efficient
request mechanism while also enjoying the more efficient file
transfer protocols and lower overall overhead of a SEAlink-based
session.
Such a change would not be without cost, as it would sacrifice
the targeted-request capability of the SEAlink-based file request
mechanism (and in addition, for us at least, would involve
difficulties relating to backwards compatibility with existing
customers). However, it would be quite possible for a mailer to
honor BOTH sorts of requests -- one for targeted requests, and
one for non-targeted requests -- and thus acheive the best of
both worlds. Hence, we intend to move in that direction in the
future. We can but hope that other developers will see fit to
follow suit.
-----------------------------------------------------------------
FidoNews 6-52 Page 9 25 Dec 1989
COMPUTER INFORMATION MONTHLY NEWS
=================================
This is the Official Announcement of what may very well be
the first of it's kind of magazine. I have searched every
possible avenue for a like product and have so far been unable to
find one. For several years now I have accomplished a monthly
news letter, well several months ago, I started looking at a new
approach to the conventional news letter. I was tired of having
to type them out or print them out to a printer. An after
several months of experimentation I developed a program which
is executable on IBM MS-DOS machines.
This computer program offers all the features of a normal
magazine in paper form. Feature articles, special announcements,
product reviews, editors corner, business and BBS advertisement
screens. At present there are approximately 200 (79x23) screens
available in this magazine. Another feature is it is in full
color, from the front page, to the opening index. A lot of time
has gone into the development of this program and the Premier
Issue Date is currently scheduled for 15 Jan 1990.
This program will be offered to Computer Users as FreeWare,
at this time there is NO plans to charge a subscription price,
but this option may very well be exercised in 1991. Since this
program is being offered as FreeWare, it is an absolute necessity
to have a distribution system. I would like to make this program
available to as many SysOps and Users as possible. In doing so
it will cost Me a little extra to dissiminate the program in an
ARCED version to BBS's systems. Since there are over 6000
available systems I would like to see your help in passing this
program around.
If you as a SysOp would like to make this program available
to your users, you may File Request the Magazine each month
effective 10 Jan 1990 using the file name CIMN-V##.ARC, with ##
being the monthly issue (01-Jan, 12-Dec). If you are a user and
would like to have access to this Magazine please ask your Local
Fido Net Sysop to obtain it. In some cases I will deliver a copy
to the Net Coordinator or the Regional Coordinator where the file
will be available for file requesting. If you would like a
personal copy of this file, you may also send a 5.25" floppy
formatted disk to the address provided below, along with a (SASE)
for return, or you may call Voice 1-505-865-8386 for further
details.
Remember this Program currently runs only on IBM or
compatable systems, and is Free to anyone interested in obtaining
a copy.
JAKE HARGROVE HIGH MESA PUBLISHING
13 OSAGE DR LOS LUNAS, NM 87031
FidoNews 6-52 Page 10 25 Dec 1989
COMPUTER INFORMATION MONTHLY NEWS
THE MAGAZINE OF THE FUTURE!
-----------------------------------------------------------------
FidoNews 6-52 Page 11 25 Dec 1989
I'm going to save YOU money!
It's very simple, really. You see, the new Front Door and
D'bridge versions no longer support SEAlink or BARK requests,
they supposedly support FTS-0001.
What does this mean to you? Well, it means one of two things.
If you're lucky, your transfer efficiency will ONLY go down to
about 35% at 9600 baud when one mailer calls another. *I* was
one of the UNlucky ones.
You see, I've been distributing nodelists all over the United
States and Canada for the past two months, but when the Front
Door people I called switched to the new Front Door, I found that
I was unable to send them files. You know what? They couldn't
send me files, EITHER. The lovely thing is that all these file
transfers were going on after everyone had gone to bed, so like
good little mailers, our systems would just keep calling, trying
desperately to carry out the commands we'd given them, i.e., to
send the files.
The way I figure it, the Front Door and D'bridge authors owe me
some bucks on my phone bill.
The really wierd thing about all this is that the old versions
run SEAlink and supported BARK requests really well. I've got a
half dozen Front Door people alone calling me long distance every
night for GroupMail, and THEY have no problems. So why take the
support out for a feature that was working?
Dare we call the reason (Shhh! Say it quietly!)...
"political"?
Nah, it couldn't be that, could it?
Now, here's where I back up my promise. The way you save money
if you're running Front Door is to NOT upgrade. That way you
won't be calling systems all night and either getting 3500 baud
thruput on your 9600 baud line or simply calling over and over
all night long. The new version will have the SEAlink and BARK
stuff back in (after all, they promised, didn't they? They've
had the spec for a MONTH now...), and you'll have all your other
bells and whistles, too.
If you're running SEAdog 4.5 or higher, you can save money this
way:
In your XLATLIST control file (or other equivalent software),
define a class for nodelist flag XX (WazOO update requests only),
thus:
FidoNews 6-52 Page 12 25 Dec 1989
Class Z XX
In your ROUTE-DOG file, put the following statements at the end:
Schedule ALL
HOLD Class-Z
That will insure that your mailer NEVER, EVER, calls a Front Door
or D'bridge system that's going to run up your phone bill. If
you're doing echomail with such a system, let HIM call YOU. If
he complains about the connections, or multiple calls just say,
"Hey, I didn't change MY software! Did YOU?"
* Submitted by Phil Buonomo, 1:107/583@FidoNet 520/583@AlterNet
-----------------------------------------------------------------
FidoNews 6-52 Page 13 25 Dec 1989
Thom Henderson, c/o 1:107/528
Chairman, International FidoNet Association
Internetwork Gateway Policy Revisited
I notice in FidoNews volume 6, issue 51 that a small group has
announced the creation of a new (and lengthy) Policy Document on
how internetwork gateways may or may not be done. Fortunately
the proposed (newly established?) policy meets Tom Jennings'
criteria of a "good policy". It is emminently ignorable.
In essence, some unspecified group appoints one person to be in
charge of all internetwork gateways. Said person then regulates
all gateways to ensure that they meet various criteria as
established by the policy document and by the unspecified small
group. I suppose this means that the various people now running
Usenet gateways must ask approval and seek certification if they
wish to continue in their activities.
Fortunately, as I said, it is a very ignorable policy. If you
are running a Usenet or othernet gateway, or if you wish to do
so, you can go right ahead with no worries. The reality of
FidoNet that this group seems to be overlooking is that as long
as you have the support of your NC (or your RC if you're an
independant), you can do pretty much anything you like and nobody
can really stop you.
But the real problem with this policy is not so much what it
says, as what it implies. It implies that there is some
unspecified group with no apparent mandate or means of selection
who are somehow empowered to make decisions on behalf of FidoNet.
It should be obvious by now that I don't really think that
unspecified groups like that are a good idea. I got roped into
one once (the original "interim board" of IFNA), but our very
first acts were directed at converting our "unspecified group"
into a VERY specified group with a democratically elected Board
of Directors with a known mandate to operate on behalf of the
FidoNet sysops (and somehow I've wound up STILL working on that!)
The test has been set. With much discussion and some disagree-
ment here and there, but with general consent overall as near as
I can tell. Any group or organization that wishes to represent
itself as "speaking for FidoNet" must first obtain a positive
mandate from the majority of FidoNet sysops. Passive "no voters"
count as a "no", because if the majority does not see a need for
a central organization, then there should not be one. IFNA is
undergoing this test. As I write this, the referendum is over
and the votes are being tallied. By the time you read this the
totals should be published.
FidoNews 6-52 Page 14 25 Dec 1989
One of two things will happen:
1) IFNA will receive a mandate, in which case this "proposed
policy" will be subject to review by all FidoNet sysops and
must meet with their (your) approval before it can go into
effect.
2) Or IFNA will not receive a mandate, in which case this
"unspecified group" must seek its own mandate before it can
presume to speak on behalf of FidoNet.
This goes below the level of voting on policy. Before anyone can
set ground rules for how a policy can be approved, they must
first have the authority to establish policy approval procedures.
-----------------------------------------------------------------
FidoNews 6-52 Page 15 25 Dec 1989
Date: 20 Dec 89 21:17:20
From: Walter Tietjen on 151/114
To: Tim Pearson on 286/703
Subj: FidoNews Article
Original in netmail - Copy to Vincent P. (1:1/1) for inclusion
in FidoNews
Isolation of the various political networks _WON'T_WORK_!! It
can make an accidental echomail `circular feed' _WORSE_
_ANY_ `circular feed' in echomail causes duplicate messages.
With full FidoNet/AnyOtherNet combined seen-bys and path-lines,
the duplicates caused by the `circular feed' are restricted to
the nodes in the closed loop of the `circular feed'.
With pure seen-by stripping at "approved inter-net echo-gates"
the duplicates originally caused by a `circular feed' are spread
to nodes _OUTSIDE_ the closed loop of the `circular feed'. The
path-lines if left intact still provide some limited ability to
manually trace & eliminate a circular feed.
If _BOTH_ the seen-bys and path-lines are stripped-out, there is
_NO_ method left available to track down a circular feed
involving dual-ID nodes which through accident receive an echo
from both sides of an internet echogate.
ALTERNATIVE PROPOSAL:
_ALL_ FTSC-compatible networks shall draw their "Net" numbers (of
<Net>/<Node>) from a _COMMON_ number pool thus insuring that an
AnyOtherNet address will _NOT_ interfere with echomail delivery
within FidoNet.
Future agreements between different FTSC-compatible networks
should address the fair & equitable sharing of echomail
distribution cost between multiple networks participating in a
shared echo.
Re: Private netmail replies to echomail messages:
By the use of "private" nodelists an artificial `zonegate' can
easily be set-up between the pure-FidoNet nodes in a local area
and a dual-ID system in the same local area who maintains an
address in the target AnyOtherNet.
-----------------------------------------------------------------
FidoNews 6-52 Page 16 25 Dec 1989
IBM Offers free system Board to 50Z Owners
Recently, certain users of the IBM Model 50Z PS/2 computer have
encountered problems using software which bypass the computer's
BIOS and attempt to send data to a serial port, according to
Cheryl Butcher, an IBM systems engineer in West Lafayette, Ind.
IBM has acknowleged the existance of a bug in the system board
which will halt the output process and leave users with a
useless machine.
The bug causes problems in use with such programs as Microsoft
Corp.'s Windows and Lotus Development Corp.'s Symphony by
keeping the software from properly accessing the PC's serial
port. IBM is offering a free replacement system board to users
who encounter this problem.
IBM has issued an engineering change for its IBM Model 50Z BIOS
to correct the problem in new machines, and has offered to
replace defective system boards thru December 31st, 1989.
Users of Microsoft's WORD 5.0 will also notice the problem,
which is how IBM originally became aware of the bug. "Microsoft
WORD 5.0 worked fine on all of our other machines except the
Model 50Z," said Bruce Fuller, and electrical engineer at Purdue
Universeity. "The only work around was to use WORD 4.0, which
is really not a solution."
IBM will replace system boards that qualify according to the
following chart:
The machine must have the following:
o Module ZM41 (located in the center of the system board) is
marked with part number 05fox3628.
o The serial number is one of the following:
Model 50Z 31: Model 50Z 61:
23-7134521 23-7634866
72-7072052 55-6667427
78-4223666 72-7617500
90-5011650 78-4704505
90-5602521
Users whose machines do not qualify for the system board
replacement should contact the software developers for patches,
Butcher said.
IBM officials recommend that users get in touch with their local
IBM representative for further information and assistance.
FidoNews 6-52 Page 17 25 Dec 1989
* Submitted by Phil Buonomo, 1:107/583@FidoNet 520/583@AlterNet
-----------------------------------------------------------------
FidoNews 6-52 Page 18 25 Dec 1989
Jack Decker
1:154/9, 11:154/8
NOTES ON THE PROPOSED INTERNETWORK GATEWAY POLICY DOCUMENT
In Fidonews 651 an article by Tim Pearson of 1:286/703
appeared, which described and presented a draft of an
Internetwork Gateway Policy document.
I would just like to point out a few observations on this
document. If past experience holds, most of this will fall on
deaf ears. It seems most sysops tend to ignore net politics
until it's their node number going down the tubes, at which
point they are pretty powerless to do anything about it. Well,
if that's what you want, fine. Just don't act so surprised
when you are on the outside looking in.
Now the question we should be asking ourselves is whether this
proposed policy will enhance communications, or inhibit them?
Most of us joined Fidonet because we wanted to be able to
communicate with a maximum number of people. A policy that
inhibits communications may stroke the egos of a few who wish
to be "in control", but it doesn't benefit most sysops within
the net.
The first thing to notice is the proposed method for adoption
of this document: "It is our intention to allow 30 days for the
receipt of input from the network at large. After that, the
final draft will be presented to the International Coordinator
for adoption."
Now you'd think that folks would by now realize that many
Fidonet sysops are totally opposed to the "control from on
high" operation of Fidonet. You have the opportunity to
comment, but do you have the right to say "I don't think there
is any need for this policy at all?" Probably not. If you
suggest changes, the Gateway Policy Development Committee may
decide to incorporate your suggested changes, or they may not.
But if you tell them "I sincerely fail to see any need for such
a policy, and would prefer that it not be adopted", I wonder if
they would listen?
Keep in mind that the "members of the Gateway Policy
Development Committee include: Bill Bolton, Steve Bonine, Randy
Bush, David Dodell, Rick Moore, Tim Pearson, Vince Perriello,
Tim Pozar, and Matt Whelan." Now I'm not saying that any of
these folks are bad people. In fact, I think most of them have
a vision of what Fidonet should be, and they think it's a good
vision. The problem is that in my experience, the vision of
some of these folks as to what Fidonet should be is almost 180%
degrees removed from what most of the "common sysops" I have
spoken to want from Fidonet. If you are familiar with the
names in the above list, you probably know what I'm talking
about. With a couple of exceptions, most of these folks have a
vision of Fidonet that is controlled from the top down, with
the individual sysops having almost no say in how the net is
FidoNews 6-52 Page 19 25 Dec 1989
operated. I'm sure that in their own minds, they are convinced
that this is the best way to "run a railroad", but others might
disagree (by the way, for what it's worth, you will notice that
Tom Jennings, the founder of Fidonet, is not on the above
committee. I've noted that he generally seems to not approve
of these efforts to exert additional political controls over
those using Fidonet technology).
Now rather than simply take snipes at the people involved in
this proposal, I'd like to point out some problems with the
proposal itself. Some of these problems also exist in Policy4,
by the way.
The first is that any time we get into domain gating (which is
what's really being proposed here), we are talking some major
software changes in the network. Or else we are talking about
having users add addressing information to messages manually,
or both. In this proposal it appears that we are talking both,
since not only will software be required to change addressing
information at the domain gates, but users will be expected to
add certain addressing information within the text of the
message itself. Folks, we're adding a lot of additional
complexity to the network here. Many sysops are of the opinion
that we should "Keep It Simple, Stupid" but there are a few
wannabe Usenet administrators in our net who would like to turn
Fidonet into a very technically complex network. If we gain
some real benefits from increased complexity, then the benefits
may outweigh the problems. But where are the benefits to the
average sysop here?
The power players in Fidonet have continuously and deliberately
ignored the simplest solution to the perceived problems...
assign each "FidoNet Technology Network" (FTN) a block of net
numbers for their use. Thus, within Zone 1, you know that any
net with a number between 100 and 399 (or in the 3xxx range) is
in Fidonet, while numbers from 400 to 799 are in Alternet, and
so on. It would be much easier to formalize an addressing
agreement between the other networks than to go through the
hassle of setting up domain gates, and that would not break
existing software, and would allow sysops to send mail to other
networks with a minimum of hassle.
The one thing we all agree on is that Zonegating (to alternate
networks) doesn't work... but if we go to "domain gates", we
will have many of the same problems we have with Zonegates. "A
rose by any other name"... However, instead of going for a
less complex, more easily implemented solution, the proposal
introduces even greater complexity. Why? Well, I submit that
it's because the great complexity, while doing little or
nothing to advance communications, does allow a certain few to
exert greater amounts of control over the network. Control
over what? Well, consider the following paragraphs from the
proposal:
FidoNews 6-52 Page 20 25 Dec 1989
"FidoNet is now gated into Internet via UUCP. It has
agreed to the terms and conditions necessary for membership in
and connectivity to the Internet multi-network "umbrella". One
obvious method for achieving connectivity to FidoNet (and a
whole host of other wide area networks) is for the Other
Network to apply to Internet for a gateway. Under this
scenario, the Other Network is bound by the terms and
conditions of Internet just as FidoNet is. In this peer
relationship, the terms and conditions stated in this document
are used by FidoNet to determine if Other Network message
traffic arriving at a FidoNet/Internet gateway will be accepted
into FidoNet."
Now please note that in the above paragraph, it seems to be a
given that Fidonet cannot dictate the terms and conditions
under which it will accept messages from the Internet. That
makes sense... Internet has been around a lot longer and is a
lot larger, and quite frankly, many of the folks in Internet
couldn't care less whether Fidonet is tied in or not. But if
you read the above carefully, something else is being stated
here. That is that if another network obtains connections to
the Internet quite independent of Fidonet, and follows all the
rules, regulations, terms and conditions of Internet, Fidonet
may still elect to refuse message traffic based solely on the
originating network. Who wants to bet that this provision
would first be used to exclude traffic that originated on
another FTN network?
Actually, this whole document hold forth different standards
for interconnection between a "FidoNet Technology Network"
(FTN) and "All Other Networks" (see sections 3.6 and 3.7).
Section 3.7 states:
"3.7 - Other Criteria (FTN Other Networks)
-----------------------------------------
Software allowing nodes in FTN Other Networks to simultaneously
participate directly in FidoNet as valid FidoNet nodes,
isolating the Other Network's addresses from FidoNet message
traffic (i.e., using only valid FidoNet addresses in FidoNet
message traffic) presently exists. This 'dual identity'
approach is the method FidoNet expects nodes in the FTN Other
Network will employ....."
In other words, if you are running FTN software you are
expected to have a Fidonet net/node number and to use it,
rather than the address of your primary network. No mention is
made of what you are supposed to do if you can't get a Fidonet
node number (for example, if you want to be a private, unlisted
node, since many of these have recently been excluded from the
Fidonet nodelist).
FidoNews 6-52 Page 21 25 Dec 1989
More from section 3.7:
".....the FTN Other Network must provide evidence of overriding
technical or social considerations, must show cause why these
considerations justify the establishment of a Gateway instead
of merely allowing its individual nodes to use the 'dual
identity' approach, and must satisfy FidoNet that such an
arrangement will be mutually beneficial."
And add in section 5.1:
"5.1 - Interpretation
--------------------
FidoNet retains the exclusive right to interpret the terms and
conditions stated herein based upon its representatives' best
understanding of those terms and conditions and upon its
knowledge of the original intent of the authors."
What we have here is Fidonet saying, in effect, that if you
choose to use FTN software, you had better join Fidonet and use
your Fidonet net/node number (and if for some reason you can't
get one, you can always take up stamp collecting, I guess).
Curiously, this only applies if you are using FTN software.
This could actually encourage software authors to make their
software slightly NON-FTSC compliant, so that users of that
software could rightly claim that they are not in an "FTN Other
Network" and obtain Gateway status on more favorable terms.
Then there's section 3.4:
"3.4 - Application of FidoNet Administrative Policy
--------------------------------------------------
For the purposes of applying FidoNet policy, FidoNet will
view the entire Other Network as a single FidoNet 'node' under
the control of the individual named as the 'Administrative
Contact / Responsible Party' (or an authorized agent thereof)
in the administrative agreement outlined in paragraph 3.3
above. All other systems and their users will be viewed by
FidoNet as users on the 'responsible party's' node for the
purposes of FidoNet official policy application.
FidoNet holds the operator of a FidoNet node responsible
(from an administrative policy standpoint) for the actions of
that node's users, subordinate 'point' systems, and the 'point'
system's users. FidoNet views single or multiple Other Network
Gateways as a single 'boss' node under the control of the
'responsible party' and will apply FidoNet official policy
accordingly. FidoNet reserves the right to sever links to one
or more of the Other Network's Gateways as its final remedy for
violations of administrative policy....."
FidoNews 6-52 Page 22 25 Dec 1989
I think the bottom line here is that we have a classic case of
what is termed "Imperialism" when nations are involved.
Basically, we have a large entity (Fidonet) saying that it will
not participate as an "equal" in the "global community" (except
in relationships with entities of larger size and status) but
that rather feels that it should be able to set policies for
smaller entities on a "take it or or leave it" basis... and the
"take it" option in this case looks more like a takeover!
It is my opinion that some (NOT all) of the folks on the
"Gateway Policy Development Committee" still view the alternate
networks as some sort of a "cancer" that should be cut out of
electronic networking. But, as I pointed out in a recent
message in the SYSOP echo, "We need more than one viable
network that uses Fidonet technology. What do you suppose
would happen if the Democrats and the Republicans (or the
Liberals, PC's, and NDP's for those of you in the Great White
North) were all merged into one political party? There would
be so much infighting that nothing would ever be accomplished.
Even our churches have found the need to divide into groups of
like-minded people rather than constantly bicker over minor
points of doctrine. So why do we, in a hobbyist communications
network, think that we can force sysops who hold widely
divergent views on how a network should be operated into one
mold?
"Rather than look upon alternate networks as an enemy of
Fidonet, as something to be harassed and suppressed, you should
realize that this is a place where those who don't agree with
you can go and leave you (and those who agree with you) alone
to get on with life. It never ceases to amaze me that folks
who in one breath say that the Fidonet nodelist is getting too
large and who are all for cutting out certain classes of nodes
(private nodes, etc.) will nevertheless turn around and
participate in the harassment, or the attempts to 'shun' those
in other nets. They don't realize that these nets COULD be the
SOLUTION to the problem, rather than the problem itself."
There is one other section of the proposed policy that deserves
some attention:
"3.5 - Supported Message Types
-----------------------------
FidoNet will grant Gateway interconnection for the
purposes of exchanging messages of the type defined above as
'Netmail' and optionally for the purposes of exchanging
messages of the type defined above as 'Echomail'. FidoNet will
not grant Gateway interconnection for the purposes of
exchanging 'Echomail' only. The ability to generate a private
and personal 'Netmail' reply to an 'Echomail' message is one of
the basic facets of FidoNet and cannot be compromised."
FidoNews 6-52 Page 23 25 Dec 1989
If you believe this, I've got a nice bridge to sell you...
Maybe this is how things should be in Fidonet, but that is not
how they work now, at least not in Zone 1. I'll have more to
say on this subject in an upcoming article, but for the
purposes of this discussion, let me ask a couple of questions:
1) If I'm in an alternative network that has a "Gateway" with
Fidonet, will I be able to just dump all my Netmail on the
Fidonet Gateway and let the Gateway operator worry about
sending it anywhere in Fidonet? Will anyone in Fidonet really
want to become a Gateway if they have to send Netmail their own
expense? Why should those in alternate networks have access to
such a "one stop" delivery point for Fidonet Netmail when those
who are in Fidonet enjoy no such privilege (except those
fortunate enough to be on one of the few nets that have
OGATEs)?
2) If Fidonet does NOT expect its "Gateway" systems to deliver
Netmail anywhere in Fidonet, then why do they expect the
smaller alternative networks to provide this capability? The
smaller the net is, the more of a burden this could become.
Also, this requirement could subject an alternate network
Gateway to what would amount to "terrorist tactics" by someone
in Fidonet, who could send large amounts of Netmail traffic to
the Gateway and require the gateway node to either deliver or
return it at his expense.
It is a well known fact to just about every sysop in Fidonet
that most sysops are in Fidonet to receive echomail, and could
care less if Netmail service disappeared tomorrow. But the
select few who do use Netmail regularly have made something of
an idol out of it, and refuse to recognize that most of the
sysops that have joined Fidonet in the last 2-3 years just
don't care about Netmail. Fine, but if they are so concerned
about Netmail, let them come up with a Netmail distribution
scheme that WORKS, instead of trying to convince everyone that
Netmail is so all-fired important by mere words. In the
meantime, I feel that this particular section is totally
inappropriate in this document.
There's a lot more that I find objectionable in this document,
but I fear I'm probably already pushing the limits for length
of a Fidonews article. I hope it's never adopted, or failing
that, that it undergoes some pretty serious revision first,
preferably by some folks who do not believe that Fidonet is at
the center of the universe.
Since I am probably spitting into the wind anyway, I will just
offer a few suggestion to those in the alternate networks:
Begin linking conferences with each other! Stop depending on
the Fidonet backbone for all your echomail traffic. Start
listing your nodes in the OPCN nodelist so you can communicate
with each other if you find yourself locked out of Fidonet
(contact 1:234/1 or 1:236/7 for information). Develop your own
independent links into networks such as Internet and Usenet. I
FidoNews 6-52 Page 24 25 Dec 1989
will be truly amazed if anyone actually heeds these warnings,
but at least I tried...
-----------------------------------------------------------------
FidoNews 6-52 Page 25 25 Dec 1989
Utility authors: Please help keep this list up to date by
reporting new versions to 1:1/1. It is not our intent to list
all utilities here, only those which verge on necessity.
-----------------------------------------------------------------
FidoNews 6-52 Page 28 25 Dec 1989
Thom Henderson 1:107/528 Chairman of the Board
Les Kooyman 1:204/501 President
Fabian Gordon 1:107/323 Vice President
Bill Bolton 3:3/0 Vice President-Technical Coordinator
Kris Veitch 1:147/30 Secretary
Kris Veitch 1:147/30 Treasurer
IFNA COMMITTEE AND BOARD CHAIRS
Administration and Finance *
By-laws and Rules John Roberts 1:385/49
Executive Committee (Pres) Les Kooyman 1:204/501
International Affairs *
Membership Services Jim Vaughan 1:226/300
Nominations and Elections Steve Bonine 1:1/0
Public Affairs David Drexler 1:147/30.20
Publications Irene Henderson 1:107/9
Technical Standards Rick Moore 1:115/333
Ethics *
Security and Privacy *
Grievances *
* Position in abeyance pending reorganization
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Courtney Harris 1:102/732 Don Daniels 1:107/210
11 John Rafuse 1:12/900 Phil Buonomo 1:107/583
12 Bill Bolton 3:711/403 Mark Hawthorne 1:107/238
13 Fabian Gordon 1:107/323 Tom Jennings 1:125/111
14 Ken Kaplan 1:100/22 Irene Henderson 1:107/509
15 Kevin McNeil 1:128/45 Steve Jordan 1:206/2871
16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628
17 Kathi Crockett 1:134/30 Dave Melnik 1:107/233
18 Andrew Adler 1:135/47 Jim Hruby 1:107/536
19 Kris Veitch 1:147/30 Burt Juda 1:107/528
2 Henk Wevers 2:500/1 Karl Schinke 1:107/516
3 Matt Whelan 3:54/99 John Roberts 1:147/14
-----------------------------------------------------------------
FidoNews 6-52 Page 30 25 Dec 1989
Membership for the International FidoNet Association
Membership in IFNA is open to any individual or organization that
pays a specified annual membership fee. IFNA serves the
international FidoNet-compatible electronic mail community to
increase worldwide communications.
Member Name _______________________________ Date _______________
Address _________________________________________________________
City ____________________________________________________________
State ________________________________ Zip _____________________
Country _________________________________________________________
Home Phone (Voice) ______________________________________________
Work Phone (Voice) ______________________________________________
Zone:Net/Node Number ____________________________________________
BBS Name ________________________________________________________
BBS Phone Number ________________________________________________
Baud Rates Supported ____________________________________________
Board Restrictions ______________________________________________
Your Special Interests __________________________________________
_________________________________________________________________
_________________________________________________________________
In what areas would you be willing to help in FidoNet? __________
_________________________________________________________________
_________________________________________________________________
Send this membership form and a check or money order for $25 in
US Funds to:
International FidoNet Association
PO Box 41143
St Louis, Missouri 63141
USA
Thank you for your membership! Your participation will help to
insure the future of FidoNet.
Please NOTE that IFNA is a general not-for-profit organization
and Articles of Association and By-Laws were adopted by the
membership in January 1987. The second elected Board of Directors
was filled in August 1988. The IFNA Echomail Conference has been
established on FidoNet to assist the Board. We welcome your
input to this Conference.
