ÛÛÛÛÛÛÛÛÛÜ ÜÛÛÛÛÛÛÛÛÛÜ ÛÛÛÛ ÛÛÛÛ ÛÛÛ (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