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.
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 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 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 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 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
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
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.
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.
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.
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
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 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.
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.
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 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 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.
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
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 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
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 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 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 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.
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 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 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
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.
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:
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
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.
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