2776 lines
123 KiB
Plaintext
2776 lines
123 KiB
Plaintext
F I D O N E W S -- Vol.10 No.14 (05-Apr-1993)
|
||
+----------------------------+-----------------------------------------+
|
||
| A newsletter of the | |
|
||
| FidoNet BBS community | Published by: |
|
||
| _ | |
|
||
| / \ | "FidoNews" BBS |
|
||
| /|oo \ | +1-519-570-4176 1:1/23 |
|
||
| (_| /_) | |
|
||
| _`@/_ \ _ | Editors: |
|
||
| | | \ \\ | Sylvia Maxwell 1:221/194 |
|
||
| | (*) | \ )) | Donald Tees 1:221/192 |
|
||
| |__U__| / \// | Tim Pozar 1:125/555 |
|
||
| _//|| _\ / | |
|
||
| (_/(_|(____/ | |
|
||
| (jm) | Newspapers should have no friends. |
|
||
| | -- JOSEPH PULITZER |
|
||
+----------------------------+-----------------------------------------+
|
||
| Submission address: editors 1:1/23 |
|
||
+----------------------------------------------------------------------+
|
||
| Internet addresses: |
|
||
| |
|
||
| Sylvia -- max@exlibris.tdkcs.waterloo.on.ca |
|
||
| Donald -- donald@exlibris.tdkcs.waterloo.on.ca |
|
||
| Tim -- pozar@kumr.lns.com |
|
||
| Both Don & Sylvia (submission address) |
|
||
| editor@exlibris.tdkcs.waterloo.on.ca |
|
||
+----------------------------------------------------------------------+
|
||
| For information, copyrights, article submissions, |
|
||
| obtaining copies and other boring but important details, |
|
||
| please refer to the end of this file. |
|
||
+----------------------------------------------------------------------+
|
||
========================================================================
|
||
Table of Contents
|
||
========================================================================
|
||
|
||
1. Editorial..................................................... 2
|
||
2. Articles...................................................... 2
|
||
The Cynic's Sandbox, v2.0ReallyWideAlphaForAnyOne........... 2
|
||
Why Policy 4.1C deserves our serious attention.............. 4
|
||
Commodore Geos Echo Available............................... 6
|
||
Responce to Stanton McCandlish.............................. 6
|
||
OS2 echos................................................... 9
|
||
Policy Proposals: The Cart Before the Horse?................ 10
|
||
Rebuttal to an Anonymous Critic............................. 14
|
||
FidoNet Policy Document Version 5........................... 17
|
||
3. Fidonews Information.......................................... 48
|
||
FidoNews 10-14 Page: 2 05 Apr 1993
|
||
|
||
|
||
========================================================================
|
||
Editorial
|
||
========================================================================
|
||
We Lied.
|
||
|
||
There are TWO policy documents in this issue, although there
|
||
won't be any more, probably.
|
||
|
||
We are getting bulges of requests for information about sending
|
||
mail from FidoNet to Internet, and queries from exotic sounding
|
||
internet addresses about how to "get on" FidoNet. For example,
|
||
to whom and where should we refer someone in the Dominican
|
||
Republic who wants to start a BBS? Also, during said mail bulges
|
||
i managed to lose an announcement about a Chinese language
|
||
e-'zine and would its sender very kindly re-send it?
|
||
|
||
Spring is coming easily la-de-da, cactuses between cabling on
|
||
tables are sprouting little green things. I'm still waiting for
|
||
my monitor to sprout. Why is it difficult to get anything
|
||
started when beginnings happen so naturally in plant-life?
|
||
Vine-like networks tangle around and i just watch. It is too
|
||
easy to be inert and accepting unless some buttons are pushed
|
||
and rewards are possible. Not much truly interesting seems to
|
||
happen unless somebody tries something new simply to try
|
||
something new.
|
||
|
||
oh...whaa...excuse me, D.T. [ET in moments such as this] in
|
||
muttering something over my shoulder about how God is a computer
|
||
who invented man as a bootstrap loader...
|
||
|
||
"man". Hrrrumph. Try wiring a net without gender changers.
|
||
========================================================================
|
||
Articles
|
||
========================================================================
|
||
The Cynic's Sandbox, v2.0ReallyWideAlphaForAnyOne
|
||
R. Cynic
|
||
|
||
It's Spring, it must be time for a policy proposal.
|
||
|
||
Boy, and I was getting bored with Fight-O-Net. Now we have
|
||
Pol5, Pol4.1c, caller ID, and another well-thought-out-type-
|
||
III-packet-proposal-which-will-be-ignored-until-someone-writes-
|
||
code. I don't think I've ever had so much fun with clothes on.
|
||
|
||
I'd like to take this moment, if I may, to submit the R. Cynic
|
||
Pol6 Proposal, which I hope you'll all examine with a 10x
|
||
magnifier.
|
||
|
||
Policy Six
|
||
Final Version
|
||
1 April 1993
|
||
|
||
0. Legal Stuff
|
||
This document is FraggleWare. To register, sing the Fraggle
|
||
FidoNews 10-14 Page: 3 05 Apr 1993
|
||
|
||
Rock theme. You forgot the last verse. Try Again.
|
||
|
||
1. Overview
|
||
|
||
Fight-O-Net is a whole buncha systems with little more than
|
||
FTS-0001 in common, and sometimes, if they run FrontDoor, not
|
||
even that.
|
||
|
||
2. Language
|
||
|
||
The official language of Fight-O-Net is english, preferably
|
||
with as many fancy technical words as you can think of to
|
||
confuse the hopeless newbies and teen sysops.
|
||
|
||
3. The Rules
|
||
|
||
3.1 The Boss
|
||
|
||
Fight-O-Net should be controlled by whoever's screaming the
|
||
loudest for democracy. Anyone who wants it that badly should
|
||
be allowed to go nuts trying to run it.
|
||
|
||
3.2 Complaints
|
||
|
||
Policy Complaints should be referred to node 1/1, along with
|
||
all other junk mail. If you send enough, you may wind up
|
||
running Fight-O-Net!
|
||
|
||
3.3 Echomail policy
|
||
|
||
Echomail, defined as mail with lots of Echos (Dupe Loops) and
|
||
lots of missing mail (Caused by dupe killers) is already
|
||
fascist and governed by non-democratically elected vengeful
|
||
moderators who don't follow their own rules. It will be
|
||
ignored by this document, except as precedent for the actions
|
||
of The Boss.
|
||
|
||
3.3.1 Echomail renaming
|
||
|
||
Echomail shall be more accurately known as FlameMail.
|
||
|
||
3.4 Excessively Annoying Systems
|
||
|
||
Excessively Annoying Systems, those run by any member of the Good Old
|
||
Boys network, shall be dropped from the nodelist until such time as
|
||
hell freezes over.
|
||
|
||
3.5 Sense of proportion
|
||
|
||
A sense of proportion is unimportant in Fight-O-Net.
|
||
|
||
4. Anthem
|
||
|
||
The official song of Fight-O-Net is below. Sing to "America, the
|
||
Beautiful", or "The Star Spangled Banner", or "We ain't gonna take
|
||
FidoNews 10-14 Page: 4 05 Apr 1993
|
||
|
||
it" by Twisted Sister.
|
||
|
||
Democracy, democracy,
|
||
we pin our hopes on thee,
|
||
and someday soon,
|
||
we hope to have,
|
||
a grunt for Z1C
|
||
|
||
Spam, Spam, Spam, Spam,
|
||
Spam, Spam, Spam, Spam,
|
||
Spam, Spam, Spam, Spam,
|
||
Spam, Spam, Spam, Spam.
|
||
|
||
5. Credits, acknowlegments, etc.
|
||
|
||
Fight-O and Fight-O-Net are trademarks of Fight-O software, Inc.
|
||
I'd also like to thank Nets 2605 and 2606, Richard Bash (for no
|
||
apparent reason), Pablo Kleinman, Tom Jennings, my mother, and
|
||
that cute redhead I had a crush on in 6th grade.
|
||
|
||
Next time in the Cynic's Sandbox: Caller ID - For the man who has
|
||
nothing to hide...
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Why Policy 4.1C deserves our serious attention
|
||
|
||
Why 4.1C deserves our serious attention
|
||
|
||
I read with great interest, two things in last week's edition (1013) of
|
||
Fidonews; the article about DRAFT008 and the little article by Glen
|
||
Johnson that preceded the full text of the 4.1C proposal.
|
||
|
||
I'm the 'anonymous' person that wrote the original comparison article a
|
||
few issues ago. I'm going to remain anonymous, and I'll tell you why.
|
||
|
||
I've seen what has transpired in the many SYSOP-type conferences over
|
||
the last three months with the policy debates. The group that developed
|
||
4.1C was the first on the scene, and they and their proposal were
|
||
immediately attacked by a number of people for doing so. It was VERY
|
||
clear to me, at least, that the reason many people assailed their
|
||
document was because of who the authors were, not what the document
|
||
said.
|
||
|
||
Probably the most ludicrous of all the things I saw were the many
|
||
utterly horrifying things said by one Bob Germer, who started calling
|
||
members of Net 163 names because of their support for democratic
|
||
reform in Fidonet. And this person developed a policy draft himself!
|
||
|
||
The reason I did my article anonymously, is because I don't want my
|
||
friends and members of the net I'm in to be categorized, or pre-judged
|
||
or labelled because of the things -I- say. I offered my honest
|
||
interperetation of both documents, and you all can take that for
|
||
what its worth.
|
||
|
||
FidoNews 10-14 Page: 5 05 Apr 1993
|
||
|
||
I called the other document BAKERPOL because it was distributed by
|
||
Christopher Baker, the RC of Region 16. I don't know if he wrote it
|
||
himself, nor do I care. But I called it what I did because I under-
|
||
stand that he was the person that released it. I don't know
|
||
Christopher Baker or the other guy, Ken Tuley, and it doesn't even
|
||
matter. I didn't judge the proposals by the names attached to them,
|
||
I judged them on their merits.
|
||
|
||
I never much cared about Fidonet policy, because I get my mail, and
|
||
that's all I ever really cared about. Sure, it bothered me a little
|
||
that it seemed to be an all-male, political, barb throwing contest
|
||
at times, but it really wasn't THAT big of an issue with me.
|
||
|
||
Then 4.1C came out, and I read it. And it changed my view of things.
|
||
Then I read the others that started coming out in rapid-fire
|
||
succession after it. And they reinforced my new view of things.
|
||
|
||
The 4.1C proposal isn't perfect. But it has something very significant
|
||
in it; democracy. I've heard the authors of it continually extolling
|
||
the virtues of what they call the 'one sysop, one vote' concept, and
|
||
I must say, that I think that's a WONDERFUL concept, and the 4.1C
|
||
proposal bears that out. I'm thrilled with the idea of letting
|
||
regular people vote for their coordinators.
|
||
|
||
Giving each sysop a vote brings us all back down to Earth; it puts
|
||
us all on the same level with one another. After all, people will
|
||
tend to support, and help, and cooperate, and work with coordinators
|
||
that are there because we WANT them there as opposed to being PUT
|
||
there, or elected by only select people (like NCs being the only
|
||
people 'allowed' to vote for an RC) . Everyone pitches in, everyone
|
||
has a say, and noone's vote is any 'stronger' than anyone elses. I
|
||
think its a LOVELY idea.
|
||
|
||
I like the 4.1C proposal over anything that has come out so far
|
||
because it treats Fidonet as a group of PEOPLE, each with their own
|
||
equal voice. And coordinators should find it equally appealing, as
|
||
it will give them the 'warm & fuzzy' feeling of knowing that there's
|
||
no QUESTION that they have the support of the people they're serving.
|
||
|
||
We've nothing to fear from this proposed policy, I think it'd be
|
||
good for us. The Regional Coordinators should allow a vote on it to
|
||
take place. It's only fair. And then if it passes a vote, we'll ALL
|
||
have an equal opportunity to participate in shaping Fidonet for the
|
||
future.
|
||
|
||
Give us a chance, please?
|
||
FidoNews 10-14 Page: 6 05 Apr 1993
|
||
|
||
|
||
Commodore Geos Echo Available
|
||
|
||
Commodore Geos Echo Available
|
||
by Steve Dressler
|
||
|
||
Even today there are still alot of 8 bit Commodore 64's and 128's out
|
||
in the market place. Commodore has an operating system called GEOS.
|
||
GEOS is the Windows environment of the Commodore Business Machines.
|
||
I have started a GEOS Echo for all people interested in CBM in
|
||
hopes to gain enough traffic to justify backbone status. The
|
||
echo is on the E-List, but with little success to date. At the
|
||
present time, there are around 25 messages a week and growing.
|
||
|
||
People in Zone 3 may request a feed from 3:633/162. Zone 1 may
|
||
request a feed at 1:154/92 or 1:170/202 or 1:170/610. Each feed is
|
||
v.32bis, and mine (170/202) is a ZyXEL 19.2k.
|
||
|
||
Steve Dressler is the moderator and Steven Guthrie is the
|
||
co-moderator (VP of the Tulsa Area Commodore Users Group).
|
||
Discussions are about, but not limited to, Commodore Geos related
|
||
topics. It is suprising how serious people take their GEOS in the
|
||
Commodore world.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Responce to Stanton McCandlish
|
||
|
||
Chris Farrar
|
||
1:246/20 - Windsor, Ontario, Canada
|
||
89:488/20
|
||
|
||
Caller ID Revisited
|
||
|
||
In Fidonews 10-13, Mr. McCandlish had some things to say, and I would
|
||
like to take the time here to refute them. In keeping with the
|
||
statement from the Editor, any future responce on Caller ID will be
|
||
made in the PHONES echo, available from the Fidonet backbone, or via
|
||
netmail. Netmail, whether or not it has the PVT bit set, can and may
|
||
be replied to and quoted publically in the PHONES echo. Systems
|
||
running in the IMEX network, can find a similar conversation in the
|
||
IMEX.TELECOM echo, available from your echo feed on the IMEX (zone 89)
|
||
backbone.
|
||
|
||
>I could be slammed harder. I did NOT say that callers should
|
||
>not have to provide BBSs with correct address, name and phone
|
||
>number. The last few criticisms of my letter have hinged on
|
||
|
||
True, you didn't say that, but how to you intend to discover if the
|
||
name, number, and address (if required) _is valid_? I don't know
|
||
about his system, but every week I have at least a couple of twits who
|
||
like calling in, and trying to gain access to my system. If they
|
||
aren't twits, then Ronald Reagan, William Clinton, and Al Gore all
|
||
decided to call my BBS, one after another, at 2 in the morning. Why
|
||
don't I beleive that they are the caller's real names? Then again,
|
||
FidoNews 10-14 Page: 7 05 Apr 1993
|
||
|
||
I used to have a user, James Bond, (a real person, I saw the birth
|
||
certificate), who is a real person. With CLID, discovering there is a
|
||
real Bond, and a fake Reagan, Clinton, et al is a piece of cake.
|
||
|
||
>that there may be a problem. Again I did not say that CID is
|
||
>Satan incarnate, rather that some thought should be given to its
|
||
>use and that people should be patient and wait until policy has
|
||
>been updated and nodelist flags defined to account for CID-only
|
||
>systems. Is this so difficult to grasp? As for long distance
|
||
|
||
But you have yet to give a valid reason WHY people should wait for new
|
||
nodelist flags. The technology is available today, why shouldn't it
|
||
be used? The answer is simple, there is no reason why it shouldn't be
|
||
implemented. Also, why do we need nodelist flags? CLID can keep a
|
||
user from connecting with a BBS without stopping a mailer from
|
||
connecting for mail sessions, and how many users download the nodelist
|
||
each week for a BBS list anyway.
|
||
|
||
>callers: why verify them? What nut is going to call you long
|
||
>distance, at THEIR expense to lie to you so they can get an
|
||
>extra account to cheat SRE with, or whatever? It just isn't
|
||
>likely.
|
||
|
||
Sorry. There are nuts that will call to upload their favorite trojan
|
||
and virii, lord knows I've found enough that LD callers have no
|
||
uploading abilities until after they have been validated. There are
|
||
people who do get their kicks from uploading virii, and doing it LD
|
||
makes it harder to track them down.
|
||
|
||
> And finally, the merits of Canadian vs US law is real
|
||
>neat and all but totally irrelevant. READ the article, for
|
||
|
||
Hardly irrelevant. Laws in countries are different, and you cannot
|
||
expect that views will be identical between different countries.
|
||
Living in a border city, I have seen enough people, on both sides of
|
||
the border, who don't realize that when they pass the line down the
|
||
middle of the Detroit River, that they are subject to different laws,
|
||
and regulations. The number of Michigan motorists that get arrested
|
||
at sobriety roadblocks is proof of that, as they claim them to be
|
||
unconstitutional, and then want Detroit cops to come and get them, as
|
||
they don't consider Windsor police officers having any jurisdiction
|
||
over them.
|
||
|
||
>chrissakes. And only last thing, I just want to emphasize yet
|
||
>AGAIN that when I say CID harms privacy I am not refer- ring to
|
||
>sysops, but rather to less savoury folks. By forcing caller ID,
|
||
>sysops in effect demand that we send caller ID info to ALL
|
||
>numbers. When the telcos come up with all call blocking that
|
||
>can be temporarily disabled with a keypad code to dial one
|
||
>number, then fine, CID your heart out. Until that time comes
|
||
|
||
Why should we wait to implement CLID for your convienence? If you are
|
||
calling "less savoury folks", you have several options:
|
||
|
||
1) Install a data line, and call them off it, so if they do call
|
||
FidoNews 10-14 Page: 8 05 Apr 1993
|
||
|
||
you back, they will never reach you.
|
||
2) Call from work
|
||
3) Call from a pay phone
|
||
4) Petition whatever group that regulates phones in your state to
|
||
allow either disabling on a per call basis, or switch to allowing
|
||
blocking on a per call basis, by dialing your equivelant of *69.
|
||
|
||
And, not everywhere has global blocking, such as there is where you
|
||
live. Here in Ontario (Canada), the only style of blocking available
|
||
is the per call, dial a * code, and then make your call, the same way
|
||
you would go about temporarely disabling Call Waiting to make a data
|
||
call.
|
||
|
||
>you are doing everyone as disservice by demanding Caller ID
|
||
>info. Why not USE CID if it is given, and voice verify the rest
|
||
>without a hassle? Simple.
|
||
|
||
Why should the system operator have to take the time to do voice
|
||
verifications, when there are faster, easier, and more convienent ways
|
||
of validation. Voice verification creates longer delays for validation
|
||
of callers, involves either calling directly, and running up the
|
||
sysop's phone bill, which is generally high enough already, or calling
|
||
collect, in which case the sysop's phone number appears on the user's
|
||
phone bill within a month, removing the sysop's right to privacy. You
|
||
can then end up having to make several calls to voice verify, if the
|
||
person isn't in when you call, etc.
|
||
|
||
>PS: the idea that having CID blocking would make someone
|
||
>prosecutable for un- authorized access is a very silly fantasy.
|
||
|
||
I would suggest that you take a look at Section 342.1 of the Criminal
|
||
Code (Canada). It specifically spells out what is considered the
|
||
offence, and the punnishment. 342.1(1) puts it simply and clearly,
|
||
and very easy to read and understand, as can be seen below:
|
||
|
||
342.1 (1) Every one who, fraudulently and without color of right,
|
||
(a) obtains, directly or indirectly, any computer service,
|
||
(b) by means of an electro-magnetic, acoustic, mechanical or other
|
||
device, intercepts or causes to be intercepted, directly or
|
||
indirectly, any function of a computer system, or
|
||
(c) uses or causes to be used, directly or indirectly, a computer
|
||
system with intent to commit an offence under paragraph (a) or (b),
|
||
or an offence under section 430 in relation to data or a computer
|
||
system
|
||
is guilty of an offence and liable to imprisonment for a term not
|
||
exceeding ten years, or is guilty of an offence punishable on summary
|
||
conviction.
|
||
|
||
(2) In this section,
|
||
|
||
"computer program" means data representing instructions or statements
|
||
that, when executed in a computer system, causes the computer system to
|
||
preform a function;
|
||
|
||
"computer service" includes data processing, and the storage or
|
||
FidoNews 10-14 Page: 9 05 Apr 1993
|
||
|
||
retrieval of data;
|
||
|
||
"computer system" means a device that, or a group of interconnected
|
||
or related devices one or more of which,
|
||
(a) contains computer programs or other data, and
|
||
(b) pursuant to computer programs,
|
||
(i) preforms logic and control, and
|
||
(ii) may preform any other function;
|
||
|
||
"data" means representations of information or of concepts that are
|
||
being prepared or have been prepared in a form suitable for use in a
|
||
computer system;
|
||
|
||
"electro-magnetic, acoustic, mechanical or other device" means any
|
||
device or apparatus that is used or is acapable of being used to
|
||
intercept any function of a computer system, but does not include a
|
||
hearing aid used to correct subnormal hearing of the user to not better
|
||
than normal hearing.
|
||
|
||
"function" includes logic, control, arithmetic, deletion, storage and
|
||
communication or telecommunication to, from or within a computer system;
|
||
|
||
"intercept" included listen to or record a function of a computer
|
||
system, or acquire the substance, meaning, or purport thereof.
|
||
R.S. 1985, c27
|
||
|
||
Section 430, as mentioned in the above, is in regards to mischief, and
|
||
mischief in relation to data, including destruction of data.
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
OS2 echos
|
||
From: Byron Miller (1:106/433)
|
||
|
||
Well, here is my first posting to fidonews, and i thought i would pass
|
||
on some interesting info to my fellow OS/2 SysOps
|
||
|
||
As you may have seen, OS/2 has been growing, and Very Rapidly. Many SysOps
|
||
Are slowly Converting there BBS over to OS/2, but i hear lots of complaints
|
||
about the limited supply of OS/2 speceific BBS software. Pete Norloff
|
||
has taken the stand has started the OS2BBS_DEV echo...
|
||
|
||
This echo is for the Discussion of OS/2 BBS programing and requests and
|
||
ideas that people would like to see in a BBS System. Many OS/2 programmers
|
||
are starting to find their way to the echo, and we are looking for some
|
||
more talented people to jump in..
|
||
|
||
The following Systems carry the echo, and would happily send it to you
|
||
upon request.
|
||
|
||
1:292/60 1:280/304
|
||
1:110/535 1:289/27
|
||
1:202/514 1:201/2104
|
||
1:273/714
|
||
|
||
FidoNews 10-14 Page: 10 05 Apr 1993
|
||
|
||
I Hope to see some great programmers jump in, and look forward to seeing
|
||
the Best BBS packages for OS/2 anytime soon..
|
||
|
||
And while were discussing OS/2... you might like to find out more info
|
||
so here are some of the Non-Backbone Echo's that Might be of Interest
|
||
to All.
|
||
|
||
OS2BEGIN Beginners Questions And Answers
|
||
OS2BBS_DEV Developing/Programming OS/2 specific BBS software/utils
|
||
OS2CDROM Using CD-ROMS with OS/2
|
||
OS2COMM Communications with OS/2 via networks such as TCP/IP
|
||
OS2DP Development/Use of Databases under OS/2
|
||
OS2DOS Using/Configuring programs to run under OS/2 DOS box
|
||
OS2GAMES Running games under OS/2, great info to get Games to work right
|
||
OS2REXX Programming and using REXX under OS/2
|
||
OS2VIDEO Video Drivers, hardware, and configuring options
|
||
OS2WPS Using the OS/2 "W"ork "P"lace "S"hell
|
||
OS2WP Word Processing under OS/2
|
||
OS2_13 Using, Discussion about OS/2 1.3
|
||
TEAMOS2 Users sharing ideas on use of OS/2 and its promotion.
|
||
|
||
These echos are available on MANY OS/2 BBS's and should be requestable from
|
||
the nodes listed above.
|
||
|
||
Hope to see many of you in Fidonet in these echos!
|
||
|
||
Byron Miller
|
||
SysOp of North Shore BBS (OS/2 BBS of Course)
|
||
1:106/433
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
Policy Proposals: The Cart Before the Horse?
|
||
Jack Decker
|
||
Fidonet 1:154/8
|
||
|
||
Policy Proposals: The Cart Before the Horse?
|
||
|
||
I've been reading the articles on the proposed revisions to Policy 4,
|
||
and while I agree that there is a crying need to replace Policy 4, I
|
||
get the feeling that both proposals are an attempt to provide better
|
||
ways to put out flames without ever addressing the actual cause of the
|
||
fires.
|
||
|
||
I just want to make a couple of comments that I wish the authors of
|
||
these proposals would consider. First and most important, please let
|
||
technology take care of technological problems. Fidonet policy is
|
||
primarily a political document, telling us how we are supposed to
|
||
interact with each other. The trouble is, it is so long that many
|
||
sysops never read the whole thing, and fewer remember enough of what
|
||
they read to really affect their day-to-day operations. Fidonet isn't
|
||
a government, it's a hobby, so why try to make governmental type
|
||
regulations?
|
||
|
||
Suppose we could spend less time worrying about how people in Fidonet
|
||
FidoNews 10-14 Page: 11 05 Apr 1993
|
||
|
||
relate to each other? We'd have fewer flames, our policy document
|
||
could be shorter and more concise, and everyone would lead a generally
|
||
happier life (one would hope so, anyway)!
|
||
|
||
What are the major causes of flames and disagreements in Fidonet? No,
|
||
I don't mean the APPARENT cause, I mean the ROOT cause. These are
|
||
often two entirely different things. Many policies were invoked to
|
||
solve specific problems that may have been known only to a few. These
|
||
root problems were responsible for the creation of perhaps a whole body
|
||
of policy (formal or informal) that may now be a problem in itself.
|
||
|
||
As an example, consider that the ever-expanding size of the Fidonet
|
||
nodelist has been responsible for a whole host of proposals, the net
|
||
effect of which would be to exclude some nodes from the nodelist. Many
|
||
of the arguments over what status points should have could be more
|
||
easily resolved if points could somehow be included in the nodelist,
|
||
but at this point NO ONE wants to see the nodelist grow any larger.
|
||
|
||
Or consider the totally screwed up format of Fidonet echomail messages.
|
||
I have yet to hear from anyone who does not agree that the current
|
||
Fidonet message format leaves a lot to be desired (and is a
|
||
programmer's nightmare!), but what you may not realize is that the lack
|
||
of effective duplicate message control was in part responsible for some
|
||
of the ridiculous geographic restrictions found in Fidonet policy (at
|
||
least, that was the claim at the time the restrictions were added...
|
||
more on that later).
|
||
|
||
How do we deal with these problems? Unfortunately, because few seem to
|
||
recognize the root cause of such problems, we attempt political fixes
|
||
that no one's really happy with (not even the so-called power mongers
|
||
after a while, because they become targets for all the flak). I would
|
||
like to suggest that any new Policy document should give us some
|
||
mechanism for effecting TECHNICAL changes to Fidonet that could do far
|
||
more to help us solve our problems than any amount of words on paper
|
||
ever could.
|
||
|
||
Therefore, I'd like to make a couple of proposals for the next Policy
|
||
document:
|
||
|
||
First, give at least the IC, and hopefully others in Fidonet the right
|
||
to open discussion on technical matters in Fidonet, with the idea of
|
||
setting or revising Fidonet technical standards. This should be at
|
||
least a semi-orderly process and should include specific time frames
|
||
for each part of the process. Here's one possible outline of the
|
||
process:
|
||
|
||
1) Initial discussion phase: Is it broke? Do we need to fix it? What
|
||
would we like to see in any new proposals? (Example: Do we need a new
|
||
nodelist format? Should we stop issuing a nodelist covering all zones?
|
||
What are the problems with the present format?)
|
||
|
||
2) Request for proposals: In this phase we ask interested groups or
|
||
individuals to submit FORMAL proposals for the new standard. There
|
||
should be a deadline date for this!
|
||
|
||
FidoNews 10-14 Page: 12 05 Apr 1993
|
||
|
||
3) Discussion of proposals: A time period where the proposals are made
|
||
available to any interested party. Comments go back to the authors of
|
||
the proposals, who basically have the freedom to modify their proposals
|
||
based on user input. Consolidation of similar proposals would be
|
||
encouraged.
|
||
|
||
4) Release of final draft of proposals: After comments have been
|
||
received, the authors would release their final drafts of their
|
||
proposals.
|
||
|
||
5) Vote on the proposals: At this point the proposals under
|
||
consideration would be voted on. If no one proposal receives a clear
|
||
majority, a runoff vote may be necessary. Again, a specific date
|
||
should be set for the vote, lest it be put off indefinitely (it's only
|
||
a hobby, so folks tend to procrastinate)!
|
||
|
||
6) Implementation of the proposals: This should be far enough in the
|
||
future to allow software authors time to make any adjustments needed to
|
||
their software.
|
||
|
||
Again, the above is only a possible outline. My point is that we need
|
||
SOME sort of mechanism like this, clearly defined in Policy. The
|
||
current system (arguing the subject in the NET_DEV echo until everyone
|
||
is sick of it!) doesn't make it. If the current system worked,
|
||
something would have been done about the nodelist problem years ago.
|
||
As it is, we are helpless to make needed technical changes because we
|
||
have no official mechanism in place to make those changes. This is
|
||
something that REALLY needs to be included in the next Policy, in my
|
||
opinion.
|
||
|
||
I mentioned the Fidonet message format earlier. Just about all the
|
||
technically-minded folks agree it's a nightmare, yet I think probably
|
||
thousands of person-hours of effort have gone into creating proposals
|
||
for a new message format. Some were posted in NET_DEV, some were
|
||
published in Fidonews, but in the end they all suffered the same fate:
|
||
They were all eventually ignored! Not because the proposals were all
|
||
bad, but because there's simply no process in place that allows them to
|
||
be formally considered by the net as a whole.
|
||
|
||
Now, I personally think we should just adopt the standard message
|
||
format used in the Internet (as described in Internet document RFC-1136
|
||
and similar documents), possibly with some Fidonet-specific extensions
|
||
(message header lines that start with "X-FTN-<keyword>:" for Fidonet
|
||
specific information). This would make us far more compatible with the
|
||
Internet, and avoid all the pitfalls now associated with
|
||
echomail-to-newsgroup conversion (something that a growing number of
|
||
sysops seem to be interested in). But in any case, something needs to
|
||
be done, because many of our flame wars can be traced to the message
|
||
format!
|
||
|
||
Why?!?, I hear you ask. Well, consider that the insane geographic
|
||
restrictions found in Policy 4 were only added in that document... that
|
||
is to say, there were no such restrictions in Policy 3 and earlier
|
||
documents. And the important thing to keep in mind is that the
|
||
justification for adding these restrictions was almost entirely based
|
||
FidoNews 10-14 Page: 13 05 Apr 1993
|
||
|
||
on on the existence of dupe loops in echomail. Now, some of us may
|
||
believe that wasn't the REAL reason (in fact, one report that came to
|
||
me was that the restrictions were added at the request of ONE RC who
|
||
didn't like the idea that nodes could "opt out" of being in HIS region)
|
||
but it doesn't really matter; the point is that the (POLITICAL)
|
||
restrictions were justified due to the (TECHNICAL) problems of echomail
|
||
dupes! As it turned out, the restrictions didn't fix the problem (in
|
||
fact, the greatest advances in duplicate message elimination have come
|
||
about because of improved software that catches and rejects dupes) but
|
||
we have to live with them.
|
||
|
||
And, of course, the geographic restrictions remove the option of
|
||
"voting with your feet" (in a figurative sense) if you can't get along
|
||
with the NC or RC above you. I don't mean to sound provincial, but it
|
||
surprises me especially that North American sysops who would scream
|
||
bloody murder if told they could only shop at one particular
|
||
supermarket or eat at one particular restaurant (based solely on where
|
||
they live) will so easily accept the notion that they can participate
|
||
in their hobby via only one point of contact based on their geographic
|
||
location.
|
||
|
||
Many of the disputes we have in Fidonet could be resolved rather
|
||
painlessly (for all concerned) if folks who just plain don't like each
|
||
other weren't forced to interact with each other. Consider all the
|
||
messages you've read were someone didn't get along with their NC or
|
||
RC... wouldn't it save us all a lot of anguish if that person could
|
||
simply find another net to join? Yeah, I know that for some reason
|
||
that concept is considered heresy in Fidonet, but I don't understand
|
||
why. The Internet, and many other nets work quite well without
|
||
imposing such stupid restrictions (although the Internet has what might
|
||
be considered an opposite problem... because folks there AREN'T
|
||
required to associate with each other, it sometimes happens that
|
||
someone who wants a feed can't get one locally, because none of the
|
||
local folks already connected to the Internet want to give a feed to
|
||
the new person. I'm NOT saying we should go to that extreme... sysops
|
||
should be ALLOWED to join their local net, but not REQUIRED to).
|
||
|
||
So, along with some mechanism for getting technical changes implemented
|
||
in Fidonet, I'd like to see the removal of sections of Policy that
|
||
attempt to compensate for technical shortcomings with political
|
||
solutions. The ridiculous geographic restrictions are a prime example,
|
||
but there are other such things buried in there. Maybe we could even
|
||
shorten Policy enough so that folks would READ it!
|
||
|
||
Anyway, please give this some consideration, and please remember that
|
||
Fidonet Policy affects all sysops in all zones, and we should not
|
||
lightly add things to Policy just to resolve some specific local
|
||
conflict. But above all, don't put the "cart before the horse" by just
|
||
adding new regulations without giving us some way to fix the underlying
|
||
technical problems. Let's start finding technical solutions to those
|
||
problems!
|
||
FidoNews 10-14 Page: 14 05 Apr 1993
|
||
|
||
|
||
Rebuttal to an Anonymous Critic
|
||
|
||
A Non-Anonymous Reply on Policy Draft Differences
|
||
Ken Tuley, 1:374/98
|
||
|
||
Having openly asked for comments and suggestions in every
|
||
echomail and netmail contact in which I have discussed ideas for
|
||
future Policy, I was a little disappointed to see the level of
|
||
disinformation included in the article in FNEWSA12 by an
|
||
anonymous "analyst". Hopefully, those who went on to read the
|
||
draft itself could see through the smoke and mirrors of selective
|
||
quoting and recombination of statements, but I feel compelled to
|
||
respond for the sake of clarity. Also for clarity, I have taken
|
||
the liberty of replacing references to the draft with its name as
|
||
distributed [DRAFT008].
|
||
|
||
> [DRAFT008] 4.1C
|
||
> NC,RC selection not specific, each net Democratic
|
||
> has its own method elections
|
||
> one sysop
|
||
one
|
||
> vote. Term
|
||
is
|
||
> No term two years
|
||
|
||
These are specifically designated as being determined by local
|
||
policies developed by the SYSOPS of those nets/regions.
|
||
|
||
> (Policy 4.1C requires a 2/3 majority of the Zone Coordinators
|
||
to
|
||
> elect an Internation Coordinator. [DRAFT008] requires just a
|
||
> majority of the ZCs and give control of the election to the RCs
|
||
if
|
||
> the ZCs can't seem to come up with a winner.)
|
||
|
||
Given the difficulty 10 zone 1 RCs had deciding on a ZC, it
|
||
seemed reasonable to allow a fall-back selection process that
|
||
involved a larger voting pool. The difference between "majority"
|
||
and "2/3" is a single person.
|
||
|
||
> Replacement of By RC,ZC regardless 20% below can
|
||
call > NC,RC of sysops a sysop
|
||
election.
|
||
> wishes. to
|
||
replace,limited
|
||
|
||
The interesting distinction here is that 4.1c continues to make
|
||
the RC responsible for the NCs (and ZC for RCs), but provides no
|
||
authority to act. DRAFT008 provides for the TEMPORARY
|
||
replacement of an RC or NC sho is not performing his duties only
|
||
until the local policy can be invoked to select a replacement.
|
||
The *C is obligated to support the wishes of the majority of
|
||
sysops in the affected net/region.
|
||
|
||
FidoNews 10-14 Page: 15 05 Apr 1993
|
||
|
||
> The Policy 4.1C proposal gives SYSOPS the authority to recall
|
||
or
|
||
> replace coordinators whom they feel are not performing.
|
||
|
||
What about the *C above who is responsible for his actions??
|
||
|
||
> [DRAFT008] on the other hand, gives unlimited authority to the
|
||
RCs
|
||
> to replace an NC, and unlimited authority to the ZC to replace
|
||
an
|
||
> RC.
|
||
|
||
Not unlimited... The RC may remove an NC for failure to perform
|
||
the duties listed in Fidonet Policy and HAVE THE NET MEMBERSHIP
|
||
SELECT A REPLACEMENT. The same applies to the ZC for an RC.
|
||
|
||
Under [DRAFT008], all 2000 sysops in a Region could object to
|
||
the
|
||
removal of their RC, yet the ZC would still have the authority to
|
||
do
|
||
so.)
|
||
|
||
> Local policies
|
||
|
||
> The 4.1C proposal keeps a unified Fidonet under one basic set
|
||
of
|
||
> guidelines. It also provides for the implementation of local
|
||
> policies provided that they are not more RESTRICTIVE than 4.1C
|
||
> itself.
|
||
|
||
This is essentially the same in both drafts, except that DRAFT008
|
||
gives an example of one thing that might "ordinarily" be in a
|
||
local policy.
|
||
|
||
> [DRAFT008] allows for local definition of what should be
|
||
net-wide.
|
||
> Like what "excessively annoying" is.)
|
||
|
||
Wrong! DRAFT008 refers to "Fidonet Policy" for the definition of
|
||
excessively annoying. It simply requires that applicants for
|
||
node numbers familiarize themselves with applicable local
|
||
policies as well.
|
||
|
||
> Points Access can be refused no change
|
||
from
|
||
> existing
|
||
|
||
Since any sysop may refuse access to any user, neither of these
|
||
is a change from existing policy. DRAFT008 simply reinforces the
|
||
fact than running a mailer as a point does not automatically
|
||
grant you access to all systems.
|
||
|
||
> Excommunications Notice to next level no change
|
||
from
|
||
> required existing
|
||
FidoNews 10-14 Page: 16 05 Apr 1993
|
||
|
||
|
||
No argument here. I would expect most excommunications to be
|
||
appealed, so I believe it reasonable to notify the *C above if
|
||
you have done so. It just prevents surprises.
|
||
|
||
> Policy Ratification Can be selectively Whole
|
||
document
|
||
> changed by section. must be
|
||
presented
|
||
|
||
> (Fidonet has always adopted entire policy documents, not
|
||
amendments
|
||
> by section. The reasons why are even stated in current policy.
|
||
|
||
The reason stated is "to simplify the process". I think the
|
||
sysops of Fidonet are capable of dealing with sectional
|
||
amendments, and allowing them helps to focus attention on the
|
||
specific changes offered. Besides, "always" is a misdirected
|
||
term, since provisions for adoption of new policies didn't even
|
||
exist prior to the current policy.
|
||
|
||
> (A significant change in 4.1C over current policy is that it
|
||
moves
|
||
> the level of approval of policy referendums DOWN a notch to the
|
||
NC
|
||
> level. [DRAFT008] still gives complete control over policy
|
||
> referendums to the RCs)
|
||
|
||
I have already stated in public discussions that I would support
|
||
addition of a threshold for NCs to trigger a referendum, but the
|
||
4.1c proposal of 5% is absurd (that's 29 NCs at the present
|
||
time). There are more nets than that in the state of Florida
|
||
alone! Something like 50% of the RCs 'or' 20% of the NCs would
|
||
be more reasonable (IMO).
|
||
|
||
> How local policy comes into existence is not specified in
|
||
> [DRAFT008], yet the *C structure is required to abide by it
|
||
when
|
||
> judging "excessively annoying".
|
||
|
||
I don't know where this came from. The *C structure is required
|
||
to abide by local policies in recognizing the *C selected under
|
||
it, but the section on resolution of disputes that talks about
|
||
excessively annoying behavior makes no reference to local
|
||
policies.
|
||
|
||
> [DRAFT008] introduces more uncertainty into Fidonet as there
|
||
can be
|
||
> as many "policies" on a local level as there are
|
||
nets+regions+zones
|
||
> and they may CONFLICT with each other.
|
||
Granted, but they may not conflict with any policy above them.
|
||
This is already the case. Some nets have policies on cost
|
||
recovery, outbound netmail routing, hub responsibilities and
|
||
other procedures that vary from one net to another. I don't see
|
||
FidoNews 10-14 Page: 17 05 Apr 1993
|
||
|
||
this as a problem.
|
||
|
||
The biggest difference between DRAFT008 and 4.1c is in where the
|
||
responsibility lies to make the democratic process work.
|
||
DRAFT008 puts it in the hands of the local sysops through
|
||
encouragement of local policies consistent with Fidonet Policy.
|
||
4.1c puts it in the hands of the IC to develop some unknown
|
||
future procedure for accomplishing its goals.
|
||
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
FidoNet Policy Document Version 5
|
||
FidoNet Policy Document
|
||
|
||
Version 5
|
||
Draft 008
|
||
03/12/93
|
||
|
||
1 Overview
|
||
|
||
This document establishes the policy for sysops who are members
|
||
of the FidoNet organization of electronic mail systems. FidoNet
|
||
is defined by a NodeList issued weekly by the International
|
||
Coordinator.
|
||
|
||
Separate policy documents may be issued at the zone, region, or
|
||
net level to provide additional detail on local procedures.
|
||
Ordinarily, these lower- level policies may not contradict this
|
||
policy, but will add procedural information specific to those
|
||
areas, such as methods of coordinator selection. However, with
|
||
the approval of the International Coordinator, local policy can
|
||
be used to implement differences required due to local
|
||
conditions. These local policies may not place additional
|
||
restrictions on membership in FidoNet beyond those included in
|
||
this document, other than enforcement of local mail periods.
|
||
|
||
1.0 Language
|
||
|
||
To facilitate the largest possible readership, all international
|
||
Fidonet documents will be written in English. Translation into
|
||
other languages is encouraged.
|
||
|
||
1.1 Introduction
|
||
|
||
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 (1993) includes over 20,000 systems on six
|
||
continents.
|
||
|
||
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 through their systems.
|
||
FidoNews 10-14 Page: 18 05 Apr 1993
|
||
|
||
|
||
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. Multi-net operation provides the structure.
|
||
Decentralized management provides the control. This document
|
||
describes the procedures which have been developed to manage the
|
||
network.
|
||
|
||
1.2 Organization
|
||
|
||
FidoNet systems are grouped on several levels, and
|
||
administration is decentralized to correspond to these
|
||
groupings. This overview provides a summary of the structure;
|
||
specific duties of the coordinator positions are given later in
|
||
the document.
|
||
|
||
1.2.1 Individual Systems and System Operators
|
||
|
||
The smallest subdivision of FidoNet is the individual system,
|
||
corresponding to a single entry in the nodelist. The system
|
||
operator (sysop) formulates a policy for running the board and
|
||
dealing with users if the sysop provides access to others
|
||
through that node. The sysop must mesh with the rest of the
|
||
FidoNet system to send and receive mail, and the local policy
|
||
must be consistent with other levels of FidoNet. BBS operation
|
||
is not required to be a Fidonet sysop.
|
||
|
||
1.2.1.1 Users
|
||
|
||
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.) 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. (See section 2.1.3.)
|
||
|
||
1.2.1.2 Points
|
||
|
||
A point is a FidoNet-compatible system that is not in the
|
||
nodelist, but communicates with FidoNet through a node referred
|
||
to as a bossnode. A point is generally regarded in the same
|
||
manner as a user, for example, the bossnode is responsible for
|
||
mail from the point. (See section 2.1.3.) Points are addressed
|
||
by using the bossnode's nodelist address; for example, a point
|
||
system with a bossnode of 114/15 might be known as 114/15.12.
|
||
Mail destined for the point is sent to the bossnode, which then
|
||
routes it to the point.
|
||
|
||
In supporting points, the bossnode may make use of a private net
|
||
number which should not be generally visible outside of the
|
||
bossnode-point relationship. 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. Outside the local
|
||
FidoNews 10-14 Page: 19 05 Apr 1993
|
||
|
||
bossnode, a point may be refused access to other Fidonet systems
|
||
since points are considered users and sysops have full control
|
||
over users' access to their systems.
|
||
|
||
1.2.2 Networks and Network Coordinators
|
||
|
||
A network is a collection of nodes in a local geographic area,
|
||
usually defined by an area of convenient telephone calling.
|
||
Networks coordinate their mail activity to decrease cost.
|
||
|
||
The Network Coordinator is responsible for maintaining the list
|
||
of nodes for the network, and for forwarding netmail sent to
|
||
members of the network from other FidoNet nodes. The Network
|
||
Coordinator may make arrangements to handle outgoing netmail,
|
||
but is not required to do so.
|
||
|
||
The Network Coordinator is selected by the nodes of that net.
|
||
Nets are encouraged to formulate policies regarding the
|
||
mechanism for accomplishing this.
|
||
|
||
1.2.2.1 Network Routing Hubs
|
||
|
||
Network Routing Hubs exist only in some networks. They may be
|
||
appointed by the Network Coordinator, in order to assist in the
|
||
management of a large network. The exact duties and procedures
|
||
are a matter for the Network Coordinator and local policy to
|
||
arrange, and will not be discussed here, except that a network
|
||
coordinator may not delegate responsibility to mediate disputes.
|
||
|
||
1.2.3 Regions and Regional Coordinators
|
||
|
||
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.
|
||
|
||
The Regional Coordinator maintains the list of independent nodes
|
||
in the region and accepts nodelist segments from the Network
|
||
Coordinators in the region. These are compiled to create a
|
||
regional nodelist, which is then sent to the Zone Coordinator.
|
||
A Regional Coordinator does not perform message-forwarding
|
||
services for any nodes in the region. The Regional Coordinator
|
||
may participate in netmail routing between the coordinator
|
||
levels, but is not required to do so.
|
||
|
||
Regional Coordinators are selected by the nodes of that region.
|
||
Regions are encouraged to formulate policies regarding the
|
||
mechanism for accomplishing this.
|
||
|
||
1.2.4 Zones and Zone Coordinators
|
||
|
||
A zone is a large geographic area containing many regions,
|
||
covering one or more countries and/or continents.
|
||
|
||
The Zone Coordinator compiles the nodelist segments from all of
|
||
FidoNews 10-14 Page: 20 05 Apr 1993
|
||
|
||
the regions in the zone, and creates the master nodelist and
|
||
difference file, which is then distributed over FidoNet in the
|
||
zone. A Zone Coordinator does not perform message-forwarding
|
||
services for any nodes in the zone. The Zone Coordinator may
|
||
participate in netmail routing among the coordinator levels, but
|
||
is not required to do so.
|
||
|
||
Zone Coordinators are selected by the Net and Regional
|
||
Coordinators in that zone as representatives of the nodes to
|
||
whom they provide service (see section 8.3).
|
||
|
||
1.2.5 Zone Coordinator Council
|
||
|
||
In certain cases, the Zone Coordinators work as a council to
|
||
provide advice to the International Coordinator. The
|
||
arrangement is similar to that between a president and advisors.
|
||
In particular, this council considers inter-zone issues. This
|
||
includes, but is not limited to: working out the details of
|
||
nodelist production, mediating inter-zone disputes, and such
|
||
issues not addressed at a lower level of FidoNet.
|
||
|
||
1.2.6 International Coordinator
|
||
|
||
The International Coordinator coordinates the joint production
|
||
of the master nodelist by the Zone Coordinators.
|
||
|
||
The International Coordinator acts as the chair of the Zone
|
||
Coordinator Council and as the overseer of Fidonet-wide
|
||
elections -- arranging the announcement of referenda, the
|
||
collection and counting of the ballots, and announcing the
|
||
results for those issues that affect FidoNet as a whole.
|
||
|
||
The International Coordinator is selected by the Zone
|
||
Coordinators. See section 7.2.
|
||
|
||
1.2.7 Top-down Organization. Checks and Balances.
|
||
|
||
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.
|
||
|
||
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 coordinator at the next level may
|
||
replace them. For example, a Regional Coordinator who fails to
|
||
FidoNews 10-14 Page: 21 05 Apr 1993
|
||
|
||
perform may be replaced by the Zone Coordinator. Interim
|
||
replacements will be appointed until such time as a formal
|
||
replacement can be selected under the local or regional
|
||
policies. Such appointments will be considered final in the
|
||
absence of such policies.
|
||
|
||
To provide for checks and balances at the highest level of
|
||
FidoNet, there is an exception to this top-down organization.
|
||
The International Coordinator is selected by a majority vote of
|
||
the coordinators of the Zone Coordinators (see section 7.2).
|
||
Similarly, decisions made by the International Coordinator can
|
||
be reversed by the Zone Coordinator Council. Decisions made by
|
||
other coordinators are not subject to reversal by a vote of the
|
||
lower level, but instead are subject to the appeal process
|
||
described in section 9.5.
|
||
|
||
1.3 Definitions
|
||
|
||
1.3.1 FidoNews
|
||
|
||
FidoNews is a weekly newsletter distributed in electronic form
|
||
throughout the network. 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. Contributions are submitted to the node listed in
|
||
Fidonews and in the nodelist for that purpose; a file describing
|
||
the format to be used is available from that and many other
|
||
systems.
|
||
|
||
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.
|
||
|
||
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 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.
|
||
|
||
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
|
||
FidoNews 10-14 Page: 22 05 Apr 1993
|
||
|
||
are described in section 5.6.
|
||
|
||
1.3.3 Zone Mail Hour
|
||
|
||
Zone Mail Hour (ZMH) is a defined time during which all nodes in
|
||
a zone are required to be able to accept netmail. Each Fidonet
|
||
zone defines a ZMH and publishes the time of its ZMH to all
|
||
other Fidonet zones. See sections 2.1.8 and Appendix 1.
|
||
|
||
1.3.4 Nodelist
|
||
|
||
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 Friday, and is available electronically for
|
||
download or file request at no charge. To be included in the
|
||
nodelist, a system must meet the requirements defined by this
|
||
document. No other requirements may be imposed.
|
||
|
||
Partial nodelists (single-zone, for example) may be made
|
||
available at different levels in FidoNet. The full list as
|
||
published by the International Coordinator is regarded as the
|
||
official FidoNet nodelist, and is used in circumstances such as
|
||
determination of eligibility for voting. All parts that make up
|
||
the full nodelist are available on each Zone Coordinator's and
|
||
each Regional Coordinator's system.
|
||
|
||
1.3.5 Excessively Annoying Behavior
|
||
|
||
There are references throughout this policy to "excessively
|
||
annoying behavior", especially in section 9 (Resolution of
|
||
Disputes). It is difficult to define this term, as it is based
|
||
upon the judgement of the coordinator structure. Generally
|
||
speaking, annoying behavior irritates, bothers, or causes harm
|
||
to some other person. It is not necessary to break a law to be
|
||
annoying.
|
||
|
||
There is a distinction between excessively annoying behavior and
|
||
(simply) annoying behavior. For example, there is a learning
|
||
curve that each new sysop must climb, both in the technical
|
||
issues of how to set up the software and the social issues of
|
||
how to interact with FidoNet. It is a rare sysop who, at some
|
||
point in this journey, does not manage to annoy others. Only
|
||
when such behavior persists, after being pointed out to the
|
||
sysop, does it becomes excessively annoying. This does not
|
||
imply that it is not possible to be excessively annoying without
|
||
repetition (for example, deliberate falsification of mail would
|
||
likely be excessively annoying on the very first try), but
|
||
simply illustrates that a certain amount of tolerance is
|
||
extended.
|
||
|
||
See section 9 for more information.
|
||
|
||
1.3.6 Commercial Use
|
||
|
||
FidoNews 10-14 Page: 23 05 Apr 1993
|
||
|
||
FidoNet is an amateur network. Participants spend their own
|
||
time and money to make it work for the good of all the users.
|
||
It is not appropriate for a commercial enterprise to take
|
||
advantage of these volunteer efforts to further their own
|
||
business interests. On the other hand, FidoNet provides a
|
||
convenient and effective means for companies and users to
|
||
exchange information, to the mutual benefit of all.
|
||
|
||
Network Coordinators could be forced to subsidize commercial
|
||
operations by forwarding host-routed netmail, and could even
|
||
find themselves involved in a lawsuit if any guarantee was
|
||
suggested for mail delivery. It is therefore FidoNet policy
|
||
that commercial mail is not to be routed. "Commercial mail"
|
||
includes mail which furthers specific business interests without
|
||
being of benefit to the net as a whole. Examples include
|
||
company- internal mail, inter-corporate mail, specific product
|
||
inquiries (price quotes, for instance), orders and their
|
||
follow-ups, and all other subjects specifically related to
|
||
business.
|
||
|
||
2 Sysop Procedures
|
||
|
||
2.1 General
|
||
|
||
2.1.1 The Basics
|
||
|
||
As the sysop of an individual node, you can generally do as you
|
||
please, as long as you operate a mailer compatible with FTS-0001
|
||
specifications, observe mail events, are not excessively
|
||
annoying to other nodes in FidoNet, and do not promote or
|
||
participate in the distribution of pirated copyrighted software
|
||
or other illegal behavior via FidoNet.
|
||
|
||
2.1.2 Familiarity with Policy
|
||
|
||
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 this policy
|
||
and any applicable local, regional or zone policies before
|
||
requesting a node number.
|
||
|
||
2.1.3 Responsible for All Traffic Entering FidoNet Via the Node
|
||
|
||
The sysop listed in the nodelist entry is responsible for all
|
||
traffic entering FidoNet via that system. This includes (but is
|
||
not limited to) traffic entered by users, points, and any other
|
||
networks for which the system might act as a gateway. If a
|
||
sysop allows "outside" messages to enter FidoNet via the system,
|
||
the gateway system must be clearly identified by FidoNet node
|
||
number as the point of origin of that message, and it must act
|
||
as a gateway in the reverse direction. Should such traffic
|
||
result in a violation of Policy, the sysop must rectify the
|
||
situation as soon as notified.
|
||
|
||
2.1.4 Encryption and Review of Mail
|
||
FidoNews 10-14 Page: 24 05 Apr 1993
|
||
|
||
|
||
FidoNet is an amateur system. Our technology is such that the
|
||
privacy of messages cannot be guaranteed. As a sysop, you have
|
||
the right to review traffic flowing through your system, if for
|
||
no other reason than to ensure that the system is not being used
|
||
for illegal or commercial 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 path constitutes annoying behavior. See
|
||
section 1.3.6 for a definition of commercial traffic.
|
||
|
||
2.1.5 No Alteration of Routed Mail
|
||
|
||
You may not modify, other than as required for routing or other
|
||
technical purposes, any message, netmail or echomail, passing
|
||
through the system from one FidoNet node to another. If you are
|
||
offended by the content of a message, the procedure described in
|
||
section 2.1.7 must be used.
|
||
|
||
2.1.6 Private Netmail
|
||
|
||
The word "private" should be used with great care, especially
|
||
with users of a BBS. Some countries have laws which deal with
|
||
"private mail", and it should be made clear that the word
|
||
"private" does not imply that no person other than the recipient
|
||
can read messages. Sysops who cannot provide this distinction
|
||
should consider not offering users the option of "private mail".
|
||
|
||
If a user sends a "private message", the user has no control
|
||
over the number of intermediate systems through which that
|
||
message is routed. A sysop who sends a message to another sysop
|
||
can control this aspect by sending the message direct to the
|
||
recipient's system, thus guaranteeing that only the recipient or
|
||
another individual to whom that sysop has given authorization
|
||
can read the message. Thus, a sysop may have different
|
||
expectations than a casual user.
|
||
|
||
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, unless the traffic has been
|
||
released by the author or the recipient or is a part of a formal
|
||
policy complaint. 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.
|
||
|
||
2.1.6.2 Private mail addressed to you
|
||
|
||
The issue of private mail which is addressed to you is more
|
||
difficult than the in-transit question treated in the previous
|
||
section. A common legal opinion holds that when you receive a
|
||
message it becomes your property and you have a legal right to
|
||
do with it what you wish. Your legal right does not excuse you
|
||
from annoying others.
|
||
FidoNews 10-14 Page: 25 05 Apr 1993
|
||
|
||
|
||
In general, sensitive material should not be sent using FidoNet.
|
||
This ideal is often compromised, as FidoNet is our primary mode
|
||
of communication. In general, if the sender of a message
|
||
specifically requests in the text of the message that the
|
||
contents be kept confidential, release of the message into a
|
||
public forum may be considered annoying.
|
||
|
||
There are exceptions. If someone is saying one thing in public
|
||
and saying the opposite in private mail, the recipient of the
|
||
private mail should not be subjected to harassment simply
|
||
because the sender requests that the message not be released.
|
||
Judgement and common sense should be used in this area as in all
|
||
other aspects of FidoNet behavior.
|
||
|
||
2.1.7 Not Routing Mail
|
||
|
||
You are not required to route traffic if you have not agreed to
|
||
do so. You are not obligated to route traffic for all if you
|
||
route it for any, except as required of a Net Coordinator if you
|
||
hold that position. Routing traffic through a node not
|
||
obligated to perform routing without the permission of that node
|
||
may be annoying behavior. This includes unsolicited echomail.
|
||
|
||
If you do not forward a message when you 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. (It is not necessary to return
|
||
messages which are addressed to a node which is not in the
|
||
current nodelist.) Intentionally stopping an in-transit message
|
||
without following this procedure constitutes annoying behavior.
|
||
In the case of a failure to forward traffic due to a technical
|
||
problem, it does not become annoying unless it persists after
|
||
being pointed out to the sysop.
|
||
|
||
2.1.8 Exclusivity of Zone Mail Hour
|
||
|
||
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 during this time
|
||
using the protocol defined in the current FidoNet Technical
|
||
Standards Committee publication (FTS-0001 at 2this writing). It
|
||
is permissible to have greater capability (for example, to
|
||
support additional protocols or extended mail hours), but the
|
||
minimum requirement is FTS-0001 capability during this one hour
|
||
of the day.
|
||
|
||
This time is exclusively reserved for netmail. Many phone
|
||
systems charge on a per-call basis, regardless of whether a
|
||
connect, no connect, or busy signal is encountered. For this
|
||
reason, any activity other than normal network mail processing
|
||
that ties up a system during ZMH is considered annoying
|
||
behavior. Echomail should not be transferred during ZMH. User
|
||
(BBS) access to a system is prohibited during ZMH. File
|
||
requests should not be honored during ZMH.
|
||
FidoNews 10-14 Page: 26 05 Apr 1993
|
||
|
||
|
||
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 as
|
||
defined in local policy.
|
||
|
||
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 listings affect each member of FidoNet, since they take
|
||
up space in everyone's nodelist. Private listings which are for
|
||
the convenience of one sysop (at the expense of every other
|
||
sysop in FidoNet) are a luxury which is no longer possible.
|
||
Non-essential redundant listings (more than one listing for the
|
||
same telephone number, except as mandated by FTSC standards)
|
||
also fall into this category. Sysops requesting private or
|
||
redundant listings must justify them with a statement explaining
|
||
how they benefit the local net or FidoNet as a whole. The
|
||
Network Coordinator or Regional Coordinator may review this
|
||
statement at any time and listings which are not justified will
|
||
be removed.
|
||
|
||
2.1.10 Observing Mail Events
|
||
|
||
Failure to observe the proper mail events is grounds for any
|
||
node to be dropped from FidoNet without notice (since notice is
|
||
generally given by netmail).
|
||
|
||
2.1.11 Use of Current Nodelist
|
||
|
||
Network mail systems generally operate unattended, and place
|
||
calls at odd hours of the night. If a system tries to call an
|
||
incorrect or out-of-date number, it could cause some poor
|
||
citizen's phone to ring in the wee hours of the morning, much to
|
||
the annoyance of innocent bystanders and civil authorities. For
|
||
this reason, a sysop who sends mail is obligated to obtain and
|
||
use the most recent edition of the nodelist as is practical.
|
||
|
||
2.1.12 Excommunication
|
||
|
||
A system which has been dropped from the network is said to be
|
||
excommunicated (i.e. denied communication). If you find that
|
||
you have been excommunicated without warning, your coordinator
|
||
was unable to contact you. You should rectify the problem and
|
||
contact your coordinator.
|
||
FidoNews 10-14 Page: 27 05 Apr 1993
|
||
|
||
|
||
Systems may also be dropped from the nodelist for cause. See
|
||
sections 4.3, 5.2, and 9.
|
||
|
||
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.
|
||
|
||
2.1.13 Timing of Zone Mail Hour
|
||
|
||
The exact timing of Zone Mail Hour for each zone is set by the
|
||
Zone Coordinator. See Appendix 1.
|
||
|
||
2.1.14 Non-observance of Daylight Savings Time
|
||
|
||
FidoNet does not observe daylight savings time. In areas which
|
||
observe daylight savings time the FidoNet mail schedules must be
|
||
adjusted in the same direction as the clock change.
|
||
Alternatively, you can simply leave your system on standard time.
|
||
|
||
2.2 How to obtain a node number
|
||
|
||
You must first obtain a current nodelist so that you can send
|
||
mail. You do not need a node number to send mail, but you must
|
||
have one in order for others to send mail to you.
|
||
|
||
The first step in obtaining a current nodelist is to locate a
|
||
FidoNet bulletin board. Most bulletin board lists include at
|
||
least a few FidoNet systems, and usually identify them as such.
|
||
Use a local source to obtain documents because many networks
|
||
have detailed information available which explains the coverage
|
||
area of the network and any special requirements or procedures.
|
||
|
||
Once you have a nodelist, you must determine which network or
|
||
region covers your area. Regions are numbered 10-99; network
|
||
numbers are greater than 99. Networks are more restricted in
|
||
area than regions, but are preferred since they improve the flow
|
||
of mail and provide more services to their members. If you
|
||
cannot find a network which covers your area, then pick the
|
||
region which does.
|
||
|
||
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, as
|
||
this indicates that your system has FidoNet capability.
|
||
|
||
You must set up your software so that the from-address in your
|
||
message does not cause problems for the coordinator who receives
|
||
it. If you pick the address of an existing system, this will
|
||
cause obvious problems. If your software is capable of using
|
||
address -1/-1, this is the traditional address used by potential
|
||
sysops. Otherwise use net/9999 (e.g. if you are applying to net
|
||
123, set your system up as 123/9999). Many nets have specific
|
||
FidoNews 10-14 Page: 28 05 Apr 1993
|
||
|
||
instructions available to potential sysops and these procedures
|
||
may indicate a preference for the from-address.
|
||
|
||
The message you send must include at least the following
|
||
information:
|
||
|
||
1) Your name.
|
||
2) The phone number to be used when calling your system.
|
||
3) The name of your system.
|
||
4) The city and state where your system is located.
|
||
5) Your voice phone number.
|
||
6) Your hours of netmail operation.
|
||
7) The maximum baud rate you can support.
|
||
8) The type of mailer software and modem you are using.
|
||
|
||
Your coordinator may contact you for additional information.
|
||
All information submitted will be kept confidential and will not
|
||
be supplied to anyone except the person who assumes the
|
||
coordinator position at the resignation of the current
|
||
coordinator.
|
||
|
||
You must indicate that you have read, and agree to abide by,
|
||
this document and all the current policies of FidoNet.
|
||
|
||
Please allow at least two weeks for a node number request to be
|
||
processed. If you send your request to a Regional Coordinator,
|
||
it may forwarded to the appropriate Network Coordinator.
|
||
|
||
2.3 If You are Going Down
|
||
|
||
If your node will be down for an extended period (more than a
|
||
day or two), inform your coordinator as soon as possible. It is
|
||
not your coordinator's responsibility to chase you down for a
|
||
status report, and if your system stops accepting mail it will
|
||
be removed from the nodelist.
|
||
|
||
Never put an answering machine or any other device which answers
|
||
the phone on your phone line while you are down. If you do,
|
||
calling systems will get the machine repeatedly, producing large
|
||
phone bills, which is very annoying. In short, the only thing
|
||
which should ever answer the telephone during periods when the
|
||
nodelist indicates that your node will accept mail is
|
||
FidoNet-compatible software which accepts mail.
|
||
|
||
If you will be leaving your system unattended for an extended
|
||
period of time (such as while you are on vacation), you should
|
||
notify your coordinator. Systems have a tendency to "crash" now
|
||
and then, so you will probably want your coordinator to know
|
||
that it is a temporary condition if it happens while you are
|
||
away.
|
||
|
||
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
|
||
FidoNews 10-14 Page: 29 05 Apr 1993
|
||
|
||
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.
|
||
|
||
The first step is to contact the other sysops in your area. You
|
||
must decide which nodes will comprise the network, and which of
|
||
those nodes you would like to be the Network Coordinator. Then
|
||
consult your Regional Coordinator. You must send the following
|
||
information:
|
||
|
||
1) The region number(s), or network number(s) if a network is
|
||
splitting up, that are affected by the formation of your
|
||
network. The Regional Coordinator will inform the Zone
|
||
Coordinator and the coordinators of any affected networks that a
|
||
new network is in formation.
|
||
|
||
2) A copy of the proposed network's nodelist segment. This file
|
||
should be attached to the message of application for a network
|
||
number, and should use the nodelist format described in the
|
||
current version of the appropriate FTSC publication. Please
|
||
elect a name that relates to your grouping, for example SoCalNet
|
||
for nodes in the Southern California Area and MassNet West for
|
||
the Western Massachusetts Area. Remember if you call yourself
|
||
DOGNET it doesn't identify your area.
|
||
|
||
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.
|
||
|
||
Do not send a network number request to the Zone Coordinator.
|
||
All network number requests must be processed by the Regional
|
||
Coordinator.
|
||
|
||
3 General Procedures for All Coordinators
|
||
|
||
3.1 Make Available Difference Files and FidoNews
|
||
|
||
Each Coordinator is responsible for obtaining and making
|
||
available, on a weekly basis, nodelist difference files and
|
||
FidoNews.
|
||
|
||
3.2 Processing Nodelist Changes and Passing Them Upstream
|
||
|
||
Each coordinator is responsible for obtaining nodelist
|
||
information from the level below, processing it, and passing the
|
||
results to the level above. The timing of this process is
|
||
determined by the requirements imposed by the level above.
|
||
|
||
3.3 Ensure the Latest Policy is Available
|
||
|
||
A Coordinator is responsible to make the current version of this
|
||
document available to the level below, and to encourage
|
||
familiarity with it.
|
||
|
||
FidoNews 10-14 Page: 30 05 Apr 1993
|
||
|
||
In addition, a coordinator is required to forward any local
|
||
policies received 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.
|
||
|
||
3.4 Minimize the Number of Hats Worn
|
||
|
||
Coordinators are encouraged to limit the number of FidoNet
|
||
functions they perform. A coordinator who holds two different
|
||
positions compromises the appeal process. For example, if the
|
||
Network Coordinator is also the Regional Coordinator, sysops in
|
||
that network are denied one level of appeal.
|
||
|
||
Coordinators are discouraged from acting as echomail and
|
||
software- distribution hubs. If they do so, they should handle
|
||
echomail (or other volume distribution) on a system other than
|
||
the administrative system. A coordinator's system should be
|
||
readily available to the levels immediately above and below.
|
||
|
||
Another reason to discourage multiple hats is the difficulty of
|
||
replacing services if someone leaves the network. For example,
|
||
if a coordinator is the echomail hub and the
|
||
software-distribution hub, those services will be difficult to
|
||
restore when that person resigns.
|
||
|
||
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 the region or an independent in the
|
||
region. A Zone Coordinator must be either a member of a network
|
||
in the zone or a regional independent in the zone. The
|
||
International Coordinator must be a Fidonet sysop.
|
||
|
||
3.6 Encourage New Sysops to Enter FidoNet
|
||
|
||
A coordinator is encouraged to operate a public bulletin board
|
||
system which is freely available for the purpose of distributing
|
||
Policy, FidoNews, and Nodelists to potential new sysops.
|
||
Dissemination of this information to persons who are potential
|
||
FidoNet sysops is important to the growth of FidoNet, and
|
||
coordinators should encourage development of new systems.
|
||
|
||
3.7 Tradition and Precedent
|
||
|
||
A coordinator is not bound by the practices of predecessor or
|
||
peers beyond the scope of this document and other applicable
|
||
net, region or zone policies.
|
||
|
||
In addition, a new coordinator has the right to review any
|
||
decision made by predecessors for compliance with Policy, and
|
||
take whatever actions may be necessary to rectify any situations
|
||
not in compliance.
|
||
FidoNews 10-14 Page: 31 05 Apr 1993
|
||
|
||
|
||
3.8 Technical Management
|
||
|
||
The primary responsibility of any coordinator is technical
|
||
management of network operations. Decisions must be made on
|
||
technical grounds.
|
||
|
||
3.9 Review and Acceptance of Lower Policies
|
||
|
||
Individual regions and nets are encouraged to formulate policies
|
||
to deal with local issues not specifically covered in this
|
||
document. It is the responsibility of coordinators to review
|
||
policies submitted from lower levels for compliance with higher
|
||
policies, and to support those policies whenever possible in
|
||
deciding matters related to those areas.
|
||
|
||
In the absence of procedures determined by local/regional
|
||
policies, the coordinator should attempt to act in accordance
|
||
with the interests and wishes of the majority of nodes in the
|
||
affected area.
|
||
|
||
4 Network Coordinator Procedures
|
||
|
||
4.1 Responsibilities
|
||
|
||
A Network Coordinator has the following responsibilities:
|
||
|
||
1) To receive incoming mail for nodes in the network, and
|
||
arrange delivery to its recipients.
|
||
|
||
2) To assign node numbers to nodes in the network.
|
||
|
||
3) To maintain the nodelist segment for the network, and to send
|
||
a copy of it to the Regional Coordinator whenever it changes.
|
||
|
||
4) To make available to nodes in the network new nodelist
|
||
difference files, new issues of FidoNews, and new revisions of
|
||
Network Policy Documents as they are received, and to
|
||
periodically check to insure that nodes use up to date nodelists.
|
||
|
||
5) To make available to nodes in the network information
|
||
regarding Fidonet elections and referenda, to solicit input from
|
||
those nodes and to act as a representative of those nodes in
|
||
such elections when appropriate.
|
||
|
||
4.2 Routing Inbound Mail
|
||
|
||
It is your responsibility as Network Coordinator to coordinate
|
||
the receipt and forwarding of host-routed inbound netmail for
|
||
nodes in your network. The best way to accomplish this is left
|
||
to your discretion.
|
||
|
||
If a node in your network is receiving large volumes of mail you
|
||
can request that the sysop contact the systems which are sending
|
||
this mail and request that they not host-route it. If the
|
||
FidoNews 10-14 Page: 32 05 Apr 1993
|
||
|
||
problem persists, you can request your Regional Coordinator to
|
||
assign the node a number as an independent and drop the system
|
||
from your network.
|
||
|
||
Occasionally a node will make a "bombing run" (sending one
|
||
message to a great many nodes). If a node in another network is
|
||
making bombing runs on your nodes and routing them through your
|
||
inbound host, then you can complain to the network coordinator
|
||
of the offending node. (If the node is an independent, complain
|
||
to the regional coordinator.) Bombing runs are considered to be
|
||
annoying.
|
||
|
||
Another source of routing overload is echomail. Echomail cannot
|
||
be allowed to degrade the ability of FidoNet to handle normal
|
||
message traffic. If a node in your network is routing large
|
||
volumes of echomail, you can ask the sysop to either limit the
|
||
amount of echomail or to stop routing echomail.
|
||
|
||
You are not required to forward encrypted, commercial, or
|
||
illegal mail. However, you must follow the procedures described
|
||
in section 2.1.7 if you do not forward the mail.
|
||
|
||
4.3 Assigning Node Numbers
|
||
|
||
It is your responsibility to assign node numbers to new nodes in
|
||
your network. You may also change the numbers of existing nodes
|
||
in your network, though you should check with your member nodes
|
||
before doing so. You may assign any numbers you wish, so long as
|
||
each node has a unique number within your network.
|
||
|
||
You must not assign a node number to any system until you have
|
||
received a formal request from that system by FidoNet mail.
|
||
This will ensure that the system is minimally operational. The
|
||
strict maintenance of this policy has been one of the great
|
||
strengths of FidoNet.
|
||
|
||
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.
|
||
|
||
You should use network mail to inform a new sysop of the node
|
||
number, as this helps to insure that the system is capable of
|
||
receiving network mail.
|
||
|
||
If a node in your network is acting in a sufficiently annoying
|
||
manner, you can take whatever action you deem appropriate,
|
||
according to the circumstances of the case and due process.
|
||
Notification must be given to the Regional Coordinator if that
|
||
action taken is excommunication of a node.
|
||
|
||
4.4 Maintaining the Nodelist
|
||
|
||
You should implement name changes, phone number changes, and so
|
||
forth in your segment of the nodelist as soon as possible after
|
||
FidoNews 10-14 Page: 33 05 Apr 1993
|
||
|
||
the information is received from the affected node. You should
|
||
also on occasion send a message to every node in your network to
|
||
ensure that they are operational. If a node turns out to be "off
|
||
the air" with no prior warning, you can either mark the node
|
||
down or remove it from the nodelist. (Nodes are to be marked
|
||
DOWN for a maximum of two weeks, after which the line should be
|
||
removed from the nodelist segment.)
|
||
|
||
At your discretion, you may distribute a portion of this
|
||
workload to routing hubs. In this case, you should receive the
|
||
nodelist segments from the these hubs within your network. You
|
||
will need to maintain a set of nodelist segments for each hub
|
||
within your network, since you cannot count on getting an update
|
||
from each hub every week. You should assemble a master nodelist
|
||
segment for your network every week and send it to your Regional
|
||
Coordinator by the day and time designated. It is suggested
|
||
that you do this as late as is practical, so as to accommodate
|
||
any late changes, balanced with the risk of missing the
|
||
connection with your Regional Coordinator and thus losing a week.
|
||
|
||
4.5 Making Available Policies, Nodelists and FidoNews
|
||
|
||
As a Network Coordinator you should obtain a new issue of
|
||
FidoNews and a new nodelist difference file every week from your
|
||
Regional Coordinator. The nodelist difference file is currently
|
||
made available each Friday, and FidoNews is published each
|
||
Monday. You must make these files available to all nodes in the
|
||
network, and you are encouraged to make them available to the
|
||
general public for download.
|
||
|
||
You should also obtain the most recent versions of the Policy
|
||
documents that bind the members of your network, and make those
|
||
available to the nodes in your network. Policies are released
|
||
at sporadic intervals, so you should also inform the nodes in
|
||
your network when such events occur, and ensure the nodes are
|
||
generally familiar with the changes.
|
||
|
||
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.
|
||
|
||
5 Regional Coordinator Procedures
|
||
|
||
5.1 Responsibilities
|
||
|
||
A Regional Coordinator has the following responsibilities:
|
||
|
||
1) To assign node numbers to independent nodes in the region.
|
||
|
||
2) To encourage independent nodes in the region to join existing
|
||
networks, or to form new networks.
|
||
|
||
3) To assign network numbers to networks in the region and
|
||
define their boundaries.
|
||
|
||
FidoNews 10-14 Page: 34 05 Apr 1993
|
||
|
||
4) To compile a nodelist of all of the networks and independents
|
||
in the region, and to send a copy of it to the Zone Coordinator
|
||
whenever it changes.
|
||
|
||
5) To ensure the smooth operation of networks within the region.
|
||
|
||
6) To make new nodelist difference files, Policies, and issues
|
||
of FidoNews available to the Network Coordinators in the region
|
||
as soon as is practical.
|
||
|
||
7) To make available to Net Coordinators and independent nodes
|
||
in the region information regarding Fidonet elections and
|
||
referenda, to solicit input from the independent nodes and to
|
||
act as a representative of those nodes in such elections when
|
||
appropriate.
|
||
|
||
5.2 Assigning Node Numbers
|
||
|
||
It is your responsibility to assign node numbers to independent
|
||
nodes in your region. You may also change the numbers of
|
||
existing nodes in your region, though you should check with the
|
||
respective nodes before doing so. You may assign any numbers you
|
||
wish, so long as each node has a unique number within your
|
||
region.
|
||
|
||
You should not assign a node number to any system until you have
|
||
received a formal request from that system by FidoNet mail.
|
||
This will ensure that the system is minimally operational. The
|
||
strict maintenance of this policy has been one of the great
|
||
strengths of FidoNet.
|
||
|
||
You should use network mail to inform a new sysop of the node
|
||
number, as this helps to insure that the system is capable of
|
||
receiving network mail.
|
||
|
||
If a node in your region is acting in a sufficiently annoying
|
||
manner, you can take whatever action you deem appropriate,
|
||
according to the circumstances of the case and due process.
|
||
Notification must be given to the Zone Coordinator if the action
|
||
taken is the excommunication of a node.
|
||
|
||
If you receive a node number request from outside your region,
|
||
you must forward it to the Regional Coordinator of the
|
||
applicant's region. If you receive a node number request from a
|
||
new node that is in an area covered by an existing network, then
|
||
you must forward the request to the Coordinator of that network
|
||
instead of assigning a number yourself.
|
||
|
||
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, unless those independent node assignments
|
||
were made for reasons of high volume or commercial traffic.
|
||
|
||
5.3 Encouraging the Formation and Growth of Networks
|
||
|
||
FidoNews 10-14 Page: 35 05 Apr 1993
|
||
|
||
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. See section 2.4.
|
||
|
||
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.
|
||
|
||
5.5 Maintaining the Nodelist
|
||
|
||
As a Regional Coordinator, you have a dual role in maintaining
|
||
the nodelist segment for your region.
|
||
|
||
First, you must maintain the list of independent nodes in your
|
||
region. You should attempt to implement name changes, phone
|
||
number changes, and so forth in this nodelist segment as soon as
|
||
possible. You should also on occasion send a message to every
|
||
independent node in your region to ensure that they are
|
||
operational. If a node turns out to be "off the air" with no
|
||
prior warning, you can either mark the node down or remove it
|
||
from the nodelist segment. (Nodes are to marked DOWN for a
|
||
maximum of two weeks, after which the line should be removed
|
||
from the nodelist segment.)
|
||
|
||
Second, you must receive the nodelist segments from the Network
|
||
Coordinators within your region. You will need to maintain a
|
||
set of nodelist segments for each network within your region,
|
||
since you cannot count on getting an update from each Network
|
||
Coordinator every week. You should assemble a master nodelist
|
||
segment for your region every week and send it to your Zone
|
||
Coordinator by the day and time designated. It is suggested
|
||
that you do this as late as practical, so as to accommodate late
|
||
changes, balanced with the risk of missing the connection with
|
||
your Zone Coordinator and thus losing a week.
|
||
|
||
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
|
||
FidoNews 10-14 Page: 36 05 Apr 1993
|
||
|
||
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.
|
||
|
||
5.7 Overseeing Network Operations
|
||
|
||
It is your responsibility as Regional Coordinator to ensure that
|
||
the networks within your region are operating in an acceptable
|
||
manner. This does not mean that you are required to operate
|
||
those networks; that is the responsibility of the Network
|
||
Coordinators. It means that you are responsible for assuring
|
||
that the Network Coordinators within your region are acting
|
||
responsibly.
|
||
|
||
If you find that a Network Coordinator within your region is not
|
||
properly performing the duties outlined in Section 4, you should
|
||
take whatever action you deem necessary to correct the
|
||
situation, up to and including removing the Net Coordinator from
|
||
that position and having the net membership select a replacement.
|
||
|
||
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.
|
||
|
||
It is your obligation as Regional Coordinator to maintain direct
|
||
and reasonably frequent contact with the networks in your
|
||
region. The exact method of accomplishing this is left to your
|
||
discretion.
|
||
|
||
5.8 Making Available Nodelists, Policies, and FidoNews
|
||
|
||
As a Regional Coordinator, it is your responsibility to obtain
|
||
the latest nodelist difference file, network policies, and the
|
||
latest issues of FidoNews as they are published, and to make
|
||
them available to the Network Coordinators within your region.
|
||
The nodelist is posted weekly on Friday by the Zone Coordinator,
|
||
and FidoNews is published weekly on Monday by the node indicated
|
||
in the Fidonews and nodelist. Contact them for more details on
|
||
how to obtain the latest copies each week.
|
||
|
||
It is your responsibility to make these available to all Network
|
||
Coordinators and independent nodes in your region as soon as is
|
||
practical after you receive them. The method of distribution is
|
||
left to your discretion. You are encouraged to make all these
|
||
documents available for downloading by the general public.
|
||
|
||
6 Zone Coordinator Procedures
|
||
|
||
6.1 General
|
||
|
||
FidoNews 10-14 Page: 37 05 Apr 1993
|
||
|
||
A Zone Coordinator for FidoNet has the primary task of
|
||
maintaining the nodelist for the Zone, sharing it with the other
|
||
Zone Coordinators, and ensuring the distribution of the master
|
||
nodelist (or difference file) to the Regions in the Zone. The
|
||
Zone Coordinator is also responsible for coordinating the
|
||
distribution of Fidonet Policy documents and FidoNews to the
|
||
Regional Coordinators in the zone.
|
||
|
||
The Zone Coordinator is responsible for the maintenance of the
|
||
nodelist for the administrative region. The Administrative
|
||
Region has the same number as the zone, and consists of nodes
|
||
assigned for administrative purposes not related to the sending
|
||
and receiving of normal network mail.
|
||
|
||
A Zone Coordinator is charged with the task of ensuring the
|
||
smooth operation of the Zone.
|
||
|
||
If a Zone Coordinator determines that a Regional Coordinator is
|
||
not properly performing the duties outlined in section 5,
|
||
whatever action deemed necessary may be taken, up to and
|
||
including removing the Regional Coordinator from that position
|
||
and having the nodes of the region select a replacement.
|
||
|
||
The Zone Coordinator defines the geographic boundaries of the
|
||
regions within the zone and sets the time for the Zone Mail Hour.
|
||
|
||
The Zone Coordinator is responsible for creating new regions
|
||
within the zone when regions become too large for efficient
|
||
coordination by a single Regional Coordinator.
|
||
|
||
The Zone Coordinator is responsible for reviewing and approving
|
||
any geographic exemptions as described in section 5.6.
|
||
|
||
The Zone Coordinator is responsible for insuring the smooth
|
||
operation of gates between that zone and all other zones for the
|
||
transfer of interzone mail.
|
||
|
||
The Zone Coordinators are responsible for the selection of the
|
||
International Coordinator.
|
||
|
||
6.2 Selection
|
||
|
||
The Zone Coordinator is selected by a majority vote of the Net
|
||
and Regional Coordinators within the zone, voting as
|
||
representatives of their nodes (see section 8.3).
|
||
|
||
7 International Coordinator Procedures
|
||
|
||
7.1 General
|
||
|
||
The International Coordinator has the primary task of
|
||
coordinating the creation of the master nodelist by managing the
|
||
distribution between the Zones of the Zone nodelists. The
|
||
International Coordinator is responsible for definition of new
|
||
zones and for negotiation of agreements for communication with
|
||
FidoNews 10-14 Page: 38 05 Apr 1993
|
||
|
||
other networks. ("Other network" in this context means other
|
||
networks with which FidoNet communicates as peer-to-peer, not
|
||
"network" in the sense of the FidoNet organizational level.)
|
||
|
||
The International Coordinator is also responsible for
|
||
coordinating the distribution of Network Policies and FidoNews
|
||
to the Zone Coordinators.
|
||
|
||
The International Coordinator is responsible for coordinating
|
||
the activities of the Zone Coordinator Council. The
|
||
International Coordinator acts as the spokesman for the Zone
|
||
Coordinator Council.
|
||
|
||
In cases not specifically covered by this document, the
|
||
International Coordinator may issue specific interpretations or
|
||
extensions to this policy. The Zone Coordinator Council may
|
||
reverse such rulings by a majority vote. These extensions are
|
||
valid until such time as a policy referendum may be held to
|
||
ratify or reject such extensions.
|
||
|
||
7.2 Selection
|
||
|
||
The International Coordinator is selected (or removed) by an
|
||
absolute majority vote of the Zone Coordinators with input from
|
||
the Regional Coordinators. In the event that the Zone
|
||
Coordinators are unable to select an International Coordinator
|
||
by absolute majority, the International Coordinator will be
|
||
selected by a majority of the Regional Coordinators.
|
||
|
||
8 Referenda
|
||
|
||
The procedures described in this section are used to ratify a
|
||
new version of FidoNet policy, which is the mechanism by which
|
||
policy is changed. This procedure is also used to impeach a
|
||
Zone Coordinator.
|
||
|
||
8.1 Initiation
|
||
|
||
A referendum on policy modification is invoked when a majority
|
||
of the FidoNet Regional Coordinators inform the International
|
||
Coordinator that they wish to consider a proposed new version of
|
||
Policy.
|
||
|
||
8.2 Announcement and Results Notification
|
||
|
||
Proposed changes to Policy are distributed using the same
|
||
structure which is used to distribute nodelist difference files
|
||
and FidoNews. Results and announcements related to the
|
||
referendum are distributed by the coordinator structure as a
|
||
part of the weekly nodelist difference file. The International
|
||
Coordinator provides copies to the editor of FidoNews for
|
||
inclusion there, although the official announcement and voting
|
||
dates are tied to nodelist distributions.
|
||
|
||
If it is adopted, the International Coordinator sets the
|
||
FidoNews 10-14 Page: 39 05 Apr 1993
|
||
|
||
effective date for a new policy through announcement in the
|
||
weekly nodelist difference file and Fidonews. The effective
|
||
date will be not more than one month after the close of
|
||
balloting.
|
||
|
||
8.3 Eligibility to Vote
|
||
|
||
Each member of the FidoNet coordinator structure at and above
|
||
Network Coordinator is entitled to one vote. In the case of the
|
||
position changing hands during the balloting process, either the
|
||
incumbent or the new coordinator may vote, but not both. If a
|
||
person holds more than one coordinator position, they still
|
||
receive only one vote.
|
||
|
||
Network Coordinators are expected to assess the opinions of the
|
||
members of their network, and to vote accordingly. A formal
|
||
election is not necessary, but the Network Coordinator must
|
||
inform the net of the issues and solicit input. The Network
|
||
Coordinator functions as the representative of the rank and file
|
||
members of FidoNet. Regional Coordinators will fulfill this
|
||
responsibility with regard to independent nodes in their regions.
|
||
|
||
8.4 Voting Mechanism
|
||
|
||
The actual voting mechanism, including whether the ballot is
|
||
secret and how the ballots are to be collected, verified, and
|
||
counted, is left to the discretion of the International
|
||
Coordinator. Ideally, ballot collection should be by some
|
||
secure message system, conducted over FidoNet itself.
|
||
|
||
In order to provide a discussion period, the announcement of any
|
||
ballot must be made at least two weeks before the date of voting
|
||
commencement. The balloting period must be at least two weeks.
|
||
|
||
8.5 Voting on a whole Policy Document or Amendments
|
||
|
||
Policy may be changed as a whole document or by section as
|
||
required. Sections changed must include all cross-references
|
||
affected and the corresponding changes to those sections.
|
||
|
||
Policy changes voted on as whole documents and approved will be
|
||
incremented to the next whole number from the previous version
|
||
number. Sectional changes (including multiple sectional changes
|
||
approved in the same referendum) will increment the policy
|
||
number to the next tenth of the current version number until
|
||
nine tenths is reached. Sectional changes that would go beyond
|
||
nine tenths will increment to the next whole number from the
|
||
previous version number.
|
||
|
||
8.6 Decision of vote
|
||
|
||
A Policy amendment is considered in force if, at the end of the
|
||
balloting period, it has received a majority of the votes cast.
|
||
For example, if there were 350 eligible voters, 100 of which
|
||
cast a vote, then at least 51 affirmative votes would be
|
||
FidoNews 10-14 Page: 40 05 Apr 1993
|
||
|
||
required to declare the amendment in force.
|
||
|
||
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.
|
||
|
||
8.7 Impeachment of a Zone Coordinator
|
||
|
||
8.7.1 Initiation
|
||
|
||
In extreme cases, a Zone Coordinator may be impeached by
|
||
referendum. Impeachment of a Zone Coordinator does not require a
|
||
Policy violation. An impeachment proceeding is invoked when a
|
||
majority of the Regional Coordinators in a zone request the
|
||
International Coordinator to institute it.
|
||
|
||
8.7.2 Procedure as in Policy Referendum
|
||
|
||
The provisions of sections 8.2 and 8.3 apply to impeachment
|
||
referenda.
|
||
|
||
The definition of "majority" in section 8.6 applies. Only
|
||
coordinators in the affected zone vote.
|
||
|
||
8.7.3 Voting Mechanism
|
||
|
||
The balloting procedures are set, the votes are collected, and
|
||
the results are announced by a Regional Coordinator chosen by
|
||
the International Coordinator. The removal of the Zone
|
||
Coordinator is effective two weeks after the end of balloting if
|
||
the impeachment carries.
|
||
|
||
8.7.4 Limited to once per year
|
||
|
||
The removal of a Zone Coordinator is primarily intended to be a
|
||
mechanism by which the zone as a whole expresses displeasure
|
||
with the way Policy is being interpreted. At one time or
|
||
another, everyone is unhappy with the way policy is interpreted.
|
||
In order to keep the Zone Coordinators interpreting policy as
|
||
opposed to defending themselves, at least one full calendar year
|
||
must elapse between impeachment referenda (regardless of how
|
||
many people hold the position of Zone Coordinator during that
|
||
year.)
|
||
|
||
Should a Zone Coordinator resign during an impeachment process,
|
||
the process is considered null and void, and does not consume
|
||
the "once per year quota".
|
||
|
||
9 Resolution of Disputes
|
||
|
||
9.1 General
|
||
|
||
The FidoNet judicial philosophy can be summed up in two rules:
|
||
|
||
1) Thou shalt not excessively annoy others.
|
||
FidoNews 10-14 Page: 41 05 Apr 1993
|
||
|
||
|
||
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!"). It
|
||
must be noted that it is someone's "behavior" (action) that is
|
||
subject to this policy. The content of a person's words or
|
||
opinions is not necessarily sufficient to be considered annoying
|
||
in this context.
|
||
|
||
Actions that would be considered excessively annoying behavior
|
||
include activities that willfully disrupt the operations of one
|
||
or more Fidonet systems; using non-existent or falsified node
|
||
numbers with the intent of disguising the origin of mail traffic
|
||
or of intercepting mail intended for the rightful owner of that
|
||
node number; willfully compromising the integrity of an echomail
|
||
conference after having direct links to that conference severed
|
||
by the conference moderator; or illegal activities that involve,
|
||
pertain to or utilize Fidonet as part of those activities.
|
||
|
||
The first step in any dispute between sysops is for the sysops
|
||
to attempt to communicate directly. Any complaint made that has
|
||
skipped this most basic communication step will be rejected.
|
||
|
||
Filing a formal complaint is not an action which should be taken
|
||
lightly. Investigation and response to complaints requires time
|
||
which coordinators would prefer to spend doing more constructive
|
||
activities. Persons who persist in filing trivial policy
|
||
complaints may find themselves on the wrong side of an
|
||
excessively-annoying complaint. Complaints must be accompanied
|
||
with verifiable evidence, generally copies of messages; a simple
|
||
word-of-mouth complaint will be dismissed out of hand.
|
||
|
||
Failure to follow the procedures herein described (in
|
||
particular, by skipping a coordinator, or involving a
|
||
coordinator not in the appeal chain) is in and of itself
|
||
annoying behavior.
|
||
|
||
9.2 Problems with Another Sysop
|
||
|
||
If you are having problems with another sysop, you should first
|
||
try to work it out directly with the other sysop.
|
||
|
||
If this fails to resolve the problem, you should complain to
|
||
other sysop's Network Coordinator. If that sysop is not in a
|
||
network, then complain to the appropriate Regional Coordinator.
|
||
Should this fail to provide satisfaction, you have the right to
|
||
follow the appeal process described in section 9.5.
|
||
|
||
9.3 Problems with your Network Coordinator
|
||
|
||
If you are having problems with your Network Coordinator and
|
||
feel that you are not being treated properly, you are entitled
|
||
FidoNews 10-14 Page: 42 05 Apr 1993
|
||
|
||
to a review of your situation. As with all disputes, the first
|
||
step is to communicate directly to attempt to resolve the
|
||
problem.
|
||
|
||
The next step is to contact your Regional Coordinator. If your
|
||
case has merit, there are several possible courses of action,
|
||
including a change of Network Coordinators or even the
|
||
disbanding of your network. If you have been excommunicated by
|
||
your Network Coordinator, that judgement may be reversed, at
|
||
which point you will be reinstated into your net.
|
||
|
||
If you fail to obtain relief from your Regional Coordinator, you
|
||
have the right to follow the appeal process described in section
|
||
9.5.
|
||
|
||
9.4 Problems with Other Coordinators
|
||
|
||
Complaints concerning annoying behavior on the part of any
|
||
coordinator are treated as in section 9.2 and should be filed
|
||
with the next level of coordinator. For example, if you feel
|
||
that your Regional Coordinator is guilty of annoying behavior
|
||
(as opposed to a failure to perform duties as a coordinator) you
|
||
should file your complaint with the Zone Coordinator.
|
||
|
||
Complaints concerning the performance of a coordinator in
|
||
carrying out the duties mandated by policy are accepted only
|
||
from the level immediately below. For example, complaints
|
||
concerning the performance of Regional Coordinators would be
|
||
accepted from Network Coordinators and independents in that
|
||
region. Such complaints should be addressed to the Zone
|
||
Coordinator after an appropriate attempt to work them out by
|
||
direct communications.
|
||
|
||
9.5 Appeal Process
|
||
|
||
A decision made by a coordinator may be appealed to the next
|
||
level. Appeals must be made within two weeks of the decision
|
||
which is being appealed. All appeals must follow the chain of
|
||
command; if levels are skipped the appeal will be dismissed out
|
||
of hand.
|
||
|
||
An appeal will not result in a full investigation, but will be
|
||
based upon the documentation supplied by the parties at the
|
||
lower level. For example, an appeal of a Network Coordinator's
|
||
decision will be decided by the Regional Coordinator based upon
|
||
information provided by the coordinator and the sysop involved;
|
||
the Regional Coordinator is not expected to make an independent
|
||
attempt to gather information.
|
||
|
||
The appeal structure is as follows:
|
||
|
||
Network Coordinator decisions may be appealed to the appropriate
|
||
Regional Coordinator.
|
||
|
||
Regional Coordinator decisions may be appealed to the
|
||
FidoNews 10-14 Page: 43 05 Apr 1993
|
||
|
||
appropriate Zone Coordinator. At this point, the Zone
|
||
Coordinator will make a decision and communicate it to all
|
||
affected parties.
|
||
|
||
Zone Coordinator decisions may be appealed to the International
|
||
Coordinator. The International Coordinator will make a decision
|
||
and communicate it to all affected parties. Decisions of the
|
||
International Coordinator may be reversed by a majority of the
|
||
Zone Coordinators.
|
||
|
||
If your problem is with a Zone Coordinator per se, that is, a
|
||
Zone Coordinator has committed a Policy violation against you,
|
||
your complaint should be filed with the International
|
||
Coordinator, who will make a decision and submit it to the Zone
|
||
Coordinator Council for possible reversal, as described above.
|
||
|
||
A sample process is described in Appendix 3.
|
||
|
||
9.6 Statute of Limitations
|
||
|
||
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.
|
||
|
||
9.7 Right to a Speedy Decision
|
||
|
||
A coordinator is required to render a final decision and notify
|
||
the parties involved within 30 days of the receipt of the
|
||
complaint or appeal.
|
||
|
||
9.8 Return to Original Network
|
||
|
||
Once a policy dispute is resolved, any nodes reinstated on
|
||
appeal are re- turned to the local network or region to which
|
||
they geographically or technically belong.
|
||
|
||
9.9 Echomail
|
||
|
||
Echomail is one of many uses of Fidonet. Echomail is treated as
|
||
a use of Fidonet structure and is covered by Policy only to the
|
||
extent that this use affects primary Fidonet operations. By its
|
||
nature, echomail places unique technical and social demands on
|
||
the net over and above those covered by this Policy. It should
|
||
be noted that echomail distribution is a separate voluntary
|
||
arrangement between consenting nodes and is distinctly different
|
||
from the routing of netmail. 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.
|
||
|
||
9.10 Case Histories
|
||
FidoNews 10-14 Page: 44 05 Apr 1993
|
||
|
||
|
||
Some of FidoNet Policy is interpretive in nature. No one can
|
||
see what is to come in our rapidly changing environment. While
|
||
the history of previous complaints and decisions may be useful
|
||
as guidance, each case must be decided on its own merits in the
|
||
time and circumstances under which it occurs.
|
||
|
||
10. Credits, acknowledgments, etc.
|
||
|
||
Fido and FidoNet are registered trademarks of Fido Software, Inc.
|
||
|
||
Appendix --------
|
||
|
||
The Appendices of this document are exceptions to the normal
|
||
ratification process and are included for information purposes.
|
||
Appendix 1 may be changed by the appropriate Zone Coordinator,
|
||
and other sections may be added or changed as needed by the
|
||
International Coordinator.
|
||
|
||
Appendix 1: Timing of Zone Mail Hour
|
||
|
||
Zone Mail Hour is observed each day, including weekends and
|
||
holidays. The time is based upon Universal Coordinated Time
|
||
(UTC), also known as Greenwich Mean time (GMT). In areas which
|
||
observe Daylight Savings Time during part of the year, the local
|
||
time of zone mail hour will change because FidoNet does not
|
||
observe Daylight Savings Time. The exact timing of Zone Mail
|
||
Hour is set for each zone by the Zone Coordinator.
|
||
|
||
In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000
|
||
UTC. In each of the time zones, this is:
|
||
|
||
Eastern Standard Time (GMT -5) 4:00 AM to 5:00 AM
|
||
Central Standard Time (GMT -6) 3:00 AM to 4:00 AM
|
||
Mountain Standard Time (GMT -7) 2:00 AM to 3:00 AM
|
||
Pacific Standard Time (GMT -8) 1:00 AM to 2:00 AM
|
||
Hawaii Standard Time (GMT -10) 11:00 PM to Midnight
|
||
|
||
In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330
|
||
UTC.
|
||
|
||
In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900
|
||
UTC. In each of the time Zones involved this is:
|
||
|
||
GMT +12 Zone 6:00 AM to 7:00 AM
|
||
(New Zealand)
|
||
GMT +10 Zone 4:00 AM to 5:00 AM
|
||
(East Australia, Papua New Guinea, Micronesia)
|
||
GMT +9.5 Zone 3:30 AM to 4:30 AM
|
||
(Central Australia)
|
||
GMT +8 Zone 2:00 AM to 3:00 AM
|
||
(Western Australia)
|
||
|
||
In Fidonet Zone 4, Zone Mail Hour is observed from 0800 to 0900 UTC.
|
||
|
||
FidoNews 10-14 Page: 45 05 Apr 1993
|
||
|
||
GMT -3 Zone 5:00 AM to 6:00 AM
|
||
GMT -4 Zone 4:00 AM to 5:00 AM
|
||
GMT -5 Zone 3:00 AM to 4:00 AM
|
||
|
||
In Fidonet Zone 5, Zone Mail Hour is observed from 0100 to 0200 UTC.
|
||
|
||
GMT +0 Zone 1:00 AM to 2:00 AM
|
||
GMT +1 Zone 2:00 AM to 3:00 AM
|
||
GMT +2 Zone 3:00 AM to 4:00 AM
|
||
GMT +3 Zone 4:00 AM to 5:00 AM
|
||
|
||
In Fidonet Zone 6, Zone Mail Hour is observed from 2000 to 2100 UTC. In
|
||
each of the time zones involved this is:
|
||
|
||
GMT +9 Zone 5:00 AM to 6:00 AM
|
||
(Japan, Korea, Eastern Indonesia)
|
||
GMT +8 Zone 4:00 AM to 5:00 AM
|
||
(Hong Kong, Taiwan, Central Indonesia, Philippines)
|
||
GMT +7 Zone 3:00 AM to 4:00 AM
|
||
(Malaysia, Singapore, Thailand, Western Indonesia)
|
||
|
||
Appendix 2: Sample Election Procedure
|
||
|
||
1. Qualifications and Terms
|
||
|
||
The Coordinator serves a term of one year and may serve any
|
||
number of consecutive terms. Any sysop listed in the
|
||
appropriate segment of the Fidonet Nodelist at the time
|
||
nominations are opened is eligible to run. A simple majority
|
||
(50% + 1) of votes cast is required to elect a Coordinator. In
|
||
the event that no candidate received a majority of votes, a run
|
||
off election will be held between the two candidates with the
|
||
greatest number of votes.
|
||
|
||
2. Nominations
|
||
|
||
Nominations may be made either in a designated echo or by
|
||
netmail to the election coordinator. Any netmail nominations
|
||
received by the election coordinator will be cross-posted into
|
||
the designated echo. Any sysop listed in the appropriate
|
||
segment of the Fidonet nodelist may nominate any other eligible
|
||
sysop for the position of Coordinator.
|
||
|
||
Nominees must announce their consent to serve in order to be
|
||
considered candidates in the election, and are encouraged to be
|
||
available for discussion during the election process.
|
||
|
||
A minimum of two weeks will be allotted for the nominating
|
||
process.
|
||
|
||
3. Election Coordinator
|
||
|
||
At the start of the election process, the appropriate
|
||
Coordinator will appoint a non-candidate sysop as Election
|
||
Coordinator. This sysop will have several responsibilities:
|
||
FidoNews 10-14 Page: 46 05 Apr 1993
|
||
|
||
|
||
Collecting nominations, seconds and statements of consent to
|
||
serve from netmail and the designated echo and finalizing the
|
||
election slate.
|
||
|
||
Posting the slate of candidates and the voting format
|
||
instructions in the designated echo at the close of nominations.
|
||
|
||
Submitting the slate of candidates and the voting format
|
||
instructions to the Coordinator for distribution via netmail to
|
||
all Net and/or Regional Coordinators.
|
||
|
||
Collecting and tabulating votes submitted.
|
||
|
||
Notifying the Coordinator of the election results and posting
|
||
the election results in the designated echo.
|
||
|
||
4. Discussion Period
|
||
|
||
Following the close of nominations and presentation of the slate
|
||
of candidates, a minimum of two weeks will be allotted for
|
||
discussion before voting begins.
|
||
|
||
5. Voting Procedures
|
||
|
||
Net Coordinators in each net will distribute the slate of
|
||
candidates, voting instructions and voting schedule to all
|
||
members of their nets via netmail.
|
||
|
||
Votes must be cast by the node sysops via netmail to the
|
||
Election Coordinator. Due to changing technology, the exact
|
||
format and mechanism of placing these votes will be determined
|
||
by the Election Coordinator at the time of each election. Once
|
||
a vote has been received and validated, it may not be changed.
|
||
|
||
The Election Coordinator will announce the final counts within
|
||
seven days of the close of voting.
|
||
|
||
Challenges to the accuracy or completeness of the announced
|
||
results must be placed via netmail to the Election Coordinator
|
||
within seven days of the announcement of the results. A
|
||
successful challenge will necessitate a new election to be
|
||
initiated.
|
||
|
||
6. Installation of New Coordinator
|
||
|
||
The newly elected Coordinator will be installed in the nodelist
|
||
as soon as the transfer of control files and other necessary
|
||
information can be coordinated between the incoming and outgoing
|
||
Coordinators, but not later than two weeks from the announcement
|
||
of final election results.
|
||
|
||
Appendix 3: Sample Process for Resolution and Appeal of
|
||
Complaints
|
||
|
||
FidoNews 10-14 Page: 47 05 Apr 1993
|
||
|
||
The process of complaint and appeal available to all Fidonet
|
||
members, as delineated in sections 9.1 through 9.8, follows a
|
||
step by step procedure from the point at which a complaint has
|
||
been filed.
|
||
|
||
1. Offender does something to warrant removal from Fidonet.
|
||
|
||
2. The Net Coordinator points out this activity to the offender
|
||
and offers the opportunity to refrain.
|
||
|
||
3. The Net Coordinator records the response of the offender.
|
||
|
||
4. If the offender desists, the case is over. Otherwise;
|
||
|
||
5. The Net Coordinator issues a final warning to the offender
|
||
stating that the nodelist entry will be removed permanently
|
||
unless immediate cessation of the offense(s) follows this final
|
||
warning. Repeating at a later date an offense for which a
|
||
warning was previously given may be considered refusal to comply.
|
||
|
||
6. If the offender desists, the case is over. Otherwise;
|
||
|
||
7. The Net Coordinator notifies the offender of removal from the
|
||
nodelist.
|
||
|
||
8. Net Coordinator records offender's final response (if any)
|
||
and removes offender's node number from the nodelist if no new
|
||
information is received.
|
||
|
||
9. Net Coordinator advises Regional Coordinator of complete
|
||
chronology with documentation and the case is closed, or;
|
||
|
||
10. The offender appeals to the Regional Coordinator and offers
|
||
other information contrary to the Net Coordinator's account and
|
||
requests intervention and/or investigation.
|
||
|
||
11. If the Regional Coordinator refuses the appeal, the case is
|
||
over. Otherwise;
|
||
|
||
12. The Regional Coordinator agrees to consider the appeal and
|
||
advises the Net Coordinator to refrain from removal pending
|
||
investigation of the appeal.
|
||
|
||
13. The Regional Coordinator finds appeal has no merit, advises
|
||
Net Coordinator to proceed with node removal, and advises
|
||
offender of finding and of the option to appeal to the Zone
|
||
Coordinator, or;
|
||
|
||
14. The Regional Coordinator finds appeal has merit and advises
|
||
Net Coordinator to retain the node's number and to appeal to the
|
||
Zone Coordinator if unsatisfied.
|
||
|
||
15. Steps 10 through 14 may be repeated at the Zone Coordinator
|
||
and International Coordinator levels if necessary.
|
||
|
||
FidoNews 10-14 Page: 48 05 Apr 1993
|
||
|
||
Appendix 4: Fidonet Technical Standards
|
||
|
||
The Fidonet Technical Standards Committee (FTSC) is a
|
||
deliberative body charged with developing and maintaining
|
||
technical standards for operations in a Fidonet Technology
|
||
Network (FTN). All software used in Fidonet communications must
|
||
be in compliance with the appropriate standards, which include:
|
||
|
||
FTS-0001 A basic Fidonet technical standard, R Bush
|
||
FTS-0002 (superseded by FTS-0005)
|
||
FTS-0003 (superseded by FTS-0006)
|
||
FTS-0004 Echomail specifications, B Hartman
|
||
FTS-0005 The distribution nodelist, B Baker, R Moore
|
||
FTS-0006 YOOHOO and YOOHOO/2U2, V Periello
|
||
FTS-0007 SEAlink protocol extension, P Becker
|
||
FTS-0008 Bark file-request protocol extension, P Becker
|
||
FTS-0009 Message identification and reply linkage, j nutt
|
||
|
||
Appendix 5: File Name Conventions
|
||
|
||
For those systems accepting file requests via Fidonet, it is
|
||
generally accepted practice that certain types of information
|
||
will be available under commonly known alias names. The
|
||
following are common file aliases:
|
||
|
||
FILES List of files available for file request
|
||
ABOUT Information about the individual system
|
||
NODELIST Current full Fidonet nodelist
|
||
NODEDIFF Current weekly Fidonet nodelist difference file
|
||
FIDONEWS Current weekly issue of Fidonews
|
||
POLICY Fidonet policy documents
|
||
|
||
----------------------------------------------------------------------
|
||
|
||
========================================================================
|
||
Fidonews Information
|
||
========================================================================
|
||
|
||
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------
|
||
|
||
Editors: Sylvia Maxwell, Donald Tees, Tim Pozar
|
||
Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello,
|
||
Tom Jennings
|
||
|
||
IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been
|
||
changed!!! Please make a note of this.
|
||
|
||
"FidoNews" BBS
|
||
FidoNet 1:1/23 <---- NEW ADDRESS!!!!
|
||
BBS +1-519-570-4176, 300/1200/2400/14200/V.32bis/HST(DS)
|
||
Internet addresses:
|
||
Don & Sylvia (submission address)
|
||
editor@exlibris.tdkcs.waterloo.on.ca
|
||
|
||
Sylvia -- max@exlibris.tdkcs.waterloo.on.ca
|
||
FidoNews 10-14 Page: 49 05 Apr 1993
|
||
|
||
Donald -- donald@exlibris.tdkcs.waterloo.on.ca
|
||
Tim -- pozar@kumr.lns.com
|
||
|
||
(Postal Service mailing address) (have extreme patience)
|
||
FidoNews
|
||
172 Duke St. E.
|
||
Kitchener, Ontario
|
||
Canada
|
||
N2H 1A7
|
||
|
||
Published weekly by and for the members of the FidoNet international
|
||
amateur electronic mail system. It is a compilation of individual
|
||
articles contributed by their authors or their authorized agents. The
|
||
contribution of articles to this compilation does not diminish the
|
||
rights of the authors. Opinions expressed in these articles are those
|
||
of the authors and not necessarily those of FidoNews.
|
||
|
||
Authors retain copyright on individual works; otherwise FidoNews is
|
||
copyright 1993 Sylvia Maxwell. All rights reserved. Duplication and/or
|
||
distribution permitted for noncommercial purposes only. For use in
|
||
other circumstances, please contact the original authors, or FidoNews
|
||
(we're easy).
|
||
|
||
|
||
OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic
|
||
form may be obtained from the FidoNews BBS via manual download or
|
||
Wazoo FileRequest, or from various sites in the FidoNet and Internet.
|
||
PRINTED COPIES may be obtained from Fido Software for $10.00US each
|
||
PostPaid First Class within North America, or $13.00US elsewhere,
|
||
mailed Air Mail. (US funds drawn upon a US bank only.)
|
||
|
||
BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21,
|
||
1:125/1212, (and probably others), via filerequest or download
|
||
(consult a recent nodelist for phone numbers).
|
||
|
||
A very nice index to the Tables of Contents to all FidoNews volumes
|
||
can be filerequested from 1:396/1 or 1:216/21. The name(s) to request
|
||
are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985...
|
||
through 8=1991.
|
||
|
||
INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in
|
||
directory ~ftp/pub/fidonet/fidonews. If you have questions regarding
|
||
FidoNet, please direct them to deitch@gisatl.fidonet.org, not the
|
||
FidoNews BBS. (Be kind and patient; David Deitch is generously
|
||
volunteering to handle FidoNet/Internet questions.)
|
||
|
||
SUBMISSIONS: You are encouraged to submit articles for publication in
|
||
FidoNews. Article submission requirements are contained in the file
|
||
ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable
|
||
from 1:1/23 as file "ARTSPEC.DOC". Please read it.
|
||
|
||
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
|
||
trademarks of Tom Jennings, Box 77731, San Francisco CA 94107, USA and
|
||
are used with permission.
|
||
|
||
FidoNews 10-14 Page: 50 05 Apr 1993
|
||
|
||
Asked what he thought of Western civilization,
|
||
M.K. Gandhi said, "I think it would be an excellent idea".
|
||
-- END
|
||
----------------------------------------------------------------------
|
||
|