informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/FIDONEWS/fido0617.nws
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

1887 lines
90 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Volume 6, Number 17 24 April 1989
+---------------------------------------------------------------+
| _ |
| / \ |
| /|oo \ |
| - FidoNews - (_| /_) |
| _`@/_ \ _ |
| International | | \ \\ |
| FidoNet Association | (*) | \ )) |
| Newsletter ______ |__U__| / \// |
| / FIDO \ _//|| _\ / |
| (________) (_/(_|(____/ |
| (jm) |
+---------------------------------------------------------------+
Editor in Chief: Vince Perriello
Editors Emeritii: Dale Lovell
Thom Henderson
Chief Procrastinator Emeritus: Tom Jennings
Contributing Editors: Al Arango
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 will be rejected which is properly attributed and legally
acceptable. We will publish every responsible submission
received.
Table of Contents
1. ARTICLES ................................................. 1
Reflections on the new Policy ............................ 1
POLICY4 Reaction ......................................... 11
Reflections on POLICY4 ................................... 14
2. LETTERS TO THE EDITOR .................................... 29
Message Encryption ....................................... 29
3. LATEST VERSIONS .......................................... 30
Latest Software Versions ................................. 30
4. NOTICES .................................................. 31
The Interrupt Stack ...................................... 31
FidoNews 6-17 Page 1 24 Apr 1989
=================================================================
ARTICLES
=================================================================
Vince Perriello
Fidonet 1:141/491
Reflections on the new Draft Policy document
I believe that the new Policy document is a good document. I
also believe that it has some important flaws and omissions.
Most of these are in the area of unnecessarily rigid or
arbitrary text. I've covered the areas I feel need to be either
further explained or corrected below.
This document should be corrected before the ratification vote.
But I feel that both the corrections and the vote should take
place as soon as possible. The author(s) of Policy4 have done a
good job addressing problems that have cropped up since the
prior version and we need to have it in force as soon as
possible.
[Beginning of quoted passages]
> The official language of FidoNet is English. All documents
> must exist in English. Translation into other languages is
> encouraged.
I thought this somewhat jingoistic until someone pointed out to
me that this had first appeared in a submission from Henk
Wevers. Maybe I have gotten too sensitive to the North American
bias issue. If Henk thought this necessary, then I'll go with
it. But why was it considered so important that it even
preceded the definition of Fidonet?
> FidoNet is an amateur electronic mail system. As such, all of
> its participants and operators are unpaid volunteers. From
> its early beginning as a few friends swapping messages back
> and forth (1984), it now (1989) includes over 5,000 systems on
> six continents.
What a difference five years makes. It's too bad we don't have
5,000 FRIENDS swapping messages back and forth <sigh>.
> FidoNet is not a common carrier or a value-added service
> network and is a public network only in as much as the
> independent, constituent nodes may individually provide public
> access to the network on their system.
Good. Though I would prefer that we also said something here
like "individual nodes providing commercial services using
Fidonet as a transport mechanism are acting solely for their own
purposes and not as a member or agent of Fidonet as a whole".
FidoNews 6-17 Page 2 24 Apr 1989
> FidoNet is large enough that it would quickly fall apart of
> its own weight unless some sort of structure and control were
> imposed on it. Multinet operation provides the structure.
> Decentralized management provides the control.
Now HERE's an interesting paragraph. You mean that the IC, the
Z1C and the Z1RC's are planning on relaxing the iron fist? The
use of the word "decentralized" seems to imply this. Good.
More power to them, er, to the Nodes and NC's I mean.
> In supporting points, the bossnode makes use of a private net
> number which should not be visible outside of the
> bossnode-point relationship except as the first entry in the
> ^aPATH line.
What's a ^aPATH line? Is this Echomail? Why are we talking
about specific Echomail implementation issues in Policy?
> Unfortunately, should the point call another system directly
> (to do a file request, for example), the private network
> number will appear as the caller's address. In this way,
> points are different from users, since they operate
> FidoNet-compatible mailers which are capable of contacting
> systems other than the bossnode.
May I infer from this that if a point makes a file request from
a node other than its bossnode that it is operating in a manner
which is consistent with Policy? This issue nearly brought the
BINKLEY echomail conference to its knees recently. Some clear
statement on the issue would be a welcome relief.
> A zone is a large geographic area containing many regions,
> covering one or more countries and/or continents.
This language is probably too restrictive. How about "which MAY
cover one or more ..."? I trust you agree that, for example,
the Soviet Union or (Mainland) China are so large they might
require multiple zones?
> FidoNews is a weekly newsletter distributed throughout the
> network by the coordinator structure.
I don't believe that the distribution is limited to
coordinators.
> It is an important medium by which FidoNet sysops communicate
> with each other. FidoNews provides a sense of being a
> community of people with common interests. Accordingly,
> sysops and users are encouraged to contribute to FidoNews.
(Newsletter Editor hat on) Thank you very much. (hat off)
> Contributions are submitted to node 1/1; a file describing
> the format to be used is available on many systems.
Why not say it's available on 1/1? And why not say 1:1/1?
FidoNews 6-17 Page 3 24 Apr 1989
There ARE other Zones, you know.
> Network boundaries are based on calling areas as defined by
> the local telephone company.
Not totally. Check out Net 132 in Zone 1, for example. It
includes at least two states and area codes.
> Even in the case of areas where node density is so great that
> more than one network is needed to serve one local calling
> area, a geographic guideline is used to decide which nodes
> belong to what network. Network membership is based on
> geographic or other purely technical rationale. It is not
> based on personal or social factors.
This makes a lot more sense than the preceding sentence. Maybe
the former should be scrapped or rewritten in favor of the
latter? Seems like what we really have is geography rightfully
taking precedence over local phone companies (which come in a
close second).
> Zone Mail Hour (ZMH) is a defined time during which all nodes in
> a zone are required to be able to accept netmail.
Might I suggest here you add a sentence? Such as " A given node
may use any method preferred by its operator to transfer mail,
but all nodes must be capable of falling back to the base
Fidonet protocol as defined in FTSC document FTS-0001"?
> The nodelist is a file updated weekly which contains the
> addresses of all recognized FidoNet nodes. This file is
> currently made available by the Zone Coordinator not later
> than Zone Mail Hour each Saturday, and is available
> electronically for download or file request at no charge.
Does this mean that 1:1/0 now allows file requests for this file
starting immediately after ZMH on Saturday?
> To be included in the nodelist, a system must meet the
> standards defined by this document. No other requirements may
> be imposed.
All the more reason to take FTS-0001's name in vain above. Did
you really mean to shut FTSC out here or was this just bad
language? If it was bad language, we'd best fix it. Like
"standards defined in this document or technical standards
ratified by the FTSC and accepted by the International
Coordinator" in place of "standards defined in this document"?
> In certain cases, the Zone Coordinators work as a council to
> provide advice to the International Coordinator.
When does the Council meet?
> The Network Coordinator is not required to provide a source
> for echomail.
FidoNews 6-17 Page 4 24 Apr 1989
No such statements were made about the IC, ZC or RC. Does this
mean that they ARE so required?
> (in discussion of Hubs)
> ... a network coordinator cannot delegate responsibility to
> mediate disputes.
Why not, as long as the NC will step in if the decision of the
Hub is not acceptable to all parties?
> The system operator (sysop) formulates a policy for running
> his board and dealing with users.
You meant "his or her", right? Also, how about cases where a
Fidonet node isn't a BBS? Or are we phasing those nodes out?
> The sysop must mesh with the rest of the FidoNet system if he
> is to send and receive mail, and the local policy must be
> consistent with other levels of FidoNet.
Here you meant to say "He or She", didn't you? I'll assume you
mean the policy of the board when you say "local policy" here.
So, let me see if this works. If the International Coordinator
states that messages about "foo" are considered annoying, then I
can't allow messages about "foo" on my system even if they are
in local-only message bases? Balderdash. Rewrite this part.
> The sysop is responsible for the actions of any user when they
> affect the rest of FidoNet. (If a user is annoying, the sysop
> is annoying.)
Does this mean that any user may get his sysop thrown out of
Fidonet with one well-placed message? Seems like the sysop
should be given an opportunity to correct, limit access, or
remove a user before a determination is made that the sysop is
being annoying due to the actions of a user.
> Any traffic entering FidoNet via a given node, if not from the
> sysop, is considered to be from a user, and is the
> responsibility of the sysop. This includes messages from
> point systems.
Seems fair, but please see the previous point. By the way, is
there any reason why this logic can't include BIDIRECTIONAL
gateways with so-called "Alternative Networks" which use Fidonet
technology?
> These levels act to distribute the administration and control
> of FidoNet to the lowest possible level, while still allowing
> for coordinated action over the entire mail system.
Exactly what we should have in Zone 1. Low-level ADMINISTRATION
and high-level COORDINATION.
> The sysop of an individual node can generally do as he
> pleases, as long as he observes the mail events, is not
FidoNews 6-17 Page 5 24 Apr 1989
> excessively annoying to other nodes on FidoNet, and does not
> promote or participate in the distribution of pirated
> copyrighted software or other illegal behavior via FidoNet.
How about if the sysop decides to do something completely legal
but blatantly commercial, and advertises access to Fidonet as a
valuable part of the service he or she (I try to stay gender
neutral myself) has to offer? Then for some reason a legal
proceeding is initiated due to some action this person has or
has not taken. Are we protected? Enquiring minds ...
> In order to understand the meaning of "excessively annoying",
> it is incumbent upon all sysops to occasionally re-read
> FidoNet policy. New sysops must familiarize themselves with
> policy before requesting a node number.
Too bad we can't have some kind of exam too, like they do for
drivers' licenses. But just having this here is something.
Please don't forget to make sure that NC's are familiar with
this section and take some steps to determine that the operator
of a new node has in fact read POLICY (though I have no idea
what those steps would be)
> A Sysop is responsible for all traffic entering FidoNet via
> his system. This includes (but is not limited to) traffic
> entered by his users, points, and any other networks for which
> he might act as a gateway. If a sysop allows "outside"
> messages to enter FidoNet via his system, he has a
> responsibility to ensure his system is clearly identified by
> FidoNet node number as the point of origin of that message,
> and a responsibility to act as a gateway in the reverse
> direction. Should such traffic result in a violation of
> Policy, the sysop must rectify the situation.
How come a Sysop can fix problems with gateways and points but
is considered annoying if she has an annoying user?
> FidoNet is an amateur system. Our technology is such that the
> privacy of messages cannot be guaranteed. Any sysop has the
> right to review traffic flowing through his system, if for no
> other reason than to ensure that the system is not being used
> for illegal purposes. Encryption obviously makes this review
> impossible. Therefore, encrypted and/or commercial traffic
> that is routed without the express permission of all the links
> in the delivery system constitutes annoying behavior.
I'm not saying that something doesn't need to be said about
routed encrypted messages. But I have a problem with this black
and white stuff. No room for interpretation. No room for any
kind of mitigating circumstances, such as pilot error. We may
be judged by future generations on the quality of our mercy.
> 2.1.6 Private Netmail
This entire section makes a lot of sense. Of course it reads
more like something out of a "guide to novice sysops" rather
FidoNews 6-17 Page 6 24 Apr 1989
than a Fidonet Policy and Procedures document. But I agree it
needs to be stated somewhere. Good show.
> If a sysop does not forward a message when he had previously
> agreed to perform such routing, the message must be returned
> to the sysop of the node at which it entered FidoNet with an
> explanation of why it was not forwarded.
OK. How about messages which are sent to a given node in error?
Is the receiving node obligated to either forward or bounce? It
appears that there's nothing to cover this here.
> Zone Mail Hour is the heart of FidoNet, as this is when
> network mail is passed between systems. Any system which
> wishes to be a part of FidoNet must be able to receive mail
> from any node in the nodelist during this time.
Sure wish you'd mention FTS-0001 somewhere.
> Echomail should not be transferred during ZMH.
That's a little stiff. I don't see any problem with ultra low
volume Echomail. Can we fix the language to make individual
interpretations possible for individual cases?
> User (BBS) access to a system is prohibited during ZMH.
Yeah!
> A system which is a member of a local network may also be
> required to observe additional mail events, as defined by the
> Network Coordinator. Access restrictions during local network
> periods are left to the discretion of the Network Coordinator.
Why not let the NC judge whether such things as Echomail
transfer constitute annoying behavior as well? You can see a
problem better when you're in the same town with the guy than if
you're a couple of states removed. Though the exceptions should
be few and far between.
> The rare exception to ZMH compliance is Private Nodes. Persons
> requesting private nodes should be supported as points if
> possible. A private listing is justified when the system must
> interface with many others, such as an echomail distributor.
> In these cases, the exact manner and timing of mail delivery
> is arranged between the private node and other systems. Such
> an agreement between a private system and a hub is not binding
> on any replacement for that hub. A private node must be a part
> of a network (they cannot be independents in the region.)
That all sounds good. I can think of other applications of
Private nodes, but your example is adequate.
> Private nodes are encouraged to honor ZMH.
I'm not quite sure why. As I see it, the main purpose of a
FidoNews 6-17 Page 7 24 Apr 1989
private node is to have a Fidonet mailbox with restricted
access. Since other systems will be able to contact the private
node directly only by prior arrangement, what's the point of
having the private node honor ZMH?
> It is considered annoying behavior to assist a system which
> was excommunicated in circumventing that removal from the
> nodelist. For example, if you decide to provide an echomail
> feed to your friend who has been excommunicated, it is likely
> that your listing will also be removed.
Hmmm. Would I be presumptuous to call this the Lee Kemp Clause?
You know, there are reasons other than what you envisioned. How
about this: a system is excommunicated because he doesn't
observe ZMH. So he decides to become a point off your system.
Does that mean you're history in Fidonet?
> Once you have located the network or region in your area, send
> a message containing a request for a node number to node zero
> of that network or region. The request must be sent by
> netmail, use address -1/-1, and include the following:
>
> 1) Your name.
> 2) The name of your system.
> 3) The city and state where your system is located.
> 4) The phone number to be used when calling your system.
> 5) Your hours of operation, netmail and BBS.
> 6) The maximum baud rate you can support.
So far, so good. Though I don't understand the insistence on
using -1/-1 for an address. I'm aware of an old default address
in Fido of -1/-1 and of an undocumented feature in one or more
current network mailers. But I'm also told that several
nets already have a preferred address other than -1/-1 which
they use for the purpose of new node applications.
> You must indicate that you have read, and agree to abide by,
> this document and all the current and future policies of
> FidoNet.
Yeah, right. Give me a break. Who on earth is crazy enough to
agree to abide by some future nonexistent document? Contact
your legal eagle and see if she thinks that any such agreement
is worth the oxide it's written on.
> Using a node number other than -1/-1 can cause problems for
> the coordinator involved. Simply assigning yourself a
> net/node number can be annoying, and can be grounds to reject
> your request.
See comment above regarding -1/-1.
> Never put an answering machine or similar device on your phone
> line while you are down. If you do, calling systems will get
> the machine repeatedly, racking up large phone bills, which is
> very annoying.
FidoNews 6-17 Page 8 24 Apr 1989
Why is it you use the magic phrase "annoying behavior" elsewhere
in cases where there are definite grey areas, and don't use it
HERE? A system that answers with a machine should be marked
DOWN! PERIOD! Make some effort to reach its owner, if you
can't then JUST MARK THAT SYSTEM DOWN!
> 3.1 Make Available Nodelists, Difference Files, and FidoNews
>
> Any Coordinator is responsible for obtaining and making
> available, on a weekly basis, nodelist difference files and
> FidoNews.
Well, which is it? In the heading, nodelists are mentioned; in
the accompanying text, they are not.
> In addition, a coordinator is required to forward any local
> policies he receives to the level above, and to review such
> policies. Although not required, common courtesy dictates
> that when formulating a local policy, the participation of the
> level above should be solicited.
This appears to be the only mention of local policy. Does this
mean that as long as it's not inconsistent with general policy,
that any local policy at all can be defined? With no consent
needed from the coordinators above?
> In addition, a new coordinator has the right to review any
> decision made by his predecessors for compliance with Policy,
> and take whatever actions may be necessary to rectify any
> situations not in compliance.
Does this include excommunication for cause (or refusal to do
so)? If so, we need some kind of statute of limitations.
>(From responsibilities of a Network Coordinator)
> It is also recommended, though not required, that you call a
> board which is applying for a node number before assigning it
> a node number.
As a USER? Why? If there are acceptability issues, they should
be documented here. If not, then what purpose would be served?
> You should use network mail to inform a new node of his node
> number, as this helps to insure that he is capable of
> receiving network mail.
That's the ticket. So why does an NC need to call a system
before granting a node number?
> You should to implement name changes ...
^^
Did this word just creep in?
> Policy, FidoNews, and the nodelist are the glue that holds us
> together. Without them, we would cease to be a community, and
> become just another random collection of bulletin boards.
FidoNews 6-17 Page 9 24 Apr 1989
So why doesn't a host need to have a full nodelist available any
more? Where does somebody get one if they need it?
> A Zone Coordinator is charged with the task of ensuring the
> smooth operation of his Zone. He does this by supervising the
> Regional Coordinators.
I hate that word "supervise". What place does the term
"supervision" have in an "amateur" network? By the way, it
doesn't seem to me that "coordinate" and "supervise" are the
same thing. So where can I find the description of the Zone
Supervisor?
>(from the section relating to Policy votes)
> Network coordinators are expected to assess the opinions of
> the members of their network, and to vote accordingly.
And what if they don't?
> If a number of alternatives are to be considered, they must be
> presented as whole documents, from which one is chosen.
What if more than one of them receives the requisite votes?
> A Policy amendment is considered in force if, at the end of
> the balloting period, it has received a majority of the votes
> cast, and has received a majority of the network-coordinator
> votes cast, and has received a majority of the regional-
> coordinator votes cast.
Let me get this straight. If 100% of the NC's vote in favor of
something but only 49% of the RC's do, then it fails? That's
democracy for ya. Can we at least make it a majority of one
plus a plurality of the other?
> In the case of multiple policy changes which are considered on
> the same ballot, a version must receive more than 50% of the
> votes cast to be considered ratified. "Abstain" is a valid
> vote in this case, effectively being a vote for not changing
> the current policy as it simply increases the number of votes
> required to ratify the proposed change.
This makes me even more certain that majority of one plus
plurality of the other makes sense. I don't believe in sleazy
voting tactics like this.
>(From Statute of Limitations clause)
> A complaint may not be filed more than 60 days after the date
> of discovery of the source of the infraction, either by
> admission or technical evidence. Complaints may not be filed
> more than 120 days after the incident unless they involve
> explicitly illegal behavior.
That's fine. Now let's say that the Coordinator finds in favor
of the person accused. Then the Coordinator leaves office. Can
the new coordinator reinitiate the proceedings, regardless of
FidoNews 6-17 Page 10 24 Apr 1989
the amount of time which has passed? Based on the earlier stuff
I pointed out, I would say that the answer is YES. That needs
to be addressed.
[End of quoted passages]
Those are the specific areas in which I saw problems in the
document. By and large, it's a good one, as I said above. I'd
like to see most of the changes proposed above in the final
version, though. Particularly the areas concerning FTSC. I
trust that the areas where annoying behavior is defined are
meant primarily to establish criteria for filing complaints and
not to lock a given Coordinator into a set course of action.
The reason I highlighted those areas was to make certain that
this was indeed the case.
I look forward to seeing language corrections and clarifications
added to the document, and to seeing it accepted by the *C's. I
can't encourage you enough to read this document yourself and to
discuss it with your fellow Sysops and with your respective Net
or Regional Coordinator. YOU are Fidonet. It's YOUR Policy.
Help make it the best Policy possible.
-----------------------------------------------------------------
FidoNews 6-17 Page 11 24 Apr 1989
Randall Greylock
Fidonet 1:321/202
Disclaimers
I was involved in the process
First off, I'm biased. Much of the work on this Policy 4 was
done while I was an RC, and I had some influence on the form of
the document.
However, I do not pretend to speak for the coordinator
structure.
I also have to apologize to the coordinators, for in making my
comments to them when initially requested, I skimmed one big
section (Policy ratification), and missed what I feel is one of
the biggest flaws in the document.
I've seen Vince's Article
I've also seen a draft of Vince's article. For the most part, I
agree with his comments, although in some cases, what seemed
obvious to me was not obvious to others. (This is basically the
same problem as exists in P3.)
Oh, and I'm writing in extreme haste. It's 22:45 right now, I
have to have this sucker in by 23:00. It hasn't been spell
checked, grammar checked, or seriously logic checked. Sorry.
Original Design Goals
Minimal Changes from P3
One of the major goals of P4 (during my tenure, at least) was a
minimal set of changes from P3. The more changes there are, the
more argument there will be.
My feeling is this goal has largely been met.
Clear Path to P(N+1)
Another primary goal was the definition of how we get from P(n)
to P(n+1). While this goal has been met, I share the
reservations Vince has on this section of the document.
All in all, though, I can live with it.
Casting In Policy The Learning From Precedent
Finally, much of what was not so much to change Policy, but to
refine it - taking things decided by dispute and putting them
FidoNews 6-17 Page 12 24 Apr 1989
into clear Policy language. Much of the new text is not new
policy, but the application of Policy.
Problems - Perceived and Otherwise
Dual Majorities
The democratic procedures have changed greatly since last I saw
P4. At that time, the concept of two kinds of majorities was in
place in order to balance geography against population. In order
for Policy to be put in place, it had to be ratified by a
majority of those voting, and a majority of the Zones. The
intention (which may or may not have been well served) was to
ensure that a broad geographic consensus be reached for Policy
changes.
The concept of dual majorities applied to the levels of FidoNet
does not seem to provide any protection against anything. It
leaves the system such that a very small number of sysops can
dictate network philosophy - i.e., the RC's essentially have veto
power over any Policy initiative.
I do not necessarily believe democratic procedures are the best
way to run a network. But I do believe the majority of the
network feels otherwise. The language as it stands is an affront
to that viewpoint. An argument can (and will) be made that the
RC's are in the best position to formulate and evaluate Policy.
Further argument can and will be made that most people don't
participate anyway. While there is merit to both of these
arguments, this is not a good reason to institionalize a caste
system in the decision making process.
Usage of the Word Annoying
During my involvement in the P4 formulation, the word annoying
and the phrase excessively annoying were used rather precisely.
Annoying behaviour is not, in and of itself, excommunicatable.
Excessively annoying behaviour is. Annoying behaviour can
CUMULATIVELY become excessively annoying if steps are not taken
to rectify it.
Unfortunately, given the lack of precision in the usage of other
terms and phrases in the document, this distinction may have
been lost. Somewhere along the line, it would be nice to have
some word other than annoying to describe the "lesser" mode of
the term.
References to Technical Standards Documents
The biggest problem with Policy in all its incarnations is that
what seemed obvious to the authors is not nearly so obvious to
the readers. This is particularly true in the case of technical
standards and their relationship to this document.
FidoNews 6-17 Page 13 24 Apr 1989
It seemed obvious that saying "One must be capable of receiving
netmail during ZMH" implied FTS-0001 compliance. There is a
flip side of this problem Vince fails to mention, however - to
the best of my knowledge, there is no official list of compliant
software. Further, there is a serious problem of existence.
Does FidoNet exist? Does a relationship between FidoNet and
IFNA exist? Does a relationship between IFNA and FTSC exist?
Does a relationship between FidoNet and FTSC exist? The answers
to these questions are not clear to me, and I'm not sure
hardening such relationships is the best way to clarify them.
There was, during my involvement, a feeling on the part of many
that we could not solve all the problems of the world, and we'd
be better off clearly saying how we should go about addressing
them than doing a bad job of addressing them in an environment
where the right to do so was unclear.
Also, there are some issues that are political as well as
technical. One of them is the appearance of "non-FidoNet"
address information in traffic flowing through FidoNet's routing
systems. Is it fair to impose the burden of another network's
routing information on nodes operating in an official FidoNet
capacity? Personally, I think not. No matter what, I do not
think this is a purely technical decision.
Similar arguments can be made about the -1/-1 new node number
request. The goal was to make it possible for hosts to be able
to honor requests for node numbers, while still being able to
maintain control of their systems. It is possible with many
mailers to close out unidentified systems, and regulate the
access of known ones. The goal was to provide a known number
for the request of a new node number to simplify the lives of
those hosts that wish to otherwise exclude unknown systems.
-1/-1 was chosen because of historical precedent. I suggest
that a single number like 1/32000 be used in its stead. (We
don't need yet another administrative entry in each net.)
Overall Reaction
Overall, I still urge any and all coordinators to ratify this
document. Even with the flaws, the existance of a clear
ratification process provides a mechanism for other issues to be
addressed in the future. The process has taken much too long as
it is, and has caused too much turmoil. Let's get the sucker
out the door, then take six months or a year to carefully
address many of the perceived problems of the net.
Specifically, I would leave aside the issue of commercialism
that seems to be sweeping the net lately - the current Policy
seems to have mostly worked, and rules should not be made in
haste. Many, many dates have been set and past for the
implementation of this document; I believe that the credibility
of the *C structure simply cannot take too many more election
dates set, missed, voted on, then overturned, all of which is
done with little public notice.
-----------------------------------------------------------------
FidoNews 6-17 Page 14 24 Apr 1989
Jack Decker
Fidonet 1:154/8 LCRnet 77:1011/8 NetWork 8:70/8
REFLECTIONS ON POLICY4
After reading POLICY4, I have a few comments I'd like to share
with you. I haven't had access to the SYSOP or IFNA echoes for
close to four months now (another result of ECHOPOL), so these
thoughts are not repetitions of anything I've heard there
recently. First, I'll take some of the parts of POLICY4 and
comment on them individually, then I'll close with some general
comments.
Starting near the beginning (a very good place to start!), we
find this small but significant (and somewhat confusing)
paragraph:
FidoNet is large enough that it would quickly fall
apart of its own weight unless some sort of structure
and control were imposed on it. Multinet operation
provides the structure. Decentralized management
provides the control. This document describes the
procedures which have been developed to manage the
network.
Highlight the words "unless some sort of structure and control
were imposed on it." The problem here is that most Fidonet
sysops that I've spoken to don't want structure and control
IMPOSED ON THEM from on high. It's strange that in America,
the land of democracy, the people in Fidonet would be forced to
live under a document that sounds like something that the
Russian government would issue (in pre-glastnost days, no
less).
1.2.3 Networks
A network is a collection of nodes in a local
geographic area. Networks coordinate their mail
activity to decrease cost.
This is mention #1 of geography. I'll get back to this later.
1.2.3 Regions
A region is a well-defined geographic area containing
nodes which may or may not be combined into networks.
A typical region will contain many nodes in networks,
and a few independent nodes which are not a part of
any network.
Mention #2 of geography. More later.
1.2.5 Zones
A zone is a large geographic area containing many
regions, covering one or more countries and/or
FidoNews 6-17 Page 15 24 Apr 1989
continents.
Mention #3 of geography. For those in other (non-Fidonet)
networks it also ignores current usage of zones, but then I
hear they're trying to come up with some spiffy new "Domain"
proposal that will once again break all existing software, so
the other nets won't have to (be allowed to?) use zones for
this purpose.
1.3.2 Geography
Each level of FidoNet is geographically contained by
the level immediately above it. A given geographic
location is covered by one zone and one region within
that zone, and is either in one network or not in a
network. There are never two zones, two regions, or
two networks which cover the same geographic area.
Why? Would the world come to an end if there were two nets in
the same geographic area? Maybe we ought to give AT&T the
northern U.S., Sprint the Eastern seaboard, MCI the West and
Southwest, and divide the rest of the U.S. among the other
long distance carriers. What's that got to do with anything?
Well, recent history should tell us that when you can only
obtain a service from one provider, they can charge whatever
they want, and often treat those they serve in any way they
like. When there is competition, or the ability to go to more
than one source for a service, the providers of that service
seem to be just a little nicer and more considerate.
Even where real competition doesn't exist, the fact that
competition is possible can make a big difference. If I had
the only gas station in a town and decided to charge $5 a
gallon for gas, you can bet that somebody would soon get the
idea that they would be a local hero if they opened a station
and charged only $1.50 a gallon. That thought would probably
keep me from charging totally ridiculous prices for my gas.
I know some are saying "That's fine for business, but what has
it to do with Fidonet?" Simple, human nature being what it is,
the same principles apply. If you have a net coordinator or a
regional coordinator who can tell people to do things his way
or get out of the net, or to accept the few services he chooses
to provide even though someone else might be willing to offer
more services, that gives the *C structure the ability to "play
dictator" to those under them. Of course, MOST *C's wouldn't
do that, but life can be no fun at all if YOU happen to be
under a heavy-handed *C.
If a node is in the area of a network, it should be
listed in that network, not as an independent in the
region. (The primary exception to this is a node
receiving inordinate amounts of host-routed mail; see
section 4.2). Network boundaries are based on calling
areas as defined by the local telephone company. Even
in the case of areas where node density is so great
FidoNews 6-17 Page 16 24 Apr 1989
that more than one network is needed to serve one
local calling area, a geographic guideline is used to
decide which nodes belong to what network. Network
membership is based on geographic or other purely
technical rationale. It is not based on personal or
social factors.
More geography. Also, who determines "calling areas as defined
by the local telephone company?" Some cities have a metro area
(where it's a free call to anywhere in that area from anywhere
in that area), but in other places calling areas overlap (for
example, everyone gets their home exchange plus all surrounding
exchanges as part of their local calling area). Some folks may
live just outside a local calling area for a net, but may wish
to participate in that net anyway, while others in the same
situation may prefer to remain independent.
There are cases in which the local calling areas lead
to situations where logic dictates that a node
physically in one FidoNet Region should be assigned to
another. In those cases, with the agreement of the
Regional Coordinators and Zone Coordinator involved,
exemptions may be granted. Such exemptions are
described in section 5.6.
An admission that basing everything on geography is going to
cause problems. But wait 'til you see section 5.6!
1.4.9 Summary
These levels act to distribute the administration and
control of FidoNet to the lowest possible level, while
still allowing for coordinated action over the entire
mail system. Administration is made possible by
operating in a top-down manner. That is, a person at
any given level is responsible to the level above, and
responsible for the level below.
This strikes me as being backward. A coordinator SHOULD be
responsible to those he governs. "Government by the consent of
the governed", it's called. Seems I recall that the United
States fought some wars to win this right a couple of hundred
years ago.
For example, a Regional Coordinator is responsible to
the Zone Coordinator for anything that happens in the
region. From the point of view of the Zone
Coordinator, the Regional Coordinator is completely
responsible for the smooth operation of the region.
Likewise, from the point of view of the Regional
Coordinator, the Network Coordinator is completely
responsible for the smooth operation of the network.
If a person at any level above sysop is unable to
properly perform their duties, the person at the next
level may replace them. For example, if a Regional
FidoNews 6-17 Page 17 24 Apr 1989
Coordinator fails to perform, the Zone Coordinator can
replace him.
What this means, folks, is that if your NC decides to back you
in a dispute against the Fidonet hierarchy, they can order him
replaced. You have no say as to who you want for your NC.
Does any of this remind you of the government structure used in
certain countries that don't have many Fidonet nodes?
2.1.6.1 No Disclosure of in-transit mail
Disclosing or in any way using information contained
in private netmail traffic not addressed to you or
written by you is considered annoying behavior,
regardless of how you come upon that traffic. This
does not apply to echomail which is by definition a
broadcast medium, and where private mail is often used
to keep a sysop-only area restricted.
There are several clauses in the proposed policy dealing with
private mail. My feeling is that this is an amateur network,
and therefore we shouldn't handle mail for which any level of
"security" is expected. There are private commercial services
intended for that purpose (e.g. MCI Mail, Compuserve, GEnie,
etc.). Given that, I would prefer not to see clauses like the
one above, which could (under the right circumstances) subject
a Fidonet sysop to litigation.
2.1.9 Private Nodes
The rare exception to ZMH compliance is Private Nodes.
Persons requesting private nodes should be supported
as points if possible. A private listing is justified
when the system must interface with many others, such
as an echomail distributor. In these cases, the exact
manner and timing of mail delivery is arranged between
the private node and other systems. Such an agreement
between a private system and a hub is not binding on
any replacement for that hub. A private node must be
a part of a network (they cannot be independents in
the region.) Private nodes are encouraged to honor
ZMH.
What happens if a person needs to operate a private node (for
whatever reason) but is not part of the geographical coverage
area of any network? The point may be a bit moot, because
since a private node is by definition unlisted, it could be
part of any net and nobody would be the wiser (so long as the
real geographic location of the node was not given in the
nodelist, and folks were careful not to reveal the real
location). But why force folks to go through that type of
sham?
2.2 How to obtain a node number
[Regarding application for a new Fidonet node] .....
FidoNews 6-17 Page 18 24 Apr 1989
You must indicate that you have read, and agree to
abide by, this document and all the current and future
policies of FidoNet.
How can one "read and agree to abide by" all FUTURE policies of
Fidonet? Especially when they often seem to be imposed "at
will" by power-hungry coordinators?
2.4 How to Form a Network
If there are several nodes in your area, but no
network, a new network can be formed. This has
advantages to both you and to the rest of FidoNet.
You receive better availability of nodelist difference
files and FidoNews, and everyone else can take
advantage of host-routing netmail to the new network.
....
Granting a network number is not automatic. Even if
the request is granted, the network might not be
structured exactly as you request. Your Regional
Coordinator will review your application and inform
you of the decision.
Does this now give the RC veto power over which nodes can and
cannot be in a local network? Again, it seems the power is
flowing from the wrong direction here...
3.5 Be a Member of the Area Administered
A coordinator must be a member of the area
administered. That is, a Network Coordinator must be a
member of that network by virtue of geography. A
Regional Coordinator must be either a member of a
network in his region, or an independent of the
region.
More geography (I've lost count by now...).
4.3 Assigning Node Numbers
...
You may not assign a node number to a node in an area
covered by an existing network. Further, if you have
nodes in an area covered by a network in formation,
those nodes must be transferred to the new network.
Though perhaps not readily apparent, this is still more
geography!
5.1 Responsibilities
A Regional Coordinator has the following
responsibilities:
FidoNews 6-17 Page 19 24 Apr 1989
...
3) To assign network numbers to networks in the
region and define their boundaries."
"...and define their boundaries???" So the RC can come in and
in one fell swoop, cut a bunch of nodes out of your net by
changing the boundaries! More geography! More power flowing
in the wrong direction!
5.2 Assigning Node Numbers
...
If a network forms in an area for which you have
independent nodes, those nodes will be transferred to
the local network as soon as is practical.
Normally this would be desirable, but in certain cases it may
not be. Why not give the independent nodes the option of
joining or not joining the new network?
Let me give you one example of a potential problem. There are,
we'll say, ten independent nodes in a given area. One of the
local sysops reads Policy one day and decides to apply to form
a net, listing all ten of the independent nodes in his area as
part of the new net. Unfortunately, this guy is well known to
the local Sysop community (but NOT to the RC) as a real twit,
someone that can't get along with anybody. The RC approves the
request, and these other nine sysops suddenly find themselves
under the thumb of Mr. Twit.
5.3 Encouraging the Formation and Growth of Networks
One of your main duties as a Regional Coordinator is
to promote the growth of networks in your region.
You should avoid having independent nodes in your
region which are within the coverage area of a
network. There are, however, certain cases where a
node should not be a member of a network, such as a
system with a large amount of inbound netmail; see
section 4.2.
If several independent nodes in your region are in a
local area you should encourage them to form a
network, and if necessary you may require them to form
a network. Refer to section 2.4. Note that this is
not intended to encourage the formation of trivial
networks. Obviously, one node does not make a
network. The exact number of nodes required for an
effective network must be judged according to the
circumstances of the situation, and is left to your
discretion.
This puts a lot of power... much TOO MUCH power in my
FidoNews 6-17 Page 20 24 Apr 1989
opinion... into the hands of the RC. Of course it goes without
saying that we're still talking geography here.
5.4 Assigning Network Numbers
It is your responsibility to assign network numbers to
new networks forming within your region. You are
assigned a pool of network numbers to use for this
purpose by your Zone Coordinator. As a part of this
function, it is the responsibility of the Regional
Coordinator to define the boundaries of the networks
in the region.
"define the boundaries of the networks???" Here we go again
(sorry if it's getting monotonous, I was getting pretty tired
of it by the time I waded through the whole document! I didn't
agree with it the first time, and the endless repetition sure
didn't win me over!).
5.6 Geographic Exemptions
There are cases where local calling geography does not
follow FidoNet regions. In exceptional cases,
exemptions to normal geographic guidelines are agreed
upon by the Regional Coordinators and Zone Coordinator
involved. Such an exemption is not a right, and is
not permanent. When a network is formed in the proper
region that would provide local calling access to the
exempted node, it is no longer exempt. An exemption
may be reviewed and revoked at any time by any of the
coordinators involved.
Finally we arrive at section 5.6. Don't you love this? They
admit that in some cases there may be good reasons to bend the
rules on the geography, but then they allow any of who knows
how many coordinators to kill the arrangement on a whim (thus
forcing some nodes to go long distance for services they should
be able to get for free). The way this clause is worded sucks
eggs, in my opinion. It allows the RC's to get much too
involved in what should be a matter of concern only to a local
net.
5.7 Overseeing Network Operations
...
If a network grows so large that it cannot reasonably
accommodate traffic flow during the Zone Mail Hour,
the Regional Coordinator can direct the creation of
one or more new networks from that network. These new
networks, although they may be within a single
local-calling area, must still conform to a
geographical basis for determining membership.
Not only is this getting confusing, it's getting ridiculous!
Does this mean that in some cases a sysop may have to join a
FidoNews 6-17 Page 21 24 Apr 1989
new net if he moves across town? Would it be so awful terrible
to give sysops a choice of which net they prefer to belong to?
Oh, yeah, you did notice they mentioned geography again, didn't
you?
9.1 General
The FidoNet judicial philosophy can be summed up in
two rules:
1) Thou shalt not excessively annoy others.
2) Thou shalt not be too easily annoyed.
In other words, there are no hard and fast rules of
conduct, but reasonably polite behavior is expected.
Also, in any dispute both sides are examined, and
action could be taken against either or both parties.
("Judge not, lest ye be judged!")
The coordinator structure has the responsibility for
defining "excessively annoying". Like a common
definition of pornography ("I can't define it, but I
know it when I see it."), a hard and fast definition
of acceptable FidoNet behavior is not possible. The
guidelines in this policy are deliberately vague to
provide the freedom that the coordinator structure
requires to respond to the needs of a growing and
changing community.
I'm glad they used that example. It makes the difference
between the proposed policy and a democratic governing system
fairly obvious.
Pornography is supposed to be judged according to "prevailing
community standards." In other words, it is NOT supposed to be
the opinion of the judges hearing the case. Suppose the judge
were a closet Ted Bundy, or a straight-laced Puritan? No
matter, it's not HIS opinion that's supposed to count, rather
the offense is to be measured against community standards...
that is, what would most of the PEOPLE in the community think
about this?
But in Fidonet, "Excessively Annoying Behaviour" is judged not
against the views of the common sysops of Fidonet, but rather
against the values and ideals of the *C structure, which are
often diametrically opposed to the views of the common sysop.
For example, common sysops might find it very annoying that a
Regional Coordinator would try to step in and say which nodes
could or could not be in their net! MANY sysops have found it
VERY annoying that certain coordinators with very big egos (or
worse?) have tried to prohibit cross-regional echo feeds.
9.8 Return to Original Network
FidoNews 6-17 Page 22 24 Apr 1989
Once a policy dispute is resolved, any nodes
reinstated on appeal are returned to the local network
or region to which they geographically or technically
belong.
Just one more mention of geography... but the "or technically"
is interesting. I wish there were a lot more "or
technically"'s in this document, it might put things in a much
different light.
9.9 Echomail
Echomail is an important and powerful force in
FidoNet. For the purposes of Policy Disputes,
echomail is simply a different flavor of netmail, and
is therefore covered by Policy. By its nature,
echomail places unique technical and social demands on
the net over and above those covered by this version
of Policy. In recognition of this, an echomail policy
which extends (and does not contradict) general
Policy, maintained by the Echomail Coordinators, and
ratified by a process similar to that of this
document, is recognized by the FidoNet Coordinators as
a valid structure for dispute resolution on matters
pertaining to echomail. At some future date the
echomail policy document may be merged with this one.
Well, that's a whole discussion unto itself. Suffice it to say
that the current echomail policy was formed by a small group of
people who seemed to have specific goals in mind (inhibiting
communications within the network!) and who were not very
tolerant of dissenting views. For example, one of the primary
people involved in echomail policy described those who didn't
agree with geographic echomail restrictions as "fools". Many
people felt that there was a real attempt to "railroad" this
policy into place.
The big problem with the Echo Policy is that it really
represents the views of only a few in Fidonet, rather than the
many. The average sysop was given NO real say in the formation
of Echopol.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
You may wonder why I am so hung up on geography? Basically,
because it gives those in control the ability to suppress
dissent. It's the old "divide and conquer" routine. I've seen
some real efforts to keep those who disagree with Fidonet
policies from talking to each other, or to the other Sysops in
Fidonet.
Besides, it doesn't make sense technically, at least not in
North America. I would estimate that out of those sysops who
make a large number of long distance calls in a month, a fairly
good percentage are using some type of calling plan that is not
distance sensitive, whether on a packet switching network (e.g.
FidoNews 6-17 Page 23 24 Apr 1989
PC Pursuit, Starlink) or a long distance service (e.g. Reach
Out America, or Telecom Canada's "Between Friends"). Still
other sysops have access to company tie lines, Foreign Exchange
lines, or WATS lines that can give them access to other areas
of the country at little or no cost.
Many sysops have lost echo feeds in recent months, because they
(or their feeds) were formerly able to get feeds from PC
Pursuitable points (or even nearby points outside their
region), but were cut off from those feeds when regional
restrictions on echomail traffic started to be imposed IN
ANTICIPATION of an Echomail policy allowing these restrictions.
You heard me right. Many of the *C's were so into their power
trip that they went ahead and began enforcing a policy that was
still in the draft stage!
Now it may make some sense to base some things on geography,
but Fidonet regions make no sense at all (as a matter of fact,
I heard they were based on NFL football regions, or some such
thing. No one's yet been able to explain to me what football
has to do with computer networks).
The major problem is that Fidonet regions divide up the country
and inhibit folks from talking to each other, yet they are too
large to be meaningful in terms of reducing costs. For
example, a person living near the border of a region might know
that a feed for an echo he wants exists only thirty miles away,
but across a regional boundary. The next nearest feed (and the
only "legal" feed for him) is several hundred miles away in his
own region.
Now phone rates are a funny thing... even if you're on a
distance-sensitive long distance service (and keep in mind that
many sysops are not), most of the increases in phone rates are
within the first 125 miles from your location. After that, the
rates taper off, and the cost of a call remains pretty uniform
across the country (there's only a two or three cents per
minute difference between a call to a point 125 miles away, and
a call a couple of thousand miles distant). Also, in many
places, calls within your own state cost significantly more
than calls going a similar distance to an out-of-state point.
So, setting strict geographical boundaries for echomail can
often increase costs for sysops.
At the net level, basing net boundaries on a geographical
factor can have several undesirable results. It may keep those
who live near the net, or who have strong emotional ties with
the net, from getting into that net. But the biggest problem,
I think, it that it sets up a situation where the NC has too
much power. He can service nodes on a "take it or leave it"
basis. Nothing wrong with that IF there are other sources. We
don't require Standard Oil to put a gas station in every city,
because if they don't someone else probably will, and if that
firm charges too much, a competitor will no doubt appear sooner
or later. But, we do require Bell Telephone to serve every
customer in their service area, and not only that, we have an
FidoNews 6-17 Page 24 24 Apr 1989
body of people independent of the phone company (the Public
Utilities Commission) who can step in and intervene on behalf
of customers who have been overcharged, or otherwise wrongly
treated.
The trouble is that in Fidonet, all the "oversight" comes from
above... from the very people who appointed the coordinator to
his position. Nowhere are those who receive any services from
these coordinators given any say in the process. Given that, I
believe that the least we can do is to allow sysops some amount
of choice in which net they will join. That way, if you manage
to get a real dictator as an NC or RC, and the RC or ZC refuses
to replace him (thereby admitting that they made a mistake in
appointing the guy in the first place), sysops don't have to
leave Fidonet entirely to get out from under the guy.
Now I have one more thing to say about geography. Some people
have come up with the bright idea that if cross-regional
echomail feeds are prohibited, it will somehow cause dupe
messages to magically disappear. What these folks fail to
understand is the difference between geography and topology.
You can have faulty topology no matter where the individual
nodes are geographically located, or you can have a "clean"
topology even if nodes are spread across the country. The
physical location of a node makes no difference at all.
For example, suppose you have a node that has been
participating in a local net and not causing dupes. Let's
further suppose he polls his net host nightly for mail and
echoes. Now, one night he quietly packs up in the middle of
the night and moves across the country, and begins polling his
net host via long distance. Does his computer contain a sensor
that says, "oops, I've changed times zones, so I have to
generate duplicate messages?" Not hardly! As long as the node
maintains the same topology within his original net (connecting
to the same node for his feeds), he isn't going to screw up
echomail. What does this prove? Simply that whether the
network topology is good or bad has nothing to do with
geography. You could draw a network topology map without ever
knowing or caring where the nodes are geographically located.
So, I have two major reason for not liking all the fuss about
geography (and we must admit they've gone out of their way to
get it into this document!) One is that these restrictions COST
PEOPLE MONEY. They are particularly unfair to those who live
near the border of a geographic area, since they are often
forced to make long distance calls to more distant points than
would be necessary without the restrictions. They other is
that they provide a perfect spawning ground for petty dictators
(and Fidonet has seen far too many of THOSE types already!).
THESE RULES ARE UNENFORCEABLE
There is a saying that when lawmakers create unenforceable
laws, they create disrespect for the law in general. There are
generally two reasons that laws can be considered
FidoNews 6-17 Page 25 24 Apr 1989
unenforceable. One is that you can never catch the someone in
the act in order to find out that the rules are being broken.
The other is that such a high percentage of people consider the
law ridiculous and/or unenforceable, so they make no attempt to
comply with it. If everyone is breaking a certain law, it is
de facto unenforceable, and eventually the law is usually
change to reflect reality.
Policy documents are the "laws" of Fidonet. If certain
provisions are unenforceable, it can't help but create a
climate of disrespect for Policy in general. I believe that
parts of the proposed Fidonet policy are unenforceable for both
of the above-mentioned reasons. First, because Fidonet is
really a hobbyist organization, few sysops read Policy more
than once, and a lot of those who do read it ignore it anyway,
especially the parts that don't seem to make much sense. Since
BBS's come and go, this problem will ever be with us. But,
more importantly, sysops often conspire to "bend" certain rules
in such a way that the higher-ups will never find out about it
unless some fluke occurs. Some examples I've heard of
(actually, none of these refer to a specific situation, but are
composites of many tales I've heard):
* A node lets callers on during ZMH, but few callers call at
that time of morning anyway. If the NC or RC calls to deliver
mail and the line's not busy, the mail gets through and they
are none the wiser. If the line IS busy, they have no way of
knowing that it's a BBS caller rather than another mail call in
progress.
* A sysop wants to feed echomail to a node in another region.
Since he doesn't normally communicate with anyone else in the
distant node's net, he just defines the distant net as a
"pointnet" in his software, and uses some other software to
strip or change PATH lines and other information on incoming
messages from that node, so that the messages appear to have
originated on his board. Of course, should a dupe loop occur
in this setup, there is no easy way for anyone to track it down
because all records of the "wild feed" have been expunged from
the messages. Sure, it's an intentional violation of the
rules, but he feels justified because after all, he never had
any vote in the rules!
* Another sysop has moved to a different region, but he wants
to keep in touch with the folks in his old home town. So, his
old net/node number is still in the nodelist, and he polls his
net host every night for mail. Right now his node is listed as
private/unlisted, so nobody can call him, but should the RC
ever decide to try and remove all private nodes from the
nodelist, he knows a nice "permanently busy" official phone
company number that he can place in the nodelist.
* Then there is the guy who always wanted to be an echo hub, so
he set up his own point net. Since points are considered BBS
users, they can be located just about anywhere, and his point
users are (mostly because he's in a PC Pursuitable city).
FidoNews 6-17 Page 26 24 Apr 1989
Strangely enough, some of his points also happen to be BBS
sysops (who, coincidentally, seem to be getting their echo
feeds from unknown sources), but as far as he is concerned,
they are just users of his BBS, and entitled to get echoes just
like any of his other point users...
One other point... many sysops have come to realize that the
ONLY possible sanction in Fidonet is excommunication, and while
many RC's would be more than happy to excommunicate all of the
"troublemakers" from their regions, most NC's (who generally
know the "offenders" personally) are not usually so inclined,
especially in the case of a policy regulation that nobody asked
for in the first place. So, the only way that the RC can get a
node excommunicated is to replace the NC of the net, but that
isn't always so easy, either. One RC tried that and discovered
that over 90% of the nodes in his region were ready to pull out
of Fidonet and start their own network (the RC resigned
instead). In another case, the RC wanted to replace an NC, but
out of about twenty sysops, only one even thought about taking
the job... and was gently but firmly persuaded not to by the
other sysops of that net. The NC stayed put.
The fact that excommunication is the only sanction gives sysops
a lot more power than many of them realize. Suppose the only
possible penalty for a crime were death? How would you ever
enforce littering laws? You wouldn't... you'd concentrate on
the really important crimes and forget the small stuff. But
those in the Fidonet power structure like to issue a lot of
proclamations regarding minor things, totally forgetting that
they have no way short of excommunication to enforce these
dictums... and you can't excommunicate too many nodes, or folks
begin to suspect that maybe there's something wrong here!
WHY THE POWER GRAB?
The thing I can't understand is why such a small number of
people have subjected themselves to such a large number of
flames to try and bring about something that at least 90% of
the sysops are either actively opposed to, or just don't care
about. Why are they so doggedly determined to push policies
that have caused some of the brightest software developers in
Fidonet to consider leaving the net? (some have done more than
just consider it!) Why are they trying to promote policies
that will restrict the free flow of information and
communications?
These are questions you should be asking yourself, if you are a
Fidonet sysop.
There are probably a lot of entities that don't care much for
our amateur network, both in the commercial and governmental
spheres. Commercial interests would rather you use their
services (and pay the associated per-minute charges). The
government is probably a bit unsettled by the fact that we're
moving massive amounts of data around containing all sorts of
information, pretty much at will. I'm sure that some in
FidoNews 6-17 Page 27 24 Apr 1989
government would really appreciate a move to funnel all
echomail through eight or ten central collection points, which
could be more easily monitored.
Now, some have said that this kind of thinking is just plain
silly, even if some of the principal players in the creation of
Fidonet policy don't live all that far from our nation's
capitol. Well, if that be the case, I apologize. Only thing
is, for months now, I've been trying to figure out why these
people would subject themselves to flames, harrassment, and the
generally negative comments about their motives, character, and
integrity that have come from the many sysops who simply don't
want the vision of Fidonet that they're trying to sell.
IF I COULD CHANGE FIDONET...
If I could change Fidonet any way I wanted, I'd only make two
changes.
First, I'd get rid of all geographic restrictions. In most
cases they aren't needed. In most cases, folks will join the
net nearest them. If they don't, there may just be a good
reason why they don't.
Second, I'd get rid of Regions. They aren't needed. In fact,
they aren't even used for mail routing purposes. They just set
up artificial barriers to communications. If the ZC needs
folks under him to divide the workload, then let's have
"Coordinators at large". Each NC would be assigned to a
Coordinator at Large, and would sent his nodelist updates to
that person and receive his Fidonews and Netdiff feeds from
that person. In the event of a personality conflict, the ZC
could allow the NC to go through a different Coordinator at
Large (and if all the NC's requested a transfer away from a
certain coordinator, wouldn't that be a pretty good indicator
that the guy has no business being a Coordinator?).
I know some folks will quickly add that *C's should be elected,
not appointed. I believe that, too, but don't think that would
be quite so important if people were not forced to deal only
with a single *C (at any level), based strictly on where they
happen to be physically located.
Now, I've been saying all this for quite some time, and a lot
of other good, sincere sysops have been saying some of the same
things. But the idea of taking the Geography out of Fidonet
seems to scare the <insert favorite expletive> out of some of
the current crop of Fidonet *C's. Why? Is it because some
don't want to lose their Fiefdoms? Or is there some other
reason they want to keep bottleneck control over Fidonet, and
inhibit communication between different geographical areas?
Those of you in alternate networks shouldn't feel so smug
because you're not having these problems. Think about it...
where do your echoes come from? In most cases, are they either
received from or passed to Fidonet through a gate? That
FidoNews 6-17 Page 28 24 Apr 1989
gateway connection could be easily monitored or disrupted. And
right now, none of the alternate nets are all that large. If
one of THEM grows to 4,000 nodes, we may see some occurrences
in those networks that are difficult to understand.
It's time for all sysops to wake up and see how our freedom to
communicate is being gradually eroded by the added layers of
Policy proclamations being foisted upon us. Tell your *C's
that you do not support restrictions upon our freedom to
communicate! Let the voice of the average sysop be heard! Ask
yourself... are things really better now than they were before
we had "Echomail Coordinators"? Do you really feel that
restrictions based on artificial geographic boundaries have any
merit? If not, write a message to your *C's today, and let
your voice be heard!
-----------------------------------------------------------------
FidoNews 6-17 Page 29 24 Apr 1989
=================================================================
LETTERS TO THE EDITOR
=================================================================
Garth Kidd
Fidonet 3:680/809
There is currently a large discussion (argument?) going on in
some echo areas as to the legality of encrypting messages. The
draft FidoNet policy in FidoNews 6.14 stated that encryption of
any form was considered "annoying behaviour".
In echo areas, this is entirely fair. People pay large sums of
money to transport echo areas around the place, and people
should not use them as an alternative to NetMail.
The ruling, however, has one worrying aspect:
It effectively bans encryption of messages, whether by DES means
or simply by rotating the message 13 characters through the
alphabet. Unfortunately, it also prevents the only means of
keeping our privacy. It is a simple matter for sysops to read
"private" messages (most don't: some might), and thus people
will want to encrypt. Unfortunately, this makes it harder to
tell if people are using the Net for illegal purposes (transfer
of classified documents, etc).
Discounting the last point, it seems fair to ban encryption in
all places BUT private messages. Including the last point, it
seems that it should be totally banned, or performed in a simple
matter that anyone needing to check for illegal activity. This
seems to be a trivial exercise, as it removes the privacy aspect
again!
I suggest an open debate in an echo area, or pehaps a vote of
some kind by the participants in FidoNet. As voting by e-mail
would be difficult, I suggest that it be restricted to sysops
only, and the voting to be restricted to one vote per node.
Comments on this method, please.
Finally, I would like to point out that the echo area I have
seen on some bulletin board, containing USENET and ACSNET jokes,
have in them messages encryped with ROT13 (rotating letters
forward 13 characters), which is quite popular and necessary for
legal reasons on potentially offensive jokes. The ruling in the
draft policy makes these messages rather illegal. How should
these be handled?
Yours,
Garth Kidd.
-----------------------------------------------------------------
FidoNews 6-17 Page 30 24 Apr 1989
=================================================================
LATEST VERSIONS
=================================================================
Latest Software Versions
Bulletin Board Software
Name Version Name Version Name Version
Fido 12k Opus 1.03b TBBS 2.1
QuickBBS 2.03 TPBoard 5.0 TComm/TCommNet 3.4
Lynx 1.30* Phoenix 1.3 RBBS 17.1D
Network Node List Other
Mailers Version Utilities Version Utilities Version
Dutchie 2.90C* EditNL 4.00 ARC 6.01
SEAdog 4.50 MakeNL 2.12 ARCmail 2.0
BinkleyTerm 2.20* Prune 1.40 ConfMail 4.00
D'Bridge 1.18* XlatList 2.90 TPB Editor 1.21
FrontDoor 2.0 XlaxNode 2.32 TCOMMail 2.2*
PRENM 1.40 XlaxDiff 2.32 TMail 8901
ParseList 1.30 UFGATE 1.03
GROUP 2.07*
EMM 1.40
MSGED 1.99
XRS 2.0*
* Recently changed
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-17 Page 31 24 Apr 1989
=================================================================
NOTICES
=================================================================
The Interrupt Stack
28 Apr 1989
Start of Gateway '89 show at the Viscount Hotel in Queens,
New York. Contact Gateway '89 at (516) 678-7180 for info.
8 May 1989
Digital Equipment Corporations User Society (DECUS) will be
holding its semi-annual symposium in Atlanta, GA. Runs
through May 12. As usual sysop's will get together and chat.
15 May 1989
Denmark changes telephone numbers from 7 to 8 digits.
19 May 1989
Start of EuroCon III at Eindhoven, The Netherlands. Contact
Hans Ligthelm of 2:500/3 for details.
5 Jun 1989
David Dodell's 32nd Birthday
24 Aug 1989
Voyager 2 passes Neptune.
24 Aug 1989
FidoCon '89 starts at the Holiday Inn in San Jose,
California. Trade show, seminars, etc. Contact 1/89
for info.
5 Oct 1989
20th Anniversary of "Monty Python's Flying Circus"
11 Nov 1989
A new area code forms in northern Illinois at 12:01 am.
Chicago proper will remain area code 312; suburban areas
formerly served with that code will become area code 708.
If you have something which you would like to see on this
calendar, please send a message to FidoNet node 1:1/1.
-----------------------------------------------------------------
FidoNews 6-17 Page 32 24 Apr 1989
OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION
Mort Sternheim 1:321/109 Chairman of the Board
Bob Rudolph 1:261/628 President
Matt Whelan 3:3/1 Vice President
Bill Bolton 3:711/403 Vice President-Technical Coordinator
Linda Grennan 1:147/1 Secretary
Kris Veitch 1:147/30 Treasurer
IFNA COMMITTEE AND BOARD CHAIRS
Administration and Finance Mark Grennan 1:147/1
Board of Directors Mort Sternheim 1:321/109
Bylaws Don Daniels 1:107/210
Ethics Vic Hill 1:147/4
Executive Committee Bob Rudolph 1:261/628
International Affairs Rob Gonsalves 2:500/1
Membership Services David Drexler 1:147/1
Nominations & Elections David Melnick 1:107/233
Public Affairs David Drexler 1:147/1
Publications Rick Siegel 1:107/27
Security & Individual Rights Jim Cannell 1:143/21
Technical Standards Rick Moore 1:115/333
IFNA BOARD OF DIRECTORS
DIVISION AT-LARGE
10 Courtney Harris 1:102/732 Don Daniels 1:107/210
11 Bill Allbritten 1:11/301 Mort Sternheim 1:321/109
12 Bill Bolton 3:711/403 Mark Grennan 1:147/1
13 Irene Henderson 1:107/9 (vacant)
14 Ken Kaplan 1:100/22 Ted Polczyinski 1:154/5
15 Scott Miller 1:128/12 Matt Whelan 3:3/1
16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628
17 Neal Curtin 1:343/1 Steve Jordan 1:206/2871
18 Andrew Adler 1:135/47 Kris Veitch 1:147/30
19 David Drexler 1:147/1 (vacant)
2 Henk Wevers 2:500/1 David Melnik 1:107/233
-----------------------------------------------------------------
FidoNews 6-17 Page 33 24 Apr 1989
__
The World's First / \
BBS Network /|oo \
* FidoNet * (_| /_)
_`@/_ \ _
| | \ \\
| (*) | \ ))
______ |__U__| / \//
/ Fido \ _//|| _\ /
(________) (_/(_|(____/ (tm)
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.
-----------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink