Fidonet Policy Document
FidoNet Policy Document Version 4.07
June 9, 1989
5.5 Maintaining the Nodelist
As a Regional Coordinator, you have a dual role in maintaining the nodelist
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 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. (Nodes are
to marked DOWN for a maximum of two weeks, after which the line should be
removed from the nodelist.)
Second, you must receive the nodelists from the Network Coordinators within
your region. You will need to maintain a set of nodelists 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 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 connec-
tion with your Zone Coordinator and thus losing a week.
5.6 Geographic Exemptions
There are cases where local calling geography does not follow FidoNet re-
gions. In exceptional cases, exemptions to normal geographic guidelines are
agreed upon by the Regional Coordinators and Zone Coordinator involved. Such
an exemption is not a right, and is not permanent. When a network is formed
in the proper region that would provide local calling access to the exempted
node, it is no longer exempt. An exemption may be reviewed and revoked at
any time by any of the coordinators involved.
5.7 Overseeing Network Operations
You are responsible for appointing network coordinators for the nets in your
region. If the outgoing Network Coordinator suggests a successor, you are
not obligated to accept that individual, although you normally will. Simi-
larly, you are not obligated to accept the individual selected by the members
of the network in an election, although you normally will.
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.
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 reason-
ably 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 Saturday by the Zone
Coordinator, and FidoNews is published weekly on Monday by node 1/1. 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 Coordina-
tors in your region as soon as is practical after you receive them. The
method of distribution is left to your discretion. You are not required to
distribute them to any independent nodes in your region, though you may if
you wish. You are encouraged to make all these documents available for
downloading by the general public.
6 Zone Coordinator Procedures
6.1 General
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 coordinat-
ing the distribution of Network 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, which is done by appointing and supervising the Regional Coordi-
nators.
If a Zone Coordinator determines that a Regional Coordinator is not properly
performing the duties outlined in section 5, a replacement should be found.
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 reviewing and approving any geograph-
ic 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 interzonal
mail.
The Zone Coordinators are responsible for the selection of the International
Coordinator from among their ranks.
6.2 Selection
The Zone Coordinator is selected by an absolute majority vote of the Regional
Coordinators within the zone.
7 International Coordinator Procedures
7.1 General
The International Coordinator is the "first among equals" Zone
Coordinator.
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 communica-
tion with 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 Coordi-
nator may issue specific interpretations or extensions to this policy. The
Zone Coordinator Council may reverse such rulings by a majority vote.
7.2 Selection
The International Coordinator is selected (or removed) by an absolute majori-
ty vote of the Zone 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 Interna-
tional 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 effective date for a
new policy through announcement in the weekly nodelist difference file. 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 Coordi-
nator is entitled to one vote. (Hub coordinators do not 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.
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
Given that Policy is intertwined and self referencing, a relatively simple
change may require several alterations of the document. In order to simplify
the process, balloting is done on choices between whole documents, rather
than individual amendments. In the simplest case, this means voting yea or
nay to a new document. If a number of alternatives are to be considered,
they must be presented as whole documents, from which one is chosen.
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 affirma-
tive votes would be 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 consid-
ered ratified. "Abstain" is a valid vote in this case, effectively
being a
vote for not changing the current policy as it simply increases the number of
votes required to ratify the proposed change.
8.7 Impeachment of a Zone Coordinator
8.7.1 Initiation
In extreme cases, a Zone Coordinator may be impeached by referendum. Im-
peachment of a Zone Coordinator does not require a Policy violation. An
impeachment proceeding is invoked when a majority of the Regional Coordina-
tors 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 (even if the zone coordinator is also the Internation-
al Coordinator).
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 Zone Coordinator who is
being impeached. 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 net 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.
2) Thou shalt not be too easily annoyed.
In other words, there are no hard and fast rules of conduct, but reasonably
polite behavior is expected. Also, in any dispute both sides are examined,
and action could be taken against either or both parties. ("Judge not, lest
ye be judged!")
The coordinator structure has the responsibility for defining "excessively
annoying". Like a common definition of pornography ("I can't define
it, but
I know it when I see it."), a hard and fast definition of acceptable
FidoNet
behavior is not possible. The guidelines in this policy are deliberately
vague to provide the freedom that the coordinator structure requires to
respond to the needs of a growing and changing community.
The first step in any dispute between sysops is for the sysops to attempt to
communicate directly, at least by netmail, preferably by voice. Any com-
plaint 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 via netmail or voice conversation with the other sysop.
If this fails to resolve the problem, you should complain to your Network
Coordinator and the other sysop's Network Coordinator. If one or both of you
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 to a review of your situa-
tion. 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 coordi-
nator. For example, if you feel that your Regional Coordinator is guilty of
annoying behavior (as opposed to a failure to perform duties as a coordina-
tor) 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 appro-
priate 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 Region-
al Coordinator.
Regional Coordinator decisions may be appealed to the appropriate Zone
Coordinator. At this point, the Zone Coordinator will make a decision
and communicate it to the Regional Coordinators in that zone. This
decision may be reversed by a majority vote of the Regional Coordina-
tors.
Zone Coordinator decisions may be appealed to the International Coordi-
nator. The International Coordinator will make a decision and communi-
cate it to the Zone Coordinator Council, which may reverse it by majori-
ty vote.
If your problem is with a Zone Coordinator per se, that is, a Zone Coordina-
tor 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.
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 techni-
cally belong.
9.9 Echomail
Echomail is an important and powerful force in FidoNet. For the purposes of
Policy Disputes, echomail is simply a different flavor of netmail, and is
therefore covered by Policy. By its nature, echomail places unique technical
and social demands on the net over and above those covered by this version of
Policy. In recognition of this, an echomail policy which extends (and does
not contradict) general Policy, maintained by the Echomail Coordinators, and
ratified by a process similar to that of this document, is recognized by the
FidoNet Coordinators as a valid structure for dispute resolution on matters
pertaining to echomail. At some future date the echomail policy document may
be merged with this one.
9.10 Case Histories
Most of FidoNet Policy is interpretive in nature. No one can see what is to
come in our rapidly changing environment. Policy itself is only a part of
what is used as the ground rules for mediating disputes -- as or more impor-
tant are the precedents.
In order to accommodate this process, case histories may be added to or
removed from this document by the International Coordinator, with such a
revision subject to reversal by the Zone Coordinator Council. Should Policy
be amended in such a way to invalidate a precedent, Policy supersedes said
precedent. (A carefully prepared amendment would address this by removing
the precedent reference as a part of the amendment.)
Although a case may be removed, the text of a case history may not be modi-
fied by any mechanism. Case history is written close to the time of the
decision, by those involved with it. Amending the text of a case history is
the same as revising history, something quite inappropriate in an organiza-
tion dedicated to moving information.
10 Appendices
10.1 General
The Appendices of this document are exceptions to the normal ratification
process. Section 10.2 can be changed by the appropriate Zone Coordinator,
and section 10.3 may be modified by the International Coordinator (see
Section 9.10).
10.2 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 4 AM to 5 AM
Central Standard Time 3 AM to 4 AM
Mountain Standard Time 2 AM to 3 AM
Pacific Standard Time 1 AM to 2 AM
Hawaii Standard Time 11 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 +9 Zone 3:00 AM to 4:00 AM
(Japan)
(Korea)
(Eastern Indonesia)
GMT +8 Zone 2:00 AM to 3:00 AM
(Hong Kong)
(Taiwan)
(Central Indonesia)
(Philippines)
(Western Australia)
GMT +7 Zone 1:00 AM to 2:00 AM
(Malaysia)
(Singapore)
(Thailand)
(Western Indonesia)
10.3 Case Histories
Case histories of past disputes are instructive to show general procedures
and methods. Any decision may be included in this document by a majority
vote of either the Zone Coordinator Council or the Regional Coordinators.
Policy4 significantly changes the functions of the Zone and International
Coordinators. In the following cases which were decided using Policy3,
substitute "Zone Coordinator" for all occurrences of
"International Coordina-
tor(*)".
10.3.1 The Case of the Crooked Node
A sysop of a local node was using network mail to engage in unethical busi-
ness practices. The Network Coordinator became very annoyed at this, and
dropped the local from the nodelist.
The local appealed to the Regional Coordinator for assignment as an indepen-
dent node. The Regional Coordinator, after checking with the Network Coordi-
nator, decided that the Network Coordinator was right to be annoyed. Inde-
pendent status was denied.
The International Coordinator(*) did not intervene.
10.3.2 The Case of the Hacker Mailer
A sysop of a local node made use of file attaches for extra users to mail
himself the USER.BBS file from several local boards. The sysops of these
boards felt annoyed at this, and appealed to their Network Coordinator, who
agreed and dropped the offending node from the nodelist.
The Regional Coordinator was not consulted.
The International Coordinator(*) did not intervene.
10.3.3 The Case of the Bothered Barker
A local node became annoyed with the Network Coordinator for failing to
provide services. Repeated complaints to the Network Coordinator did not
satisfy him, so he appealed to the International Coordinator(*).
The International Coordinator(*) dismissed the complaint because the Regional
Coordinator had not been consulted.
The local node submitted the complaint to his Regional Coordinator, who
investigated the case and discovered that there was some justice to the
complaint. He advised and assisted the Network Coordinator in configuring
his system to provide an improved level of service to the local nodes.
The Regional Coordinator also decided that the local node was being too
easily annoyed, in that he was expecting services not normally required of a
Network Coordinator. The local node was informed as to the true duties of a
Network Coordinator, and was advised to lower his expectations.
10.3.4 The Case of the Busy Beaver
A local node which was operated by a retail establishment was engaged in
making "bombing runs" to mail advertisements over FidoNet. The
Network
Coordinator felt annoyed and handling the outgoing traffic for a commercial
operation, and asked the local node to leave the network.
The local node applied to the Regional Coordinator, and was granted status as
an independent node in the region.
10.3.5 The Mark of the Devil
A local sysop whose board was used in conjunction with voodoo rites, hacking,
phreaking, and obscene material applied to a Network Coordinator for a node
number. The Network Coordinator deemed that this board was exceptionally
annoying, and denied the request.
The Regional Coordinator was not consulted.
The International Coordinator(*), on seeing that the Regional Coordinator had
not been consulted, dismissed the case out of hand. No further appeals were
made.
10.3.6 The Case of the Sysop Twit
A patron of various local nodes had been roundly recognized by all sysops as
a twit. The user obtained his own system, became a sysop, and applied for a
node number. The Network Coordinator denied the request. No appeals were
made.
10.3.7 The Case of the Echomail Junkie
A local node became enamored with echomail and joined several conferences,
routing mail through his network. He then started an echomail conference of
his own and began relaying echomail between several systems, again routing it
all through the network.
His Network Coordinator observed that network performance was becoming
seriously impaired. The offending node was told to hold it down. A compro-
mise was reached whereby much of the echomail traffic was no longer routed
through the network, and routed echomail was limited to twenty messages per
night. No appeals were made.
10.3.8 The Case of the Bouncing Board
A local user decided to establish a node to promote a worthy charity. The
machine being used was also used for various other activities during the day,
and the sysop was often called away. His coworkers would often forget to
bring the board up at the end of the day while he was away, so the node was
often down for extended periods. The Network Coordinator, finding the node
unable to receive mail, would mark it down. The sysop would return, restart
the board, and ask to be reinstated.
The Network Coordinator eventually decided that the sysop was not able to
maintain a reliable system, and removed him from the nodelist completely.
Subsequent requests for a node number from the same sysop were turned down.
No appeals were made.
10.5 Credits, acknowledgments, etc.
Fido and FidoNet are registered trademarks of Fido Software, Inc.
Index
-1/-1, 2.3
Additional mail events in local network 2.1.8
Address in message to request node 2.2
Administrative Region 6.1
Advantages to network membership 2.2
Alteration of mail 2.1.5
Answering machine 2.3
Announcement of voting results 8.2
Annoying behavior 1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4, 2.1.6, 2.1.7, 2.1.8,
2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
Appeal chain 9.5
Appointment of coordinators 1.2.3, 1.2.4, 5.7, 6.1
Availability of NodeList 1.3.4
Balloting Period 8.4
Bombing run 4.2
BossNode 1.2.1.2
Boundaries 1.3.2
Business use of FidoNet 1.3.6
Calling areas 1.3.2, 5.6, 5.7
Case histories 9.10, 10.3
Chain of command 1.2.8
Changing node numbers 4.3, 5.2
Checks and balances 1.2.8
Commercial messages 1.3.6, 2.1.4, 4.2
Complaint (policy) 2.1.6.1, 9
Contributions to FidoNews 1.3.1
Current nodelist 2.1.11
Daylight Savings Time 2.1.14
Difference file 4.5, 5.8, 8.2
Disclosing private mail 2.1.6
Discussion period 8.2
Disputes 9
Distribution of ballots 8.2
Down 2.3, 4.4, 5.5
Downloading by users 3.6, 4.5, 5.8
EchoMail 4.2, 9.9
Effective date (policy change) 8.2
Election of coordinators 1.2.5, 6.2, 7.2
Eligibility to vote 8.3
Encryption 2.1.4, 4.2
Exceptions 5.6
Excessively annoying behavior 1.2.1.1, 1.3.5, 2.1.1, 2.1.2, 2.1.4, 2.1.6,
2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
Exclusivity of Zone Mail Hour 2.1.8
Excommunication 2.1.12, 4.3, 5.2, 9
Exemptions, node location 1.3.2, 5.6
Familiarity with policy 2.1.2, 2.2
FidoNews 1.3.1
availability 3.1, 4.5, 5.8
FTSC 2.1.8, 2.1.9, 2.4
Gateway 2.1.3
Geography 1.3.2, 5.6
Glue 4.5
Guarantee of mail delivery 1.3.6
Hats 3.4
Host-routed mail 4.2
How to obtain a node number 2.2
Hub 1.2.3.1, 4.4
Illegal behavior 2.1.1, 9.6
Illegal mail 4.2
Impeachment 8.7
In-transit mail 2.1.6.1
Independent node 4.2, 5.2
Inter-zonal questions 1.2.6
International Coordinator 1.4.1, 1.4.9, 7
Justification of private nodes 2.1.9
Language 1.0
Levels of FidoNet 1.2, 1.4
Local calling areas 1.3.2
Local policies 1.2, 3.3
Mail 1.2.3, 4.2
Mailer 2.2
Majority 8.6, 8.7.2
Member of area administrated 3.5
Modem 2.2
Modification of mail 2.1.5
National Mail Hour see Zone Mail Hour
Network
advantages 2.2
boundaries 1.3.2, 5.4
definition 1.2.3
forming 2.4, 5.3
hub 1.2.3.1, 4.4
numbers 2.2, 5.4
Network Coordinator 1.2.3
procedures 4
replacement 5.7, 9.3
Network Mail Hour see Zone Mail Hour
New sysops 2.1.2, 3.6
Node numbers 4.3, 5.2
obtaining 2.2
Nodelist 1.3.4, 2.2, 4.4, 5.5
availability 3.1, 4.5, 5.8
changes 4.4, 5.2
current 2.1.11
definition 1.3.4
format 10.3
official 1.3.4
Nodes
definition 1.2.1
down 2.3
Observing mail events 2.1.8, 2.1.10
Obtaining a node number 2.2
Offensive messages 2.1.5
Orders (commercial) 1.3.6
Partial nodelist 1.3.4
Pirated software 2.1.1
Point of origin 2.1.3
Points 1.2.1.2, 2.1.3
Policy 3.1, 3.3, 4.5, 5.8
changing 8
complaint 2.1.6.1, 9
familiarity with 2.1.2, 2.2
local 1.2, 3.3
Precedent 3.7, 9.10, 10.3
Private messsages 2.1.6
Private network 1.2.1.2
Private nodes 2.1.9
Problem resolution 9
Protocol 2.1.8
Public BBS 3.6
Ratification 7.1
Redundant nodes 2.1.9
Referendum 1.2.7, 8
Regional Coordinator 1.2.4
procedures 5
replacement 6.1, 9.4
Regions 1.2.4
Replacement of coordinators 1.2.8
Replacing services 3.4
Requirements to be in NodeList 1.3.4, 2.1.2, 2.2
Resignation of ZC 8.7.4
Resolution of disputes 9
Results Announcement 8.2
Review of decisions 3.7
Review of routed traffic 2.1.4
Routing 2.1.4 - 2.1.7, 4.2
Routing Hub 1.2.3.1, 4.4
Rules 9.1
Speedy decision 9.7
Standards (FTSC) 2.1.8, 2.4
Statute of limitations 9.6
Submissions to FidoNews 1.3.1
Sysop procedures 2
System operator (sysop) 1.2.1
Three-tiered networks 1.2.3.1
Time limit on decision 9.7
Timing of Zone Mail Hour 2.1.13, 2.1.14, 10.2
Top-down 1.4.9
Tradition 3.7
Trivial network 5.3
Unattended systems 2.3
Updates to nodelist 3.2
User 1.2.1.1
User access during ZMH 2.1.8
Vacation 2.3
Voice telephone number 2.2
Vote 8
eligibility 8.3, 8.7.2
ZMH see Zone Mail Hour
Zone Coordinator 1.2.5, 6
election 6.2
impeachment 8.7
procedures 6
removal 6.2
resignation during impeachment 8.7.4
Zone Coordinator Council 1.2.6, 7.1
Zone Mail Hour 1.3.3, 2.1.8
timing 2.1.13, 2.1.14, 10.2
Zones 1.2.5, 1.3.2
