info/mirror-textfiles.com
1
0
Fork 0
mirror of https://github.com/opsxcq/mirror-textfiles.com.git synced 2025-08-30 13:49:47 +02:00
Code Issues Releases Wiki Activity
Files
gh-pages
mirror-textfiles.com/bbs/FIDONET/rnet_pol.003

941 lines
45 KiB
Plaintext
Raw Permalink Blame History

ÛÛÛÛÛÛÛÛÛÜ ÜÛÛÛÛÛÛÛÛÛÜ ÛÛÛÛ ÛÛÛÛ ÛÛÛ (R)
ÛÛÛÛ ßÛÛÛÛ ÛÛÛÛß ßÛÛÛÛ ÛÛÛÛÛÜ ÛÛÛÛ ÛÛÛ
ÛÛÛÛ ÜÛÛÛß ÛÛÛÛ ÛÛÛÛ ÛÛÛÛÛÛÜ ÛÛÛÛ ÜÛÛÛÛÛÛÛÜ ÛÛÛÛÛÛÛÛ
ÛÛÛÛÛÛÛÛÛÜ ÛÛÛÛÛÛÛÛÛÛÛ ÛÛÛÛÛÛÛÛÛÛÛÛ ÛÛÛß ßÛÛÛ ÛÛÛ
ÛÛÛÛ ßÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ßÛÛÛÛÛÛ ÛÛÛÛÛÛÛÛÛÛß ÛÛÛ
ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ßÛÛÛÛÛ ÛÛÛÜ ÜÜÜ ÛÛÛ ÜÜ
ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ÛÛÛÛ ßÛÛÛÛÛÛÛß ßÛÛÛÛß
O F F I C I A L P O L I C Y S T A T E M E N T
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Revision #3 Updated: January,1,1993
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This Revision subsedes all Previous Policy Revisions.
Compiled by Tim Settle 72:72/0
(C) Copyright 1992, 1993 Tim Settle/IZC
RANet(tm) Lubbock, TX All Rights Reserved.
INTRODUCTION AND HISTORICAL BACKGROUND:
This is the Policy and Structure of RANet, a new approach in
private electronic message distribution and a no-fee system
offered to approved affiliated nodes agreeing to abide by its
rules and regulations as contained in this document.
RANet's motto sums up its philosophy:
"RANet: Dedicated to the Great Masterpiece"
THE SPIRIT OF RANET:
The Spirit or Raison d'Etre of RANet is the exchange of
electronic messages and vibrant conferences (popularly known as
EchoMail) with reliability and dedication as if it were a
successful business rather than what it is, an amateur network.
The echoes on RANet are Original, Active, Plentiful - three
excellent reasons to join this well-administered Network.
Friendly hobbyists like yourself, everyone who has accepted
(or ever will accept) an "official" position at any level
within RANet is a person recognized for carrying out his/her
responsibilities with professional earnestness.
ECHOMAIL STANDARDS WITHIN RANet:
RANet Echomail Policy MUST be read by each SysOp and is
contained in this archive as RA_ECHO.POL. Our Echomail Policy
differs drastically from most other networks, and you should be
keenly aware of it.
Because each SysOp decides which echoes he/she will carry on
their BBS, EchoMail conference creations within RANet are
limited only by the lack of imagination or effort put forth by
those who want a particular conference to exist. This Network
thrives on and is dedicated to echoes; potential moderators
without experience will receive friendly and helpful guidelines
by contacting the Zone Echo Coordinator (72:72/2) or their
NEC. Experienced moderators from conferences outside RANet
should also contact their RANet NEC for guidelines before
submitting their proposed conference to the Backbone.
This Network is unique in that there are definite rules and
guidelines established for Moderators. Please file request
MODRULES.ZIP from your REC or the ZEC.
(not avaiable at this time)
GENERAL PROHIBITIONS FOR ECHOMAIL CONFERENCES ON RANet:
1. No conference that violates FCC regulations;
2. No conference that in any way advocates pirated software;
3. With rare exception, no conference may be moderated by a
non-RANet SysOp. A Moderator who is a Point off an
RANet Boss node is considered an RANet affiliated
member; the same criterion applies to a Moderator who is
a User of an RANet BBS.
4. No conference will be accepted on the Backbone until it
has been active on the local RANet BBS originating it
and on one other BBS. This will give the ZEC a clue that
the conference has already established a track record. The
proposed local conference also must have been active on
the following two systems: 72:72/0 & 72:72/2 .
5. In order to prevent dupes between national networks and to
provide a more unique atmosphere in RANet, no one is
permitted to pass RANet echoes to a non-RANet BBS.
Additionally, non-RANet echoes may not be imported into
RANet without the expressed, netmailed permission of the
International Zone Echomail Coordinator. 72:72/2
DEFINITIONS:
[Some of the following definitive descriptions are quoted
and/or adapted from ECHONET's Policy and are used with the
kind permission of Ed Lawyer, the current (1992) Zone
Coordinator of said Network. Additionally, this Policy
borrows freely (and in many instances, verbatim) from the
Network who parented us all: FidoNet. FidoNet Zone
Coordinator George Peace has granted us permission to quote
and/or adapt from FidoNet Policy4.]
POINTS - A point is a system which is not listed in the
nodelist, but is capable of FidoNet-Technology Electronic mail
generation and exchange. A Point is connected to the network
via one or more regular RANet nodes. Communication to or from
a point system into the greater network is always conducted
thru one or more regular nodelisted systems. The system
operator of the *nodelisted system through which a point
communicates to the network at large is responsible for the
proper adherence to RANet policy for his respective point
systems.
* A SysOp whose node number has been published in RNETLIST.*
Points are often private bulletin board systems, or sometimes
users, who choose to accept and read message traffic 'off-line'
from the nodelisted system. In terms of RANet policy, Point
systems are treated as users of a nodelisted system.
NODES - A node is a system which is capable of FidoNet-Technology
Electronic Mail generation and exchange, and is listed in the
RANet nodelists. A node is identified by a unique address
within a given network, region or zone, which is assigned by the
appropriate network or regional coordinator specific to that node.
NETWORK - A network is a collection of nodes, usually within a
relatively local geographic area. In terms of RANet, network
areas will usually be distinct geographic groupings arranged in
such a way as to facilitate the exchange of electronic mail, and
coordination information.
In an effort to further identify geographic location based on
network affiliation, RANet adopts network numbers based on the
local telephone areacodes within the area. For example, areacode
301 is assigned as Net 301. (Hub systems may be established within
a network where Long Distance charges would be incurred with mail
transfers.) Added networks in a one area code state will be
numbered with different initial digits: e.g., 1301, 2301, 3301,
etc. In instances where _local_ calls can be placed between two or
more areacodes, a network can include nodes from more than one
areacode. In this case, the network is numbered with the areacode
of the founding Network Coordinator. Assignments are performed by
the International Zone Coordinator in conjunction with the Regional
Coordinator,Zone Nodelist Coordinator and Zone Echo Coordinator when
appropriate.
REGION - A region is a collection of both networks and independent
nodes. Independent nodes are those nodes which do not live within
reasonable proximity to existing nets or cannot be included in an
existing network for valid technical reasons which are accepted by
the Zone Echo Coordinator and Technical Coordinators.
RANet region boundaries are original and subject to change by
the Zone Nodelist Coordinator when necessary.
ZONES - A zone is a collection of regions. In terms of RANet,
the entire nodelist comprises TWO Zone, until such time as
the Zone Coordinator in conjunction with the Zone Echo Coordinator and
Technical Coordinators determines it expedient to expand into
multiple zones. RANet is known as 'Zone 72 '& 'Zone 73' (& up
for the future), which will allow proper zone-gating or domain-
gating systems of FidoNet-style mail-transfers to be utilized.
POSITIONS WITHIN RANet:
Note: Assuming you have read the "Introduction And Historical
Background" paragraphs above, you will understand why the
"Buck Stops Here" with the following three (3) hierarchical
RANet Administrative positions.
INTERNATIONAL ZONE COORDINATOR - The International Zone
Coordinator (ZC) is the highest administrative office within
RANet. He has ultimate authority over all RANet operations and,
since RANet is a private by-invitation-only electronic network,
he may approve or disapprove a new or an existing node without
recourse, electing to keep the reason(s) to himself. The ZC is
responsible for the overall operation and effectiveness of the
RANet Network. As such he retains a full voting position
on the Executive Board and participates in decisions affecting the
operation or direction of RANet. The Zone Coordinator(s) is also
the designated point-of-contact for all inter-net liaison with
other FidoNet-Technology Networks. Any policy disputes originating
from without RANet (Zone) must be conducted thru the ZC of that
ZONE for resolution.
ZONE ECHO COORDINATOR - The Zone Echo Coordinator(s) (ZEC) the
second in authority to the Zone Coordinator and is also the
technical authority regarding operations in terms of technical
matters within EchoNet. He is appointed by the Zone Coordinator.
The ZEC is responsible for the coordination of all technical
matters involving RANet. Specifically, message processing,
mail/message transmission and reception, and EchoMail structure
and operation, are regulated by the Zone Echo Coordinator(s).
The Zone Echo Coordinator is a full voting member of the Executive
Board.
If the office of Zone Coordinator becomes vacant, the Zone Echo
Coordinator assumes the duties of ZC,in accordance with the By-Laws.
ZONE NODELIST COORDINATOR - The Zone Nodelist Coordinator(s) (ZNC)
is third in authority to the Zone Coordinator(s) and is also respons-
ible for the weekly preparation and distribution of the RANet
nodelist(s) and updates for their Zone(s).
He is appointed by the Zone Coordinator(s). All Regional Nodelist
up-dates are forwarded to the Nodelist Coordinator(s) on a weekly
basis to be merged into the RANet nodelist for thier Zone
, which the ZNC distributes (Vie Tick Files).
The Nodelist Coordinator is a full voting member of the Executive
Board.
ZONE TECHNICAL COORDNATOR - The Zone Technical Coordnator(s) (ZTC)
is the fourth in authority to the Zone Coordnator and responc-
ible for the chairmanship of the Advisory Council of the regional
Coordnators for his zone.
************************************************************
[ This possission is Elected Office , Term Last 2 Years. Elected by
The RC's of their Zone(s). Elections will accure on Even numbered
Years. Campaining Till Dec 3 , and voting 7th. Take office Jan 1.]
*************************************************************
The Technical Coordnator is a full voting member of the Executive
Board
ZONE FILE COORDNATOR - The Zone File Coordnator(s) (ZFC)
Is the fifth in authority to the Zone Coordnator and responcible
for the operation of the FileBone of their ZONE in RANet.
Under the Authority if the IZC and ZC(s) of thier Zone(s)
The Zone File Coordnator(s) are Full Voting Members of the Exective
Board.
EXECUTIVE BOARD - The Executive Board consists of the
International Zone Coordinator, the Zone Echo Coordinator(s),
Zone Nodelist Coornator(s) , Zone Technical Coordinator(s),
ant the Zone FileNet Coordnator(s).
The Executive Board provides the last stage of appeal in
terms of policy administration above the Zone Coordinator,
and sets general terms of RANet direction for the network as
a whole. The Executive Board establishes or modifies existing
policy within RANet.
ADVISORY COUNCIL - The Advisory Council consists of each Regional
Coordinator, plus the Zone Coordinator as ex-officio member. One
of the representatives is elected by the other representatives to
serve as the Chair of the Council for a period of two (2) years,
and will be responsible for the conduct of all business. The
Chair's duties include presiding over all motions or discussion
within the Council. If a policy violation or other unresolved
problem is brought to the attention of a Regional Coordinator from
up the normal chain (Net Coordinator), and he/she is unable to
resolve it equitably, it must be brought before the Advisory
Council. If the Council's recommendations go unheeded by the
offending party(-ies), the Chair must make the issue known to the
Executive Board.
REGIONAL COORDINATOR - The Regional Coordinator(s) maintains the list
of networks, and any independent nodes within his/her respective
region. They perform an administrative function of resolving any
policy disputes brought to them in appeal from Network Coordinators,
or against any Network Coordinators themselves. The Regional
Coordinator must follow the established schedule for receiving node-
list segment updates from the network coordinators within their
region, and is responsible for the consolidation of these lists into
the regional nodelist segment, and submission to the Nodelist
Coordinator for inclusion into the weekly RANet nodelist.
Together with the latest edition of RANews, the Regional
Coordinator also receives the complete RANet weekly nodelists/
nodediffs and arranges for their distribution to the Network Co-
ordinators in a timely manner. A Regional Coordinator does not
perform message-forwarding services for any nodes in the region.
THE REGIONAL ECHO COORDINATOR (REC)
A Regional Echo Coordinator is responsible to the Zone Echo
Coordinator for all that happens in the region with regard to the
transfer and content of Echomail. The REC should be able to supply
all RANet conferences available on the Backbone to their NECs.
The Zone Echo Coordinator holds the Regional Echo Coordinator
completely responsible for the smooth operation of EchoMail within
the region. Likewise, the REC holds the Net Coordinator completely
responsible for the smooth operation of the network. It is the duty
of the REC to assure that there is absolutely NO porting of RANet
echomail to non-RANet systems; conversely, the REC must also be
certain that no non-RANet echomail is brought into RANet. The REC
must notify the ZEC if a problem remains unresolved, with carbon
copies to all concerned.
The Backbone will deliver echomail conferences to the REC(s); unless
other arrangements can be mutually agreed upon, it is the
responsibility of each REC to deliver RANet conferences to his/her
NECs or independent nodes.
THE NETWORK ECHO COORDINATOR (NEC)
A Network Echo Coordinator(s) is responsible to the Regional Echo
Coordinator for all that happens in his/her net with regard to the
transfer and content of Echomail. The NEC should be able to
supply all RANet conferences on the Backbone to their nodes
requesting them. The ZEC holds the REC(s) completely responsible for
the smooth operation of EchoMail within the region. Likewise, the
REC holds the Net Coordinator completely responsible for the
smooth operation of the network. It is the duty of the NEC to
assure that there is absolutely NO porting of RANet echomail to
non-RANet systems; conversely, the NEC(s) must also be certain that
no non-RANet echomail is brought into RANet. The NEC must
notify the offending node immediately. A node that refuses to end
this practice after one warning shall be excommunicated from
RANet. The NEC must notify the REC if a problem remains
unresolved, with carbon copies to all concerned.
NETWORK COORDINATOR - The Network Coordinator(s), who is held
responsible by the Regional Coordinator(s) for the smooth operation
of all in his net, maintains the list of nodes within his
respective geographic area, which comprises his network. He
performs an administrative function of maintaining his network's
smooth operation, and resolves any local policy disputes.
The Network Coordinator(s) administer any local coordination
required to allow new nodes to join RANet, and for any
activities resulting in changes, additions or subtractions from
the nodelist segment within his respective network. He/she 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.
The Network Coordinator(s) is charged with coordinating the receipt
and forwarding of host-routed inbound netmail for nodes in his/her
net, implementing this in a fashion left to his/her discretion; to
make available to nodes in the network new nodelist difference
files, new issues of RANews, and new revisions of Network Policy
documents as they are received; and to periodically check to
insure that nodes use up to date nodelists.
If a node in his/her network is acting in a sufficiently annoying
manner, then the NC can take whatever action is deemed fitting,
according to the circumstances of the case with in Policy.
MAINTAINING THE NODELIST
The NC(s) should implement name changes, phone number changes, so
forth in their segment of the nodelist as soon as possible after
the information is received from the affected node. The NC(s)
should also on occasion send a message to every node in their
network to ensure that they are operational. If a node turns out
to be "offline" with no prior warning, mark the node down or
remove it from the nodelist. (Nodes are to be marked DOWN for
a maximum of 4 weeks, after which the line should be removed
from the nodelist.)
At the NC(s) discretion, a portion of this workload may be assigned
to routing hubs. In this case, the NC should receive the
nodelist segments from the Hub Coordinators within his/her
network. The NC will need to maintain a set of nodelists for each
hub within his/her network, since it is unwise to count on getting
an update from each Hub Coordinator as changes are made.
The NC must assemble a master update for his/her network and send
it to the Regional Coordinator by the day and time designated
***(Tuesday 11PM)***. The RC must assemble the master Update list
for his/her region and submit it to the Zone Node Coordinator by the
day and time designated *** (Wedensday 11PM)***.
MAKING AVAILABLE POLICIES, NODELISTS AND RANews
Each NC should obtain a new issue of RNETLIST/RNETDIFF files
every week from the Regional Coordinator. The nodelist difference
file is currently made available each Friday morning from the
ZNC at 12am for the Regional Coordinator(s), and the RANews will be
sent along with the nodediff periodically. The NC(s) must
make these files available to all nodes in the network. Or send them
directly via the TICK method. Most RC's, NC's and Hub's should have
the TICK method of distributing files 24-7.
The NC is also encouraged to write an informal what's-going-on,
what's-new-in-the-net newsletter to be distributed to his/her
nodes periodically.
Each NC should also obtain the most recent versions of the Policy
documents that bind the members of his/her network, and make those
available to the nodes in their network. Policies are released at
sporadic intervals, so please inform the nodes in your network
when such events occur, and ensure the nodes are generally
familiar with the changes.
Policy, RANews, and the RNETLIST 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.
ENCOURAGE NEW SYSOPS TO ENTER RANet
A coordinator is encouraged to operate a public bulletin board
system which is freely available for the purpose of distributing
Policy, RANews, and RNETLIST to potential new sysops.
Dissemination of this information to persons who are potential
RANet sysops is important to the growth of RANet, and
coordinators should encourage development of new systems.
SYSTEM OPERATOR - Also known as 'SysOp' or Node Operator. The
SysOp or node operator within RANet who operates a network node,
or independent node within a region. All SysOps who wish to
become members of RANet must agree to abide by this policy
document as well as policy dictates by the IZC or Executive Board,
and to exist in harmony with other RANet members.
JOINING RANet:
While it is a private network, RANet is open to any SysOp who
agrees to follow the RANet Policy.
If you are a FidoNet (or other network) node, We Have our own
Node Numbering method.
(Echomail & File Transfers are sent via your RANet node number
Only.)
In order to become an RANet member, the SysOp must first obtain
an RANet SysOp Kit (available under the Magic name of "RANET" by
file request from 1:3804/2 or 72:72/1), (2:251/22 or 73:73/1)
Read and acknowledge agreement with the policy, and forward
a membership application to the Network Regional Coordinator
closest to you or the Zone Coordinator. Upon the receipt and
approval of a membership application, the new node will be added
to the weekly nodelist update submissions.
Once a member has been listed in the weekly nodelist, he becomes a
member of RANet, and is subject to RANet policy. While it is
not required that policy complaints from outside of RANet be
accepted, it is the nature of RANet that reasonable policy
complaints from outside the network will be addressed by the
International Zone Coordinator.
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. If not
available locally, the current RANet nodelist may be file
requested from 72:72/0 (1:3804/2) 73:73/0 (2:251/22)
with the magic name "RANET".
Once you have a nodelist, you must determine which network or
region covers your area. Regions are numbered 101 ,102 ECT;(USA)
or 73?? (EUR) by state or Country this time. network numbers
are by the local areacode.
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
( 72:????/0 ) of that network or region. The request must be
sent by netmail, as this indicates that your system has RANet
capability.
HOW TO WRITE AND SUBMIT THE ABOVE MESSAGE:
Within the archive of RANET.ZIP is MAKEREQ.EXE in the requested
information. Execute Makereq and answer the Questions ,and send the
out file (LASTNAME.APP) to the RANet NC (or RC) nearest to you.+
You should poll his system for a reply after a cupple days.
This should give time to read and reply with your Node Number.
+ You must set up your software so that the from-address in your
message to the NC (or RC) does not cause problems for the
coordinator. If you are currently a member of another network,
such as FidoNet, you can send your application to the NC using
your Fido address. If you are not with another network, set
your mailer to use address 72:nnnn/9999, where nnnn is the Net
or Region you're applying to. This is only temporary until your
NC or RC assigns a node number to you.
Your coordinator may contact you for additional information.
Please allow at least two weeks for a node number request to be
processed into the Nodelist. This should not keep you from
connection to the Echomail areas once you have you net number.
If you send your request to a Regional Coordinator, it
may forwarded to the appropriate Network Coordinator.
Once your application has been approved, and your node number has
been published in RNETLIST.A* , please link into RA_NET. This echo
is mandatory for and restricted to all RANet SysOps.
Your link to echomail will normally be your Network Echomail
Coordinator. (Or an RANet system who serves as a Hub for your
area.) If you are an independent node, then your RC will be happy
to help you arrange for your echomail conferences. As a last resort,
you may arrange to poll the Backbone (72:72/2 or 72:72/3 ).
Your weekly RANODE/DIFF and all administration files will be
available from your NC or RC.
SysOp Procedures
As the SysOp of an individual node, you can generally do as you
please, as long as you observe mail events, are not excessively
annoying to other nodes in RANet, and do not promote or
participate in the distribution of pirated copyrighted software or
other illegal behavior via RANet.
In order to prevent dupes between national networks and to provide
a more unique atmosphere in RANet, no one is permitted to pass
RANet echoes to a non-RANet BBS. Additionally, non-RANet
echoes may not be imported into RANet without the expressed,
netmailed permission of the Zone Echomail Coordinator.
***************************************************************
AMMENDEMS: Mail Routing Policies May Vary between different
Zones, due to the need of those Zones. This changes are available
from the Coordnator(s) of that Zone.
Also FileBone policys may change from Zone to Zone
Exclusion: No Non-RANet System Maybe connected to RANET FILEBONE.
Here to Known as:
(RAF) RemoteAccess Files Distribution
All RAnet File Echos will be labeled with the prefix RAF and be
the sole property of @RANet.
(This does in no way state ownership of any programs or files other
than RAnet Network files.)
****************************************************************
FAMILIAROTY WITH POLICY
In order to understand the meaning of "excessively annoying", it
is incumbent upon all sysops to occasionally re-read RANet
policy. New sysops should familiarize themselves with policy
before requesting a node number.
Responsible for All Traffic Entering RANet Via the Node
The SysOp listed in the nodelist entry is responsible for all
traffic entering RANet via that system. This includes (but is
not limited to) traffic entered by SysOp, users, and points. No
SysOp shall allow "outside" messages to enter RANet via his/her
system.
ENCRYPTION AND REVIEW OF MAIL
Like FidoNet, RANet 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 system constitutes
annoying behavior.
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 RANet node to another. If you are
offended by the content of a message, the procedure described in
"Not Routing Mail" must be used.
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.
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 as 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.
RESTRICTED CONFERENCES
There are several conferences that are restricted to certain
positions within RANet. For example, RA_NET is an echo for
RANet SysOps only. It may not be read or seen by _anyone_ who is
not an RANet SysOp of record - meaning, if he/she is not on the
nodelist, access to this area is to be denied him or her. When an
Approved Moderator restricts an echo, those restrictions are to be
strictly observed by all who are sanctioned to carry that
conference. Other restricted conferences may be added, please
observe the Roster of Echo Areas (ECHO????.TXT) for the status of
the conferences in RANet (USA) [???=MMYY]
Magic Name: Echolist
PRIVATE MAIL ADDRESSED TO YOU
The issue of private mail which is addressed to you is more
difficult than the in-transit question treated previously. 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 RANet.
This ideal is often compromised, as RANet 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. Judgment
and common sense should be used in this area as in all other
aspects of RANet behavior.
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, unless you hold a Network Coordinator or Hub
Coordinator 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 RANet 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.
IF YOU ARE GOING OFFLINE
If your node will be offline for longer than two days, inform your
coordinator as soon as possible.
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, racking up 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.
USERS - Users are the class of individuals who do not have the
primary responsibility for the management of a network or region
node within RANet. They may be point operators, or dial-in
users of bulletin boards within RANet. Any and all actions
taken by users are the responsibility of the System Operators of
the system which the Users are accessing. Policy complaints are
not generally addressed to users, as they are not bound by RANet
policy, however the system operator is responsible, and all
complaints about users will be addressed to the operators of the
system or systems through which the user has gained access to
RANet.
ZONE MAIL HOUR
Zone Mail Hour (ZMH) is a defined time during which all nodes are
required to be able to accept netmail. Zone Mail Hour in RANet
corresponds to that in FidoNet:
0400-0500 EST (0500-0600 EDT)
0300-0400 CST (0400-0500 CDT)
0200-0300 MST (0300-0400 MDT)
0100-0200 PST (0200-0300 PDT)
During ZMH, there should be no BBS callers allowed on your system.
This greatly facilitates the transfer of Net and EchoMail.
NODELIST
The nodelist is a file updated weekly which contains the addresses
of all recognized RANet nodes. This current nodelist is
delivered by the ZC to the RCs for distribution to their
respective NCs by Friday morning. The current nodelist is always
available for file request from any member of the Executive Board,
by using the magic name RANODE or RADIFF.
To be included in the nodelist, a system must meet the requirements
defined by this document. No other requirements may be imposed.
The full list as published by the International Zone Coordinator is
regarded as the official RANet nodelist, and is used in
circumstances such as determination of eligibility for voting.
**********************************************************
AMMENDEMS: Some of these Guide line may very from Zone to Zone.
Contact the nearest Coordnator(s) of the zone your in for more
information.
**********************************************************
POLICY GUIDELINES:
Two precepts copied from FidoNet and EchoNet applyed in RANet:
1. Thou shalt not excessively annoy others.
2. Thou shalt not be too easily annoyed.
In addition to these simple policy dictates above, the Executive
Board constantly evaluates and amends this RANet Policy document
when necessary.
FidoNet's Expression of Excessively Annoying Behavior
Applies to RANet
There are references throughout this policy to "excessively
annoying behavior." It is difficult to define this term, as it is
based upon the judgment 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
RANet. 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 become 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.
ELECTIVE POLICIES:
International Zone Coordinator Tim Settle shall remain in office until
he vacates it, at which time ZEC Tim Settle automatically becomes
International Zone Coordinator, and remains in that position until he
vacates the office, at which time ZNC automatically becomes
International Zone Coordinator, and remains in that position until he
vacates the office, at which time the Regional Coordinators (the
Advisory Council) will elect the new IZC from within their ranks. The
Chair for the discussion and election shall be an RC who definitely
does not want to assume the duties of IZC. (Allow no more than two
weeks of debates on who shall become the Chair.) The Chair shall
decide how long the IZC pre-election campaign will last.
The Zone Echo Coordinator and Zone Nodelist Coordinator
shall remain in their respective offices until replacements are
appointed by the Zone Coordinator.
The term of office for all other administrative positions within
RANet below the Executive Board is for two (2) years.
COORDINATOR RECALL OR REPLACEMENT POLICIES:
In the rare event where there is disillusion or disharmony within
RANet, there are procedures for the removal and replacement of
the administration-chain.
In the event that disharmony has occurred thru the violation of
policy by any coordinator position, the coordinator directly above
and in the chain-of-command may dictate the removal of the
offending coordinator. This is subject to appeal by the
individual removed from office to the next-higher office in the
chain of command, but should the appeal not be made, or the
appeal denied by the appropriate authority, a replacement election
will be held for the position vacated.
A second method for the removal of Coordinator positions within
RANet is a petition for recall vote. At the Network level, ten
percent (10%) of the total number of SysOps in the net, or five
SysOps, whichever is less, may file a petition with the Regional
Coordinator for removal of the Network Coordinator in question.
The Regional Coordinator has the option to accept or deny the
petition for recall. If accepted, he will direct an election be
held establishing a vote-of-confidence of the Network Coordinator
in question. In terms of simple majority of votes cast, if the
popular vote decrees that the coordinator be replaced, a
replacement election will be held. If a simple majority of those
voting in the recall election do not wish the coordinator's
removal, he will continue in the duties of his office, and not be
subject to another recall petition for at least six (6) months
after the unsuccessful recall election.
In the election held subsequent to a successful recall election, a
replaced Coordinator may run for his 'former' office unless
removed from RANet by action of the Coordinator structure. The
successful candidate in this election will serve the remainder of
the original term of office of the removed Coordinator.
At the Region level, twenty percent (20%) of the total number of
SysOps in the Region, or twenty (20) SysOps, whichever is less,
may file a petition with the Zone Coordinator for removal of the
Regional Coordinator in question. Otherwise, the procedure for
recall of Regional Coordinator is conducted in the same manner as
that of a Network Coordinator, and the Zone Coordinator's role in
this procedure is exactly the same as that of the Regional
Coordinator in Network Coordinator recalls.
Resignations by any position below the level of the Executive
Board will result in an immediate appointment by the next-higher
authority (if required for proper network operations) of a
temporary replacement, and a replacement election, as soon as
technically feasible, to fill the position so vacated. Voting
procedures will be determined by the Coordinator responsible for
the election, and will follow RANet policy as described by the
procedure then in effects. In cases where necessary, the
Coordinator conducting the election may appoint a neutral SysOp
within the election area to collect and pass forward for counting
and review - the ballots for the vacant office. (To alleviate the
costs of each individual forwarding their ballots long-distance).
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 Zone
Coordinator. At this point, the Zone Coordinator will make a
decision and communicate it to the Regional Coordinators in that
zone.
Zone Coordinator decisions may be appealed to the Executive Board.
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.
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.
If a person at any level above SysOp is unable to properly perform
their duties, the person at the next level may replace them. For
example, if a Regional Coordinator fails to perform, the Zone
Coordinator can replace him.
RANEWS NEWSLETTER:
RANet offers a free 'electronic newsletter' called RANews(c),
which is provided as a central communications medium and
information exchange vehicle for our members. We are all
encouraged to make submissions and to make it available for
reading by our members. The current Editor's name and node number
is listed at the top of the RANet nodelist. Each NC should
obtain a new issue of RANews from the Regional Coordinator,
along with the last nodediff of the Week. The NC must make these
files available to all nodes in the network.
Where Do I Get an RANet Policy Statement?
All "RANet NODES" must have a copy of RANet's current Policy
Statement(s) avaiable on their BBS for requests.
Or, you can file request POLICY from 72:72/0, 72:72/1, 72:72/2
or any USA RANet Node.
In Europe: 73:73/0 ,73:73/1,73:73/2 or any RANet node.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This Policy Statement may be amended by the International
Zone Coordnator or the Executive Board as a Unit when deemed
necessary. Your suggestions, comments and constructive
criticism are always welcome and should be addressed directly
to the RANet HeadQuarters, Or Zone Coordnator of your Zone.
Latest Revision: 1 January 1993, RNet_POL.003
RANEt HeadQuarters 72:72/0
Reference in New Issue View Git Blame Copy Permalink