informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/bbs/FIDONET/rgsnet.pol

828 lines
37 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
R G S N E T
Renegade Support Network
Policy and Procedures Guide
Draft 1.1
July 22, 1994
==============================================================================
Chapter 1
OVERVIEW
==============================================================================
1.1 Objective
To connect Renegade Systems across the Nation and the World into a
FidoNet Compatible Network for the "Free Exchange of Information."
We (The Renegade Support Network) have no intentions of trying to replace
or compete with the existing FidoNet Network. We (The Renegade Support
Network) only want a means of communicating directly with other Renegade
SysOps across the nation and to enhance the transmission of messages
across the nation and to further develop Renegade.
This document is an attempt to describe the procedures which have
been developed to manage The Renegade Support Network (RGSNet).
1.2 Background
FidoNet is an amateur electronic mail system. From its early
beginnings as a few friends swapping messages back and forth, it has
now grown to (June 1994) over 25000 different systems on four
continents.
RGSNet is attempting to provide the resources to a Renegade System
Operator (SysOp) and the tools to connect into a Network of other
Bulletin Board (BBS) SysOps across the nation. We are also able to
provide partial international connectivity as well.
RGSNet will not try to reinvent the wheel. We will adopt most of
of the standards that International FidoNet Association has already
adopted into their network.
1.3 Definitions
RGSNet nodes are grouped on several levels. These are as follows:
Nodes: A node is a single Net address, and is the smallest
recognized unit of the Net.
Hubs: A hub is a collection of nodes, usually in a
relatively small geographic area. Hubs coordinate
their mail activity to decrease cost and increase mail
throughput.
Networks: A collection of hubs/nodes within a slightly larger
geographic area (an individual state for example).
Networks are treated just like large hubs.
Therefore, all that applies for Hubs ... also applies
for Networks.
Regions: A collection of a group of networks within a specified
geographical region, usually several states grouped together.
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.
Zones: (Not applicable)
A zone is a large geographic area containing many
regions, and covering one or more countries and/or
continents.
RGSNet: This indicates the entire mail network, as designed by
the Renegade Support Network Coordinators and as defined
by the weekly nodelist.
1.4 The Levels of RGSNet
With the introduction of The Renegade Support Network, RGSNet has
developed the following levels of organization:
The Zone Coordinator
The Zone Coordinator compiles all of the nodelists
for the entire Zone and creates the master nodelist,
which is then distributed across The Renegade Support Network.
Any disputes at the Regional level are handled by the Zone
Coordinator and/or his assignees.
The Regional Coordinator
The Regional Coordinator is responsible for maintaining the list
of Networks for his Region, and for receiving and forwarding any
mail coming to the region from the outside. He is also responsible
for the maintenance of the members of his region and will ensure
proper use of the network by those members. Any disputes at the
Network Level are handled by the Regional Coordinator and/or his
assignees.
The Network Coordinator
The Network Coordinator is responsible for maintaining the
list of nodes for his network, and for receiving and
forwarding any mail coming to the network from the outside.
He is also responsible for the maintenance of the members of
his network and will insure proper use of the network by those
members. Any disputes at the Network Routing Hub Level are handled
by the Network Coordinator and/or his assignees.
The Network Routing Hub
Network Routing Hubs exist only in three-tiered networks. They
generally share some or all of the duties of the Network
Coordinator, in order to ease the management of a large
network. The exact duties and procedures are a matter for the
Network Coordinator and his hubs to settle, and will not be
discussed here. The Network Coordinator is still responsible
for the maintenance of the network and insures proper use of
the network for the people in his Routing Hub. All disputes at the
node level, should be addressed by the Routing Hub, before being
forwarded to the Network Coordinator.
The System Operator (SysOp)
The SysOp formulates his own policy for running his board and
dealing with his users, so that will not be discussed in this
document. However, the sysop must also mesh with the rest of
the RGSNet Systems if he is to send and receive mail, and
that will be discussed here.
The User
Policy and procedures for the individual user on any given
board is determined by the system operator of that board, and
will not be considered in this document.
These levels act to distribute the administration and control of
RGSNet to the lowest possible level, while still allowing for
coordinated action over the entire mail system.
==============================================================================
Chapter 2
SYSOP PROCEDURES
==============================================================================
A SysOp of an individual node can pretty much do as he pleases, as
long as he observes the mail events, is not excessively annoying to
other nodes on RGSNet or any other FidoNet Compatible Network,
and does not promote the distribution of pirated copyrighted software.
National Mail Hour (also known as ZMH, or Zone Mail Hour) is the heart
of any Netmail Network, as this is when the network mail is passed
between systems. Any system which wishes to be a part of a NetMail
Network must be able to receive mail at this time. A system which is
a member of a network may also be required to observe additional mail
events, as defined by his Network Coordinator.
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.
The exact timing of National Mail Hour is set for the zone by the
Zone Coordinator. In the United States, National Mail Hour is observed
from 0900 to 1000 GMT (Greenwich Mean Time) every day, weekends included.
In each of the United States time zones, this would be as follows:
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 12 Midnight
Networks do not observe daylight savings time. In areas which observe
daylight savings time the RGSNet mail schedules must be adjusted
in the same direction as the clock change. Alternatively, you can
simply leave your system on standard time.
2.1 How to get 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 the
closest RGSNet Bulletin Board System to you.
If the SysOp of any RGSNet system does not have a nodelist available
for downloading, then he can probably tell you where to get one, BUT we
STRONGLY suggest all nodes carry and allow for download the most recent
RGSNLIST.Z?? and related RGSNet files.
Once you have a nodelist, you must determine which network or region
covers your area. If you are unsure of this or there is not one in
your area, send the information to the Zone Coordinator @ 50:50/0.
Once you have located the network or region in your area, send a
request for a node number to node zero of that network or region. The
request must be sent by a NetMail message and must include at least the
following:
1) Your name.
2) The name of your system.
3) The city and state where your system is located.
4) The phone number to be used when calling your system.
5) Your hours of operation.
6) The maximum baud rate you can support.
7) BBS Software Version.
8) NetMail Interface Program.
9) A list of EchoMail Conferences that you wish to pick up.
10) Voice number (Internal use only!).
Your coordinator may want additional information. If so, he/she will
contact you.
Please allow at least five working days for a node number request to be
processed. If you send your request to the Zone Coordinator, then
he may forward your request to the Network Coordinator who covers your
area (if any), which may take longer.
2.2 If you are going down
If your node will be down for an extended period (more than a day or
two), then you should inform your coordinator as soon as possible. If
you do not do this, then other systems will still try to reach you
while you are down, much to the annoyance of everyone. Do not under
any circumstances put an answering machine or similar device on your
phone line while you are down. If you do, then calling systems will
get the machine repeatedly, racking up large phone bills, which is
VERY annoying.
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 _do_ 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.3 How to join a network
If you are an independent node and would like to join a network in
your area, you must contact the Network Coordinator. He can be
reached by sending Netmail to node zero of the network. He will
inform you of any special mail schedules and/or routing required by
the network. Once you have been placed in the network, you will be
informed by the Network Coordinator.
There are many advantages to being in a network. First and foremost
is that it helps reduce congestion of RGSNet during National Mail
Hour. Also, many networks are "outbound" as well as "inbound", which
can substantially reduce your phone bills. In addition, network
members receive regular updates of the nodelist, while an independent
node may not.
2.4 How to form a network
If there are several nodes in your area, but no network, then you may
wish to form your own. Again, this has several advantages as outlined
above.
Your 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
is going to be the Network Coordinator. Your next step is to inform
Network Administration. You must send him a NetMail message with 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) The name that you wish to call your network. Please try to
select a name that relates to your grouping. For example,
SoCalNet for nodes in the Southern California Area
and MassNet for Massachusetts Area. Remember if you
call yourself DOGNET it doesn't help others know what area
of the country (or even what country) your group is in.
3) A copy of the proposed network's nodelist. The nodelist
file should be named RGSNET.nnn where "nnn" is the
proposed host's current region or network number.
This file should be sent attached to the message of
Application for a Network Number.
SAMPLE FORMAT OF A RGSNET.100 FILE
Host,100,California_NET,North_Palm_Springs_CA,Scott_Freeman,1-619-251-0609,9600,
CM,XA,V32b,V42b
,1,Alternate_Reality,North_Palm_Springs_CA,Scott_Freeman,1-619-251-1675,9600,CM,
XA,V32b,V42b
,2,Olympus_BBS,Cathedral_City_CA,Mike_Partelow,1-619-324-2526,9600,CM,XA,V32b,V4
2b
,3,Desert_Night,Oceanside_CA,Rodney_Dunn,1-619-430-7734,9600,CM,XA,V32b,V42b,MNP
;
Granting of a network number is not automatic. Network Administration
will review your application and inform you of the decision.
==============================================================================
Chapter 3
NETWORK COORDINATOR PROCEDURES
==============================================================================
A Network Coordinator has the following responsibilities:
1) To receive incoming mail for nodes in his network, and to
deliver it to its recipients. This mean you have to poll
the Regional Coordinator or Mail Distribution System to
receive your mail.
2) To assign node numbers to nodes in his network.
3) To maintain the nodelist for his network, and to send a
copy of it to the Regional Coordinator whenever it changes.
4) To pass along to his nodes the new nodelist, nodelist
updates and new issues of RGSN????.ZIP as they are received.
3.1 Routing inbound mail
It is your responsibility as Network Coordinator to receive all
inbound mail for nodes in your network and to forward it to its
recipients. You are left to your own discretion as to how best to
accomplish this.
If a node in your network is routing large volumes of EchoMail, you
can ask him to either limit the amount of EchoMail, or even to stop
routing his EchoMail completely. The design of EchoMail is such that
it is a simple matter to do either of these. Or they can break off out
of your network.
3.2 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.
3.3 Maintaining the nodelist
You should attempt to implement name changes, phone number changes,
etcetera in your nodelist as soon as possible, and to forward the
revised Nodelist to your Regional Coordinator whenever a change occurs.
You should also on occasion send a message to every node in your
network to ensure that they are still operational. If a node turns
out to be "off the air" with no prior warning given to you, then you
can either mark the node as down, make it temporarily inactive, or
remove it from the nodelist completely, at your own discretion.
3.4 Passing along nodelists and RGSNet Info Packets
As a Network Coordinator you should obtain a new nodelist update every
week. The nodelist update is posted weekly on Saturdays. The list will
be made available to you by Network Administration.
You should pass both of these along to your member nodes as soon as is
practical after you receive them. It is also desirable that you make
them both available for downloading by the general user, but this is
not required.
The nodelists are the glue that holds us together. Without them, we
cease to be a community, and become just another random collection of
bulletin boards.
==============================================================================
Chapter 4
REGIONAL COORDINATOR PROCEDURES
==============================================================================
Regional Coordinators have 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.
4) To compile a nodelist of all of the networks and
independents in the region, and to send a copy of it to
the Mail Distribution Node whenever it changes.
5) To ensure the smooth operation of the networks within the
region.
4.1 Assigning Node numbers
The responsibility to assign node numbers to new network in the region.
You may also change the numbers of existing networks in the region,
though you should check with the respective nodes before doing so.
The numbers assigned to networks must be within the RGSNet Network
Plan in order for future growth of the region to be possible.
You should use network mail (netmail) to inform a new node of their
node number, as this helps to insure that he is capable of receiving
network mail.
If you receive a node number request from a new node that is in an
area covered by an existing network, then you should forward the
request to the Coordinator of that network instead of assigning a
number yourself.
4.2 Encouraging the formation and growth of networks
One of your main duties as the Regional Coordinator is to promote
the growth of networks in the region.
You should try to avoid having independent nodes in the 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 commercial system with a large volume of traffic which would clog
the network. The resolution of such special cases is left to your own
discretion.
If several independent nodes in your region are in a "clump", then you
should encourage them to form a network. Refer to the SysOp procedure
forming a network on forming a network for details of what information
you should get.
Note that this does not mean to encourage the formation of trivial
networks. Obviously, one node does not make a network. The exact
number of nodes required for an effective network must be judged
according to the circumstances of the situation, and should be
according to the plan of the region.
4.3 Assigning network numbers
It is your responsibility to assign network numbers to new networks
forming within your region. The network numbers are assigned by
referring to the RGSNet Network Plan.
4.4 Maintaining the nodelist
The Regional Coordinator has a dual role in maintaining the nodelist for
the 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 still operational. If a node turns out to be
"off the air" with no prior warning given to you, then you can either
mark the node as down, make it temporarily inactive, or remove it from
the nodelist completely, at your own discretion.
Second, you must receive the nodelists from the Network Coordinators
within your region. You should assemble a master nodelist for your
region every week and send it to the Zone Coordinator no later than
National Mail Hour on Friday morning. It is suggested that
you do this as late as is practical, so as to accommodate any late
changes.
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.
4.5 Overseeing network operations
It is the responsibility of Regional Coordinator to ensure that the
networks within the 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 seeing to it that the Network Coordinators
within your region are acting responsibly.
It is the obligation of Regional Coordinator to maintain direct and
reasonably frequent contact with the networks in the region. The
exact method of accomplishing this is left to your discretion.
4.6 Passing along nodelists and RGSNet Info Packets
Regional Coordinators are responsible for obtaining the latest RGSNet
nodelist updates and any RGSNet Info Packets as they are published,
and to make them available to the Network Coordinators within your
region. The Nodelist is posted weekly on Saturday's by RGSNet HQ @
Node #50:50/0.
It is your responsibility to distribute these to any Network
Coordinators 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. It is also desirable that you
make them both available for downloading by the general user, but this
is not required.
==============================================================================
Chapter 5
ECHOMAIL CONFERENCES
==============================================================================
EchoMail Conferences are messages that are passed around the
nation and the world. These conferences can range from
very technical topics to very casual ones. Some may even
have offensive language in them. So, it is very important
that you only choose the ones that would be of interest to
you and/or your users. You can always add and/or delete the
conferences that you choose.
For a current list of the available EchoMail Conferences, ask
your Network Coordinator for the current list. It will also be
available for download and/or file requestable from
Mail Distribution @ 50:50/0 as "RGSNET.NA".
If you are receiving EchoMail Conferences from RGSNet, it is
mandatory that you NOT forward RGSNet or any another Network
EchoMail Conferences to NON-RGSNet Systems. Also, do not
accept feeds of the same EchoMail Conference from more than
one source. If you do, it will create duplicate messages in
EVERYONES Network. Violation of this will not be tolerated!
The following are REQUIRED RGSNet EchoMail Conferences:
RGS_ADMI This is a PRIVATE Conference which is only
available to nodes of RGSNet. This conference
will be used for the development of The Renegade
Support Network. This should be listed in your
configurations as "sysop-only"! This Echo
Mail Conference is ONLY for RGSNet Development
Information and should not be used for anything
else.
Moderator: Scott Freeman @ 50:50/0
RGS_HUBS This is a PRIVATE Conference which is only
available to the RGSNet Hub Managers.
This conference will be used for Hub Manager Information
between them and RGSNet Network Administration.
This should be listed in your configurations as
"sysop-only"!
Moderator: Scott Freeman @ 50:50/0
RGS_HOST This is a PRIVATE Conference which is only
available to the RGSNet Network Managers.
This conference will be used for Net Manager Information
between them and RGSNet Network Administration.
This should be listed in your configurations as
"sysop-only"!
Moderator: Scott Freeman @ 50:50/0
RGS_REGION This is a PRIVATE Conference which is only
available to the RGSNet Regional Managers.
This conference will be used for Regional Manager
Information between them and RGSNet Network
Administration. This should be listed in your
configurations as "sysop-only"!
Moderator: Scott Freeman @ 50:50/0
The following are OPTIONAL RGSNet EchoMail Conferences:
RGS_ADS This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used for
all types of ads. It can be made available to
the callers of your system on an RGSNet Node.
Moderator: [OPEN]
RGS_BUGS This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
found and newly reported bugs in the Renegade BBS
system. It can be made available to the callers of
your system on an RGSNet Node.
Moderator: [OPEN]
RGS_CHAT This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
anything not related to Renegade. It was created for
the PUBLIC, but all are welcome to use it. It can be
made available to the callers of your system on an
RGSNet Node.
Moderator: [OPEN]
RGS_COMM This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
anything related to modem communications.
It was created for the PUBLIC, and all are welcome to
use it. It can be made available to the callers of
your system on an RGSNet Node.
Moderator: [OPEN]
RGS_DOORS This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
doors and their operation with the Renegade BBS
system. It can be made available to the callers of
your system on an RGSNet Node.
Moderator: B.W. Behling @ 50:190/11
RGS_FILE This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used by the RGSNet
File Echo Coordinator to announce newly hatched files
in the RGSFBONE (RGSNet Filebone), for others to
announce newly received files available for freqs
(Non-RGSFBONE), and will also serve as an area for
FILEFIND requests." It can be made available to
the callers of your system on an RGSNet Node.
Moderator: [OPEN]
RGS_MAILER This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
Front-End Mailers and their operation with the Renegade
Bulletin Board System. It can be made available to
the callers on your system on an RGSNet Node.
Moderator: [OPEN]
RGS_OPSYS This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
the different types of operating systems that run
Renegade. It can be made available to the callers of
your system on an RGSNet Node.
Moderator: [OPEN]
RGS_PROG This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
programming and programming issues that deal with the
Renegade Bulletin Board System. It can be made
available to the callers of your system on an
RGSNet Node.
Moderator: [OPEN]
RGS_QUES This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
commonly asked questions about Renegade BBS. It can
be made available to the callers of your system
on an RGSNet Node.
Moderator: [OPEN]
RGS_RELE This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
newly released software for the Renegade Bulletin
Board System. This conference was conceived to give
a place for authors of 3rd Party Software to discuss
the various nuances of their programs. It can be made
available to the callers of your system on
an RGSNet Node.
Moderator: [OPEN]
RGS_RENEGADE This is a PUBLIC Conference which is available
to all RGSNet Members. It is gated to other networks.
It will be used to discuss the Renegade Bulletin Board
System. It can be made available to the callers of
your system on an RGSNet Node.
Moderator: Cott Lang @ 1:133/501.fidonet.org
RGS_RIPG This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
RIP (Remote Imaging Protocol) and various other
utilities associated with RIP and how they interact with
the Renegade Bulletin Board System. It can be made
available to the callers of your system on
an RGSNet Node.
Moderator: Tom Gehrke @ 50:120/0 /1
RGS_SUPP This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
general Renegade Support not found in the RGS_QUES
forum. It will also be used for announcing new members
in the Renegade Support List authored by Joe Farrell
and sanctioned by the Renegade Support Network.
It can be made available to the callers of
your system on an RGSNet Node.
Moderator: [OPEN]
RGS_SUGG This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
any and all suggestions for improving the Renegade
Bulletin Board System. It can be made available to
the callers of your system on an RGSNet Node.
Moderator: [OPEN]
RGS_TICS This is a PUBLIC Conference which is available
to all RGSNet Members. It will be used to discuss
file echo processors and their use with the Renegade
Bulletin Board System. It can be made available to
the callers of your system on an RGSNet Node.
Moderator: [OPEN]
==============================================================================
Chapter 6
Renegade Support Network CONTACTS
==============================================================================
Scott Freeman Rodney Dunn
Network Administration Internet Gateway
N. Palm Springs, California Oceanside, California
(D) 619-251-0609 (D) 619-430-7734
RGSNet Node #50:50/0 RGSNet Node #50:51/0
FidoNet Node #1:219/801 FidoNet Node #1:202/402
Bryan Rapp
File Echo Coordinator
Phoenix, Arizona
(D) 602-870-3929
RGSNet Node #50:220/0
FidoNet Node #1:114/244
==============================================================================
Chapter 7
ACKNOWLEDGMENTS
==============================================================================
IFNA The International FidoNet Association for creating
standards for Packet Mail to be transmitted across the
nation.
Renegade Renegade Bulletin Board Service Program written by
Cott Lang.
RGSNet The Renegade Support Network created by Joe Farrell.
Squish The Zone Aware EchoMail Packer and Router Program which
was written by Scott Dudley.
Allfix The File Echo Processor by Harald Harms.
ReneMail A program written by Cott Lang that allows a SysOp
to pull EchoMail Conferences into Renegade.
Rodney Dunn For all his help with Nodelists and Internet Gates.
Joe Farrell For creating the idea of a network where Renegade Sysops
could help each other.
Freeman Family I would like to thank them for allowing me the time to
work on my (expensive) hobby.