DP Tool Club 19

home *** CD-ROM | disk | FTP | other *** search

/ DP Tool Club 19 / CD_ASCQ_19_010295.iso / vrac / safnet.zip / SAF-POL.001 < prev next >

Wrap

Text File | 1994-05-11 | 65KB | 1,348 lines

"SAF-NET" Policy Statement Ver. 1.1 (C) Copyright 1992,1994 IESN, Inc. & Dan Guenthner. SAF-NET(sm) Springfield, OR. All rights reserved. This policy document has been accepted by a vote of the SAF-NET Executive Board, and is the current SAF-NET policy document, until superseded. OVERVIEW This document establishes the policy for sysops who are members of the SAF-NET organization of electronic bulletin board systems. SAF-NET is defined by a NodeList issued weekly by the Zone Nodelist Coordinator / Zone Coordinator. Separate policy documents may be issued at the region, or net level, to provide additional detail on local procedures. Ordinarily, these lower-level policies may not contradict this policy. However, with the approval of the Zone Coordinator, local policy can be used to implement differences required due to local conditions. These local policies may not place additional restrictions on members of SAF-NET, beyond those included in this document, other than enforcement of local mail periods. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 2 1.0 Language The official language of SAF-NET is English. All documents must exist in English. Translation into other languages is encouraged. 1.1 Introduction This is the Policy and Structure of SAF-NET, a new approach in private electronic message distribution, offered to approved affiliated nodes agreeing to abide by its rules and regulations as contained in this document. The purpose of SAF-NET is the exchange of electronic messages, known as EchoMail, with reliability and dedication. The echoes on SAF-NET will either relate to the interests of Safety Professionals directly, or will benefit "SAF-NET" as a whole. All current administrators, everyone who has accepted (or ever will accept) an "official" position, at any level within SAF-NET, is a person recognized for carrying out his/her responsibilities in a professional manner. All members of the administration are highly aware of the need for helping each other and those they are responsible for. This "attitude" is of primary consideration when selecting new administrators. Concerning "Pay Systems", ie., those BBS's which charge for access to their systems. If it is within the software's capabilities, all SAF-NET areas (echoes and file areas) will be made accessible for a minimum of 30 minutes without charge to the user. Should the software being used, not be capable of this, or should you not wish to, you MUST notify your RC and the ZC of this situation, so that it can be kept on record. 1.2 ECHOMAIL STANDARDS SAF-NET Echomail Policy MUST be read by each SysOp and is contained in this document (second half). Our Echomail Policy differs from most other networks, and you should be aware of it. Because each SysOp decides which echoes he/she will carry on their BBS, EchoMail conference creations within SAF-NET 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 their Regional Coordinator, Regional EchoMail Coordinator or their Net EchoMail Coordinator. Experienced moderators, from conferences outside SAF-NET, should also contact their SAF-NET NC/NEC for guidelines before submitting their proposed conference to the ZC/ZEC. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 3 1.2.1 - General Prohibitions for EchoMail conferences on SAF-NET: A. No conference that violates FCC regulations. B. No conference that in any way advocates pirated software. C. No conference that deals with "dating" or "escort" services. D. With rare exceptions, no conference may be moderated by a non-SAF-NET SysOp. A Moderator who operates as a Point off a SAF-NET Boss node, is considered a SAF-NET member. The same applies to a Moderator who is a User on a SAF-NET member, BBS. F. In order to prevent dupes between national networks and to provide a more unique atmosphere in SAF-NET, no one is permitted to pass SAF-NET echoes to a non-SAF-NET member BBS. Additionally, non-SAF-NET echoes may not be imported into SAF-NET. A SAF-NET Gateway, to other networks is run by the ZC/ZEC or his/her assigned individual to take care of any importing or exporting of echoes, no other gateways, of any kind may exist without permission from the ZC/ZEC. 1.3 DEFINITIONS 1.3.1 - 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 Net via one or more regular SAF-NET nodes. Communication to or from a point system into the greater Net is always conducted through one or more regular nodelisted systems. The system operator of the nodelisted system, through which a point communicates to the Net at large, is responsible for the proper adherence to SAF-NET policy for his respective point systems. 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 SAF-NET policy, Point systems are treated as users of a nodelisted system. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 4 1.3.2 - Nodes A node is a system which is capable of FidoNet-Technology Electronic Mail generation and exchange, and is listed in the SAF-NET nodelists. A node is identified by a unique address within a given Net, region or zone, which is assigned by the appropriate Net or regional coordinator specific to that node. 1.3.3 - Nets A Net is a collection of nodes, usually within a relatively local geographic area. In terms of SAF-NET, Net areas will usually be distinct geographic groupings arranged in such a way as to facilitate the exchange of electronic mail, and the coordination information. In an effort to further identify geographic location based on net affiliation, SAF-NET has adopted a unique system for assigning Net numbers. As each region is made up of selected States or Provinces, each State or Province, within the region is assigned a series of numbers which can be used. These numbers are unique to that State or Province and can be used to identify where the system is located. Example: 44:9200/1 Zone: 44 - SAF-NET Net : 9200 - Region "9" (Northwest), State "2" (Oregon), Net "00" (Springfield). Node: 1 - Node # 1. See "Address.txt" for the assignments of Regions and States. 1.3.4 - Regions A region is a collection of both Nets 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 Net for valid technical reasons which are accepted by the Nodelist and Technical Coordinators. SAF-NET region boundaries are original and subject to change by the Zone Nodelist Coordinator when necessary. 1.3.5 - Zones A zone is a collection of regions. In terms of SAF-NET, the entire nodelist comprises a single Zone, until such time as the Zone Coordinator in conjunction with the Nodelist and Technical Coordinators determines it expedient to expand into multiple zones. SAF-NET is known as 'Zone 44', which will allow for proper zone-gating or domain-gating systems of FidoNet-style mail-transfers to be utilized. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 5 1.4 POSITIONS WITHIN SAF-NET 1.4.1 - Zone Coordinator (ZC) - The Zone Coordinator (ZC) is the highest administrative office within SAF-NET. He has ultimate authority over all SAF-NET operations and, since SAF-NET 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 him/herself. The ZC is responsible for the overall operation and effectiveness of SAF-NET Network. As such he retains a full voting position on the Executive Board and participates in decisions affecting the operation or direction of SAF-NET. The Zone Coordinator is also the designated, point-of-contact, for all inter-net liaison with other, FidoNet-Technology Networks or any other outside agency, company or the like. Any policy disputes originating from outside SAF-NET, must be conducted through the ZC for resolution. 1.4.2 - Zone Nodelist Coordinator (ZNC) - The Zone Nodelist Coordinator (ZNC) is second in authority to the Zone Coordinator and is also responsible for the weekly preparation and distribution of the SAF-NET nodelist. He is appointed by the Zone Coordinator. All Regional nodelist up- dates are forwarded to the Nodelist Coordinator on a weekly basis to be merged into the SAF-NET nodelist, which the ZNC distributes to the Regional Coordinators. The Nodelist Coordinator is a full voting member of the Executive Board. If the office of Zone Co- ordinator becomes vacant, the Nodelist Coordinator assumes the duties of ZC, in accordance with the By-Laws. 1.4.3 - Zone Technical Coordinator (ZTC) - The Zone Technical Coordinator (ZTC) is third in authority to the Zone Coordinator and is also the technical authority regarding operations in terms of technical matters within SAF-NET. He is appointed by the Zone Coordinator. The ZTC is responsible for the coordination of all technical matters involving SAF-NET. Specifically, message processing, mail/message transmission and reception, and EchoMail structure and operation, are regulated by the Technical Coordinator. The Technical Coordinator is a full voting member of the Executive Board. 1.4.4 - Executive Board - The Executive Board consists of five individuals, the Zone Coordinator, the Zone Nodelist Coordinator, the Zone Technical Coordinator and two other individuals, appointed by the Zone Coordinator. The Executive Board provides the last stage of appeal, in terms of policy disputes, ONLY, above the Zone Coordinator, and helps set the general terms of SAF-NET direction for the network as a whole. The Executive Board assists the ZC (Zone Coordinator) in establishing and or modifying, existing policy within SAF-NET. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 6 1.4.5 - 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. 1.4.6 - Sysop Council - The SysOp Council consists of one SysOp (who does not hold any other official position) representative from each State or Province, found within SAF-NET, plus the Zone Coordinator (or his/her designated appointee) as an ex-officio member. One of the representatives is elected as Chair of the council and serves for a period of one (1) year and is responsible for the conduct of all business. This council serves in an "advisory" capacity only and holds no authority over anyone and can form no direct policies concerning SAF-NET. Their purpose is to advise the ZC directly, of concerns, ideas, thoughts, etc., which affect the general SysOp. 1.4.7 - Regional Coordinator (RC) - The Regional Coordinator maintains the list of Nets, 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 Net Coordinators, or against any Net Coordinators themselves. The Regional Coordinator must follow the established schedule for receiving nodelist segment updates from the Net 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 SAF-NET nodelist. Together with the latest edition of SAFNews, the Regional Coordinator also receives the complete SAF-NET weekly nodelists/nodediffs and arranges for their distribution to the Net Co- ordinators in a timely manner. RCs are responsible for selecting a SysOp from each State or Province within his/her region, to be a member of the SYSOP COUNCIL. The selection process can be of his/her own choosing, but it is suggested an election be performed, amongst the SysOps of each State or Province for the position. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 7 1.4.8 - Net Coordinator (NC) - The Net Coordinator, is held responsible by the Regional Coordinator, for the smooth operation of all in his net, maintains the list of nodes within his respective geographic area, which comprises his Net. He performs an administrative function of maintaining his Net's smooth operation, and resolves any local policy disputes. The Net Coordinator administers any local coordination required to allow new nodes to join SAF-NET, and for any activities resulting in changes, additions or subtractions from the nodelist segment within his respective Net. He/she will use Net mail to inform a new SysOp of the node number, as this helps to insure that the system is capable of receiving Net mail. It is within his/her jurisdiction and responsibility to call a meeting of all SysOps in his/her particular Net when he/she feels such a meeting is necessary. The Net Coordinator 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 net the new nodelist files, new issues of SAFNews 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 net is acting in a sufficiently annoying manner, then the NC can take whatever action is deemed fitting, according to the circumstances of the case. 1.4.8.1 - Maintaining the Nodelist The NC will implement name changes, phone number changes, and so forth in their segment of the nodelist as soon as possible after the information is received from the affected node. The NC will also, on occasion, send a message to every node in their net to ensure that they are operational. If after three attempts at contacting a node, it contact still fails, the node is to be listed as "down". (Nodes are to be marked DOWN for a maximum of four weeks, after which the line will be removed from the nodelist) It is not necessary for the NC to contact the questionable node, in any manner, other than electronically. At the NC's discretion, a portion of this workload may be assigned to routing hubs. In this case, the NC will receive the nodelist segments from the Hub Coordinators within his/her net. The NC will need to maintain a set of nodelists for each hub within his/her Net, since it is unwise to count on getting an update from each Hub Coordinator every week. The NC must assemble a master nodelist for his/her net every week and send it to the Regional Coordinator by the day and time designated. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 8 1.4.8.2 - Making Available Policies, Nodelists and SAFNews Each NC will obtain a new issue of SAFNews and a new nodelist file as they are made available from the Regional Coordinator. The nodelist file is made available each Saturday morning from the Regional Coordinator, and the monthly SAFNews will be sent along with the nodelist as released. The NC must make these files available to all nodes in the net. Each NC will also obtain the most recent versions of the Policy documents, and make those available to the nodes in their net. Policies are released at sporadic intervals, so please inform the nodes in your net when such events occur, and ensure the nodes are generally familiar with the changes. 1.4.8.3 - Encourage New Sysops to Enter SAF-NET A coordinator is encouraged to operate a public bulletin board system which is freely available for the purpose of distributing Policy, SAFNews, and Nodelists to potential new sysops. Making these available to persons who are potential SAF-NET sysops is important to the growth of SAF-NET, and coordinators should encourage development of new systems. *** NOTE *** The two following positions, REC & NEC are included in this documentation only to cover the possible needs of the future. The RCs and NCs will fill these positions until such time as it is deemed necessary to do otherwise. Each Region, in conjunction with the ZC, will make the decision, if and when, it is necessary to expand. 1.4.8 - 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 will be able to supply all SAF-NET 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 SAF-NET echomail to non-SAF-NET systems, conversely, the REC must also be certain that no non-SAF-NET echomail is brought into SAF-NET. The REC must notify the ZC/ZEC if a problem remains unresolved, with carbon copies to all concerned. It is the REC's responsibility to pickup echomail conferences from the Backbone, unless other arrangements can be mutually agreed upon. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 9 1.4.9 - Net Echo Coordinator (NEC) A Net Echo Coordinator 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 will be able to supply all SAF-NET conferences on the Backbone to their nodes requesting them. The NEC is held completely responsible for the smooth operation of EchoMail within the Net. It is the duty of the NEC to assure that there is absolutely NO porting of SAF-NET echomail to non-SAF-NET systems. Conversely, the NEC must also be certain that no non-SAF-NET echomail is brought into SAF-NET. The NEC must notify the offending node immediately. A node that refuses to end this practice after one warning shall be excommunicated from SAF-NET. The NEC must notify the REC if a problem remains unresolved, with carbon copies to all concerned. It is the NEC's responsibility to pickup echomail conferences from their REC's, unless other arrangements can be mutually agreed upon. 1.4.10 - System Operator Also known as 'SysOp'. The SysOp is someone within SAF-NET who operates a Net/Node, or independent Node within a Region. All SysOps who wish to become members of SAF-NET must agree to abide by this policy document as well as policy dictates of the ZC or Executive Board and to co-exist, in harmony, with other SAF-NET members. 1.4.10.1 - 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 SAF-NET, and do not promote or participate in the distribution of pirated copyrighted software or other illegal behavior via SAF-NET. In order to prevent dupes between national networks and to provide a more unique atmosphere in SAF-NET, no one is permitted to pass SAF-NET echoes to a non-SAF-NET BBS. Additionally, non-SAF-NET echoes may not be imported into SAF-NET, other than through the approved SAF-NET Gateway operated by the ZC/ZEC or assigned individual. 1.4.10.2 - Familiarity with Policy In order to understand the meaning of "excessively annoying", it is incumbent upon all sysops to occasionally re-read SAF-NET policy. New sysops will familiarize themselves with policy before requesting a node number. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 10 1.4.10.3 - Responsible for All Traffic Entering SAF-NET Via the Node The SysOp, as listed in the nodelist entry, is responsible for all traffic entering SAF-NET via his/her system. This includes (but is not limited to) traffic entered by SysOp, users, and points. No SysOp shall allow "outside" messages to enter SAF-NET via his/her system. "Outside" meaning from systems who are not part of SAF-NET. 1.4.10.4 - Encryption and Review of Mail 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 purposes. Encryption obviously makes this review impossible. Therefore, encrypted traffic that is routed without the express permission of all the links in the delivery system constitutes annoying behavior. 1.4.10.5 - No Alteration of Routed Mail You may not modify, other than as required for routing or other technical purposes, any message, netmail or echomail, passing through the system from one SAF-NET node to another. If you are offended by the content of a message, the procedure described in "Not Routing Mail" must be used. 1.4.10.6 - Private Netmail The word "private" should be used with great care, especially with users of a BBS. Some countries have laws which deal with "private mail", and it should be made clear that the word "private" does not imply that no person other than the recipient can read messages. Sysops who cannot provide this distinction should consider not offering users the option of "private mail". If a user sends a "private message," the user has no control over the number of intermediate systems through which that message is routed. A SysOp who sends a message to another SysOp can control this aspect by sending the message direct to the recipient's system, thus guaranteeing that only the recipient or another individual to whom that SysOp has given authorization, can read the message. Thus, a SysOp may have different expectations than a casual user. 1.4.10.7 - Non 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. This does not apply to echomail, which by definition, is a broadcast medium and where private mail is often used to keep a SysOp-only area restricted. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 11 1.4.10.8 - Restricted Conferences There are several conferences that are restricted to certain positions within SAF-NET. For example, SAF_SYSOP is an echo for SAF-NET SysOps only. It may not be read or seen by anyone who is not a SAF-NET SysOp of record - meaning, if he/she is not in 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 carry that conference. Failure to do so is considered annoying behavior. 1.4.10.9 - 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 SAF-NET. This ideal is often compromised, as SAF-NET is often 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 SAF-NET behavior. 1.4.10.10 - Not Routing Mail You are not required to route mail if you have not agreed to do so. You are not obligated to route mail for all if you route it for any, unless you hold a Net Coordinator or Hub Coordinator position. Routing mail 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 SAF-NET 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 mail due to a technical problem, does not become annoying unless it persists after being pointed out to the SysOp. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 12 1.4.10.11 - If You are Going Off-line If your node will be off-line for longer than three 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, possibly incurring 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. 1.4.11 - Users Users are the class of individuals who do not have the primary responsibility for the management of a net or region node within SAF-NET. They may be point operators, or dial-in users of bulletin boards within SAF-NET. 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 SAF-NET 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 SAF-NET. 1.5 JOINING SAF-NET While it is a private network, SAF-NET is open to any SysOp who agrees to follow the SAF-NET Policy. In order to become an SAF-NET member, the SysOp must first obtain the SAF-NET "StartUp File" (available under the Magic name of "SAFNET" by file request from all RC/NC's or 1:152/911, or 44:44/0). He/she must read and acknowledge, agreement with the policy, and forward a membership application (see below) to the Net or Regional Coordinator or in remote locations, the Zone Coordinator. Upon the receipt and approval of a membership application, the new node will be added to the weekly nodelist update. Once a member has been listed in the weekly nodelist, he becomes a member of SAF-NET, and is subject to SAF-NET policy. While it is not required that policy complaints from outside of SAF-NET be accepted, it is the nature of SAF-NET that reasonable policy complaints from outside the network will be addressed by the Zone Coordinator and dealt with accordingly. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 13 1.5.1 - 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, though the RC/NC's will always have the listing, the current SAF-NET nodelist may be file requested from 44:44/200 (FidoNet - 1:152/911) with the magic name of "SAFLIST". Once you have a nodelist, you must determine which Net or region covers your area. Regions are numbered 100-900, Net numbers are assigned by a State or Province code, found at the end of the nodelist, or in "Address.txt". Nets 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 Net which covers your area, then pick the Region which does. Once you have located the Net or Region in your area, send a message containing a request for a node number to node zero of that net or region. The request must be sent by netmail, as this indicates that your system has SAF-NET capability. 1.5.2 - Membership Message What and How to write and submit the above message (membership application): Include: - Your name. - Your voice telephone number. - The name of your system. - The city and state where your system is located. - The phone number to be used when calling your system. - Your hours of operation, netmail and BBS. - The maximum baud rate you can support. - The type of mailer software and modem you are using. - Acknowledgment that you HAVE read SAF-NET Policy and SAF-NET Echomail Policy and agree to it. 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 44: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. If you send your request to a Regional Coordinator, it may forwarded to the appropriate Net Coordinator. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 14 Once your application has been approved, and your node number has been published in SAFLIST.* , please link into SAF_SYS. This echo is mandatory for and restricted to all SAF-NET SysOps. Your link to echomail will normally be your Net Echo Coordinator. (Or an SAF-NET 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 (44:44/100). Your weekly SAFLIST and all administration files will be available from your NC or RC. 1.5.3 ***** Note ***** SAF-NET Administrators recognize the fact that many individuals wishing to join SAF-NET may not have had much, if any, experience with "Computer Communications". With this in mind "special" provisions can be made to help those individuals get started in SAF-NET. Though normally, a netmail message is required to initiate a memebership request, voice contact may be used, to start the process. Obviously, before entry to the nodelist can be completed, the system must be operating correctly, capable of performing electronic mail transfers. 1.6 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 SAF-NET 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 NetMail. It is also suggested that no attempt to pick up EchoMail be made during this time period to further facilitate the exchange of possible NetMail packets. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 15 1.7 NODELIST The nodelist is a file updated weekly which contains the addresses of all recognized SAF-NET nodes. This current nodelist is delivered by the ZNC 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, RCs or NCs, by using the magic name 4X4LIST. To be included in the nodelist, a system must meet the requirements defined by this document. Regional and Net Coordinators may create "local" policies to outline policies considered important in their areas. All "local" policies must be approved of by the Zone Coordinator before they may take effect. The full list, as published by the Zone Coordinator, is regarded as the official SAF-NET nodelist, and is used in circumstances such as determination of eligibility for voting. 1.8 POLICY GUIDELINES Two precepts copied from FidoNet and applied in SAF-NET: 1. Thou shall not excessively annoy others. 2. Thou shall not be too easily annoyed. Essentially this means: 1. Think before you speak (type) and respect the rights of others as you wish them to respect you. 2. Count to ten before responding and if that doesn't work, count to ten again. Continue until calm. In addition to these simple policy dictates above, the Executive Board constantly evaluates and amends this SAF-NET Policy document when necessary. 1.8.1 FidoNet's expression of "Excessively Annoying Behavior", applies to SAF-NET. 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. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 16 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 in SAF-NET. 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. 1.9 ELECTIVE POLICIES 1.9.1 - Zone Coordinator The Zone Coordinator (ZC), shall remain in office until he vacates it. Prior to the time the ZC wishes to step down, an advisory committee will be created to select a new ZC. The committee will be made up of the remaining members of the Executive Council and chaired by a member of the RC group, who does not wish to hold the position of ZC. (Allow no more than two weeks of debates on who shall become the Chair) The Chair shall decide how long the ZC pre-election campaign will last. 1.9.2 - Zone Nodelist Coordinator / Zone Technical Coordinator The Zone Nodelist Coordinator and Zone Technical Coordinator shall remain in their respective offices until replacements are appointed by the new Zone Coordinator should he/she feel the need to do so. 1.9.3 - Regional Coordinator / Regional Echo Coordinator Net Coordinator / Net Echo Coordinator The term of office for all other administrative positions within SAF-NET, below the Executive Board, is for not more than, two (2) years. It is suggested (not mandatory) that NC/NEC positions be voted on, yearly and RC/REC positions be voted on every two (2) years. Multiple, consecutive, terms are permitted. 1.10 COORDINATOR RECALL OR REPLACEMENT POLICIES In the rare event where there is disillusion or disharmony within SAF-NET, there are procedures for the removal and replacement, in the administrative chain. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 17 1.10.1 - Policy Violations In the event that disharmony has occurred through 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. 1.10.2 - Recall Vote A second method for the removal of Coordinator positions within SAF-NET (other than Zone Coordinator), is a "petition for recall" vote. At the Net 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 Net 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 Net 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/she will continue in the duties of the 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 SAF-NET 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 Net Coordinator, and the Zone Coordinator's role in this procedure is exactly the same as that of the Regional Coordinator in Net Coordinator recalls. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 18 1.10.3 - Resignation 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, followed by a replacement election, as soon as technically feasible. Voting procedures will be determined by the Coordinator responsible for the election, and will follow SAF-NET 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). 1.10.4 - 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 Net 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. 1.10.4.1 - The appeal structure Net 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. 1.10.5 - 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. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 19 1.10.6 - 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/her. 1.11 SAFNews NEWSLETTER SAF-NET offers a free 'electronic newsletter' called SAFNews(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 SAF-NET nodelist. Each NC should obtain a new issue of SAFNews from the Regional Coordinator, along with the last nodelist of the month. The NC must make these files available to all nodes in the network. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 20 2.0 ECHOMAIL 2.1 General Information No SAF-NET conference may be "gated", "ported", "passed" or in any way, made available to a non-SAF-NET system without the express permission of the ZC/ZEC. Non SAF-NET originating Echoes, may be made available on SAF-NET at the discretion of the ZC/ZEC. The ZC/ZEC retains the only official "gateway" permissible from SAF-NET to or from any other Network. No Echo carried by SAF-NET will be allowed to exist without a Moderator for a period longer than one month (30 Days). Should a situation exist, where an Echo remains without a Moderator for longer than one month (30 Days), either the ZC/ZEC will appoint a new Moderator or instruct the Echo be removed from the SAF-NET Backbone. 2.2 ECHO CREATION A conference (Echo) can be created by any member of SAF-NET who feels a need exists for a particular subject area. 2.2.1 - Local Echoes Echoes which are for local consumption only, on a Net or Regional level, only need the permission of the *EC who oversees the intended areas. (NEC for Net level, REC for Regional) All relevant SAF-NET policies must be adhered to. 2.2.2 - Backbone Echoes (SAF-NET Wide) Anyone wishing to create an Echo destined for the SAF-NET backbone, must netmail a request to the ZC/ZEC explaining the subject of the echo and why they think it would be of benefit to the SAF-NET community. This request should be sent, prior to the Echo's local creation or as soon as possible, there-after. The ZC/ZEC will netmail a reply either accepting or rejecting the proposed Echo. Should the echo be rejected, it can be created as a local echo and the Moderator can reapply for Backbone status not earlier than 30 days later. If the Echo is accepted, the proposed Echo can be announced by the Moderator in the "ECHOES" Echo, making it available, from his/her system, to any other SAF-NET system who wishes to receive it directly from them. After a period of 30 days, the Moderator may Netmail the ZC/ZEC a message expressing the desire that the echo be transferred to the Backbone. With this message, a file of the Echo's message status must be sent, showing a minimum traffic flow of 7 incoming messages a week. A confirmation message from the Moderator's NEC must be forwarded to the ZC/ZEC, attesting to the Echo's traffic status. Once the ZC/ZEC approves the entry of the Echo onto the Backbone, the REC will be directed to include the Echo onto the Backbone. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 21 2.2.2.1 - BackBone Distribution No NEC may connect an Echo into the Region without the REC's permission and no REC may connect an Echo onto the Backbone without the ZC/ZEC's permission. 2.2.2.2 - Special Circumstances Under certain circumstances, the ZC/ZEC may elect to allow a newly created Echo to be entered onto the Backbone without delay. The decision to do this or not is made solely by the ZC/ZEC. 2.2.2.3 - EchoList Once approved, the echo information and Moderator name will be entered into the "EchoList", the official list of Echoes and Moderators, kept by the ZC/ZEC. The EchoList is published monthly and is available from any administrative member of SAF-NET under the magic name of "SAFELIST". 2.3 MODERATORS 2.3.1 - Selection In general, the creator/founder of an echo will be appointed as the Moderator if they so desire. Under rare circumstances, the ZC/ZEC may elect to accept the conference (Echo), but request the Moderator be someone other than the Echo's creator. 2.3.2 - Responsibilities and Requirements A Moderator who is a User and not the SysOp of the board originating a SAF-NET conference, must be able to send and receive netmail in a manner authorized by the SysOp. Moderators who are Points off the originating board, must also have this privilege. Normally a person is willing to moderate a topical conference in which he/she has an interest and a certain amount of knowledge. A Moderator need not be (and rarely is) an "expert" on the subject matter of the conference. A Moderator's behavior should encourage message posters to continue participating. An abrasive Moderator soon empties his or her conference of quality participants. 2.3.3 - Rules A Moderator, while regulating control of his or her conference, does this by enforcing the conference rules approved of by the Zone Echomail Coordinator. Under no circumstances may a Moderator alter those approved rules without first submitting the changes to the ZC/ZEC for approval. No conference rules may be posted without having first been approved by the ZC/ZEC. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 22 It is the Moderator's responsibility to post the rules of the echo on a monthly (minimum) basis in the echo he/she moderates. Frequency of rules posting will be up to the Moderator otherwise, if he/she feels posting them more often is necessary, then he/she is authorized to do so. 2.3.4 - Problems Should a Moderator encounter a problematic User in his or her conference, the Moderator is empowered to request the excommunication of that User from the conference, providing that the User has been warned at least two (2) times either in the conference itself (which is rarely considered good form, but sometimes necessary), or by netmail sent directly to the User or, in cases where the SysOp disallows netmail privileges to his or her Users, to the SysOp for forwarding to the User. The SysOp is expected to cooperate with the Moderator's requests in accordance with the Policy of SAF-NET and of the rules of the echo. 2.4 ECHOMAIL AREA COMPLAINTS 2.4.1 - User Removal If it becomes necessary for a Moderator to request that a User be barred from a conference, and the User disregards this decision, continuing to post in the conference, the Moderator will send netmail to the SysOp of the system from which the user most frequently posts, requesting the User be denied access to the echo. All such netmail messages must be carbon copied to the system's NEC, or to the REC if the NEC's position is unoccupied. The SysOp is expected to follow the requests of the moderator. After waiting seven (7) days without a response from the SysOp, the Moderator will assume the SysOp has been on vacation or that some other legitimate reason is causing the lack of response, and must make one more attempt at netmailing the SysOp for co-operation. Only after these two tries can the Moderator request the conference's feed be cut to that BBS. A carbon copy of all correspondence will be sent to the NEC. Include all necessary documentation in an arched file, forwarded with the netmail message to the NEC. 2.4.2 - System Feed Removal When requesting an echo link be cut, the Moderator will send a message to the NEC, officially requesting the action and carbon copying that request to the REC, or the ZC/ZEC if the REC's position is unoccupied. The NEC will confirm that any request for a linkage cut is from the bona fide Moderator, of the Echo. The NEC will then make an attempt to settle the matter by addressing the SysOp in question, should this fail to solve the problem, may then cut the feed for that Echo. The NEC will then notify the REC of this action. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 23 2.4.3 - Net Feed Removal Should the NEC fail or refuse to cut a link, after a valid request from a Moderator, the Moderator may send netmail, directly to the REC, requesting action be taken. Should the REC fail to illicit a response from the NEC, he/she may then cut the entire net from the echo. However, prior to performing this drastic action, the Moderator and the REC will attempt, at least once more, to contact the NEC, carbon copying the messages to the ZC/ZEC. Include all necessary documentation of the problem in an archived file to be forwarded with the netmail to the ZC/ZEC. No Net in SAF-NET may have its entire feed for a conference removed without the knowledge and approval of the ZC/ZEC, prior to this action being taken. 2.4.4 - Regional Feed Removal Under extreme circumstances, it may be necessary to cut the feed of an echo to an entire Region for a period of time. The REC may request such action be taken, in an attempt to quell a particular problem. Should this be necessary, only the ZC/ZEC can authorize such action and only the system feeding the REC for that particular echo make the actual cut. 2.5 MODERATOR REMOVAL 2.5.1 - Voluntary Resignation A Moderator, who desires to step down from their responsibilities as Moderator, is authorized to find a replacement Moderator either by appointing another or by holding an election, within the Echo. Considerations for continuity of discussions, within the Echo, will be of primary importance in this decision. Under no circumstance should the process exceed one month (30 days). Should a problem exist, whereby the existing Moderator is unable to be replaced within the one month (30 day) period, the ZC/ZEC will be notified and will appoint a new Moderator. The ZC/ZEC holds the final decision on whether or not to accept the new appointment. 2.5.2 - Forced Resignation Authority to remove a Moderator from a SAF-NET conference is reserved for the ZC/ZEC. It must be shown that the Moderator violated SAF-NET Policy and was sent at least two netmailed warnings. The ZC will consult with the other members of the Executive Board, who may request further input from the RC's. In the case where one individual moderates multiple SAF-NET conferences, once removed by the ZC/ZEC as Moderator of one conference, that same Moderator may be reviewed concerning his/her ability to moderate the other Echoes. The ZC/ZEC must arrange for a replacement(s) as soon as possible. SAF-NET Policy Document Ver. 1.1 08-13-93 Page 24 2.6 BACKBONE ECHO REMOVAL 2.6.1 - Lack of Use The main reason an Echo will be removed from SAF-NET would be due to lack of use. Should an Echo not have a message entered into it for a period of one month, it will be removed from the Backbone. 2.6.2 - Moderator's Request A Moderator requesting that his/her Echo be removed, for whatever reason, will be taken under advisement by the ZC/ZEC. --------------------------------------------------------------------- All *Cs must have a copy of SAF-NET's current Policy Statement(s) on their BBS for file requests. Or, you can file request POL from 144:144/100, 144:144/200, or 144:144/300. --------------------------------------------------------------------- This Policy Statement may be amended, by the Executive Board, when deemed necessary. Your suggestions, comments and constructive criticism, are always welcome.