Zone One Backbone Operating Procedures
========================================
Revision: 1.03 Effective Date: October 1, 1991
Table of Contents
===================
1.0 Purpose of this Document
2.0 Zone Echomail Coordinator
2.1 Zone Echolist Coordinator
2.2 Zone Hubs
3.0 Region Echomail Coordinators
3.1 Region Hubs
4.0 Backbone Conference Moderators
4.1 Duties of Moderators
4.2 Recognition of Moderators
5.0 Operating Procedures
5.1 Echomail Message Standards
5.2 Banned Messages
5.3 Censorship
5.4 Adding Conferences to the Backbone
5.5 Removing Conferences from the Backbone
5.6 Echomail Gateways
5.7 Routed Netmail
6.0 Changes to this Document
1.0 Purpose of this Document
=============================
The Zone One Backbone Echomail System consists of the Zone Echomail
Hubs (commonly referred to as "Stars"), Region Echomail Hubs and Net
Echomail Hubs who help to distribute the Zone One Backbone echomail
conferences. This system is hereafter referred to simply as the
Backbone.
An echomail conference is a message base or forum, distributed under
a specified echomail conference name, dealing with a defined area of
interest. Echomail conferences are hereafter referred to simply as
conferences.
Echomail Hubs are nodes who distribute echomail. The Echomail Hubs
are hereafter referred to simply as Hubs. Zone Hubs distribute
echomail at the zone level. Region Hubs distribute echomail at the
region level. Net Hubs distribute echomail at the net level.
This document sets forth the operating procedures used by the
Backbone at the zone level. It describes how the Zone Hubs, and
those Region Hubs who connect directly to them, operate. The
operation of the Backbone within a region or net is not covered by
this document.
If any item in this document is in conflict with any existing or
subsequent General Fidonet Policy, then General Fidonet Policy will
be in effect.
2.0 Zone Echomail Coordinator
==============================
The Zone Echomail Coordinator (ZEC) oversees the operation of the
Backbone at the zone level. The ZEC coordinates routing and
schedules to ensure reliable and efficient availability of Backbone
echomail while avoiding creation of duplicate messages. The current
ZEC can be identified from the 1/200 listing in the Nodelist.
2.1 Zone Echolist Coordinator
------------------------------
The ZEC is responsible for maintaining a list of Backbone conferences
(Echolist). To assist in this effort, the ZEC appoints the Zone
Echolist Coordinator. The current Zone Echolist Coordinator can be
identified from the 1/201 listing in the Nodelist.
The Zone Echolist Coordinator compiles and publishes the Echolist
monthly. It is distributed through the Software Distribution System
(SDS) in the ECHOLIST area.
The content and format of the Echolist are at the discretion of the
Zone Echolist Coordinator, except that it includes the conference's
name, the Moderator's name, a netmail address listed in a publicly
available nodelist of any network where the Moderator can be reached,
a general description of the conference topic, any eligibility
requirements for restricted conferences, and the network of origin
for conferences which originate outside of Fidonet.
The ZEC personally maintains a text file called FIDONET.NA. This is
a list of the Backbone conferences in such a format that it can be
used as a forward-list by programs such as AreaFix. The ZEC
distributes this list to the Zone Hubs whenever it changes.
2.2 Zone Hubs
--------------
The ZEC appoints Zone Hubs (Stars) to distribute Backbone echomail at
the zone level. The ZEC may also serve as a Zone Hub if [s]he so
desires.
The ZEC makes available a minimum of one connection from each of the
Zone Hubs to each region. A region may choose to not use all of the
connections available to it.
Each Zone Hub carries all of the Backbone conferences. Each also
distribute the FIDONET.NA file, as received from the ZEC, to the
Region Hubs they connect with.
The ZEC and Zone Hubs maintain an emergency backup plan should one of
the Zone Hubs experience problems.
Nothing in this provision requires that a ZEC or Zone Hub must import
any conference to the extent of adverse economic impact.
3.0 Region Echomail Coordinators
=================================
The Region Echomail Coordinator (REC) oversees the operation of the
Backbone at the region level. The REC coordinates routing and
schedules to ensure reliable and efficient availability of Backbone
echomail while avoiding creation of duplicate messages. The current
RECs can be identified from the 1/2xx (where "xx" = the region
number) listings in the Nodelist.
3.1 Region Hubs
----------------
The REC appoints Region Hubs to distribute Backbone echomail at the
region level. The REC may also serve as a Region Hub if [s]he so
desires.
The REC decides which Region Hub connects to each of the Zone Hubs.
If a REC feels that [s]he needs more than one connection to each of
the Zone Hubs, [s]he may request extra connections from the ZEC.
Region Hubs do not necessarily carry all of the Backbone conferences,
but all of the Backbone conferences are available through them. They
also distribute the FIDONET.NA file, as received from the Zone Hubs,
to those they connect with.
Nothing in this provision requires that a REC or Region Hub must
import any conference to the extent of adverse economic impact.
4.0 Backbone Conference Moderators
===================================
Backbone Conference Moderators (Moderators) preside over conferences.
The Backbone has no desire to interfere with the internal affairs of
a conference in so much as they do not disturb the operation of the
Backbone.
A Moderator need not be either a Sysop or a member of Fidonet. If
the Moderator is not a member of Fidonet, [s]he must list an address
in a publicly available Nodelist of any network, so that he can be
contacted if the need arises.
4.1 Duties of Moderators
-------------------------
Moderators are responsible for:
1) Seeing that messages in their conference correspond to
the conference's theme.
2) Updating their conference listing in Echolist at least
every six months.
If a Moderator believes that a node is violating a conference rule,
[s]he may authorize the feed to that node be severed. This
authorization is made in direct written form (netmail), to the Hub
feeding the offending node, with a copy to the offending node.
4.2 Recognition of Moderators
------------------------------
A Moderator is recognized as follows:
1) Upon formation of a conference, the person who forms the
conference is the Moderator.
2) Upon resignation or replacement of an existing Moderator,
the conference's rules define how the new Moderator is
selected.
3) Should a conference which originates inside of FidoNet be
without a moderator for over 30 days, the ZEC may cause a
Moderator to be selected.
Moderators are encouraged to appoint Co-Moderators to assist them in
their duties and to stand in for them in their absence.
5.0 Operating Procedures
=========================
5.1 Echomail Message Standards
-------------------------------
FTSC specifications FTS-0001 and FTS-0004 are followed. All Backbone
nodes use the pathline option.
5.2 Banned Messages
--------------------
The Backbone does not distribute any conference which routinely
contains messages which are encrypted, contain illegal information or
promote illegal activities. As used in this paragraph, "illegal
activities" includes activities which are a violation of civil law as
well as activities which would result in criminal prosecution.
The Backbone does not distribute any conference which routinely
contains counterfeit messages. A counterfeit message is any message
entered using another person's name, handle or node address with the
intent of deceiving others about the true author of the message.
5.3 Censorship
---------------
It is not allowed to delete a message from a conference, or alter its
contents, in the passing or distribution of Backbone echomail.
Exceptions to this provision are the deletion of messages, by any
node, which may lead to legal action against that node or which do
not meet the echomail message standards in Section 5.1.
5.4 Adding Conferences to the Backbone
---------------------------------------
The ZEC adds a conference to the Backbone when all of these
requirements are met:
1) The conference is listed in the Echolist.
2) The moderator sends a netmail request to the ZEC. [S]he
should include a copy of the Echolist confirmation
message if the conference does not appear in the
currently published Echolist.
3) Two RECs request that the Backbone carry the conference
to their regions.
5.5 Removing Conferences from the Backbone
-------------------------------------------
The ZEC may drop a conference from the Backbone when any of these
situations occur:
1) The conference is not listed in the Echolist.
2) The moderator sends a netmail request to the ZEC. The
ZEC always honors this request.
3) There are no longer two RECs requesting that the Backbone
carry the conference to their regions.
4) The Moderator fails to properly carry out his duties, as
described in Section 4.1.
5) The conference is without a Moderator for over 30 days.
6) The traffic level in the conference falls below 5
messages over a two month period).
5.6 Echomail Gateways
----------------------
Echomail Gateways are nodes whose systems are used to exchange mail
with other groups. The term Gateway, as used hereafter, includes all
forms of gating including, but not limited to, zone-gating,
inter-network gating, and domain-gating.
Gateways remove foreign distribution identifiers (including seen-bys)
which might adversely affect the distribution of the conference on
the Backbone.
Gateways also pass netmail into the other network, unless it is
technically impossible to do so.
5.7 Routed Netmail
-------------------
Backbone nodes accept routed netmail from any node who connects with
them for Backbone conferences. Any netmail message with a valid
Fidonet destination, regardless of its origin, is accepted. Routed
netmail may be routed along echomail paths or to a ZC, RC, or NC who
has agreed to handle such mail.
6.0 Changes to this Document
=============================
A change to this document may be proposed by any REC. Anyone else
desiring to propose a change should find a REC who is willing to
sponsor their proposal.
If a second REC concurs with a proposal, the proposed change is voted
on by all of the RECs. Notice of such a vote is posted both in the
REC conference and in FidoNews, at least 14 days prior to the start
of the voting period. The RECs are expected to assess the opinions
of the members of their regions, and to vote accordingly.
The voting period is 7 days. More than 50 percent of those voting
must vote for a change for it to be accepted.
- end -