FidoNet Policy Document Version 5.22 *** DRAFT *** Sep 29, 1989 This policy document has not been released for vote by the coordinator structure and is not yet in force. 1 Overview This document establishes the policy for sysops who are members of the FidoNet organization of electronic bulletin board systems. FidoNet membership is defined by a NodeList issued weekly by the International Coordinator. Separate policy documents may be issued at the zone, 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 FidoNet beyond those included in this document, other than enforcement of local mail periods. 1.0 Language The official language of FidoNet is English. All documents must exist in English. Translation into other languages is encouraged. 1.1 Introduction FidoNet is an amateur electronic mail system. As such, all of its partici- pants and operators are unpaid volunteers. From its early beginning as a few friends swapping messages back and forth (1984), it now (1989) includes over 5,000 systems on six continents. FidoNet is not a common carrier or a value-added service network and is a public network only in as much as the independent, constituent nodes may individually provide public access to the network on their system. FidoNet exists to provide electronic mail services to its member sysops. To efficiently provide such services, various structure and control mechanisms are necessary. Multinet operation provides the structure. Decentralized management provides the control. This document describes the procedures which have been developed to manage the network. 1.2 Organization FidoNet systems are grouped on several levels, and administration is decen- tralized to correspond with these groupings. This overview provides a summary of the structure; specific duties of the coordinator positions are given later in the document. Authorities not defined within this document shall be defined by local policies subject to review by the appropriate Zone Coordinator. 1.2.1 Individual Systems and System Operators The smallest subdivision of FidoNet is the individual system, corresponding to a single entry in the nodelist. The system operator (sysop) formulates a policy for running the board and dealing with users. The sysop must mesh with the rest of the FidoNet system to send and receive mail, and the local policy must be consistent with other levels of FidoNet. 1.2.1.1 Users The sysop is responsible for the actions of any user when they affect the rest of FidoNet. (If a user is annoying, the sysop is annoying.) Any traffic entering FidoNet via a given node, if not from the sysop, is consid- ered to be from a user and is the responsibility of the sysop. (See section 2.1.3.) 1.2.1.2 Points A point is a FidoNet-compatible system that is not in the nodelist, but communicates with FidoNet through a node referred to as a bossnode. A point is generally regarded in the same manner as a user, for example, the bossnode is responsible for mail from the point. (See section 2.1.3.) Points are addressed by using the bossnode's nodelist address; for example, a point system with a bossnode of 114/15 might be known as 114/15.12. Mail destined for the point is sent to the bossnode, which then routes it to the point. In supporting points, the bossnode makes use of a private net number which should not be generally visible outside of the bossnode-point relationship. Unfortunately, should the point call another system directly (to do a file request, for example), the private network number will appear as the caller's address. In this way, points are different from users, since they operate FidoNet-compatible mailers which are capable of contacting systems other than the bossnode. 1.2.3 Networks and Network Coordinators A network is a collection of nodes in a local geographic area, defined by an area of local telephone calling. Networks coordinate their mail activity to decrease cost. The Network Coordinator is responsible for maintaining the list of nodes for the network, and for forwarding netmail sent to members of the network from other FidoNet nodes. The Network Coordinator may make arrangements to handle outgoing netmail, but is not required to do so. Network Coordinators are elected by a majority vote of the nodes in his/her network. 1.2.3.1 Hub Coordinators Hub Coordinators exist only in some networks. They may be appointed by the Network Coordinator or elected (the exact method of selection is left to local policy), in order to assist in the administration of a large network. The exact duties and procedures are a matter for the Network Coordinator and the Hub Coordinators to arrange in accordance with local policy, and will not be discussed here. Hub Coordinators may assist in the administration of a network by providing additional routing and distribution services within the network and by acting as advisors to the Network Coordinator. In any case, the Network Coordinator retains ultimate responsibility for the operation of the network and for the resolution of disputes involving nodes within the network. 1.2.4 Regions and Regional Coordinators A region is a well-defined geographic area containing nodes which may or may not be combined into networks. A typical region will contain many nodes in networks, and a few independent nodes which are not a part of any network. The Regional Coordinator maintains the list of independent nodes in the region and accepts nodelists from the Network Coordinators in the region. These are compiled to create a regional nodelist, which is then sent to the Zone Coordinator. A Regional Coordinator is not required to perform message- forwarding services for any nodes in the region. Regional Coordinators are elected by a majority vote of the NCs in the Region. 1.2.5 Zones and Zone Coordinators A zone is a large geographic area containing many regions, covering one or more countries and/or continents. The Zone Coordinator compiles the nodelists from all of the regions in the zone, and creates the master nodelist and difference file, which is then distributed over FidoNet in the zone. A Zone Coordinator does not perform message-forwarding services for any nodes in the zone although the Zone Coordinator may form and/or administer zone-gates to forward mail between his/her zone and other FidoNet zones and/or networks. Zone Coordinators are elected by a majority vote of the Regional Coordinators in that zone. 1.2.6 Zone Coordinator Council In certain cases, the Zone Coordinators work as a council to provide advice to the International Coordinator. The arrangement is similar to that between a president and advisors. In particular, this council considers inter-zonal issues. This includes, but is not limited to: working out the details of nodelist production, mediating inter-zonal disputes, and coordinating inter- zonal passage of mail. 1.2.7 International Coordinator The International Coordinator is the nominal head of FidoNet. As such, it is the responsibility of the International Coordinator to handle and decide issues which affect the whole of FidoNet. The International Coordinator also acts as the chair of the Zone Coordinator Council and as the overseer of elections -- arranging the announcement of referenda, the collection and counting of the ballots, and announcing the results for those issues that affect FidoNet as a whole. The International Coordinator is elected by a majority vote of the Zone Coordinators. 1.2.8 Top-down and Bottom-up Organization. Checks and Balances. These levels act to distribute the administration and control of FidoNet to the lowest possible level, while still allowing for coordinated action over the entire mail system. Effective technical administration is made possible by operating in a top-down manner. That is, a person at any given level is responsible to the level above for technical operations and responsible to administer the level below. For example, a Regional Coordinator is responsible to the Zone Coordinator for anything that happens in the region. From the point of view of the Zone Coordinator, the Regional Coordinator is completely responsible for the smooth operation of the region. Likewise, from the point of view of the Regional Coordinator, the Network Coordinator is completely responsible for the smooth operation of the network. If a person at any level above sysop is unable to properly perform their duties for any reason, the person at the next level may replace them. For example, if a Regional Coordinator fails to perform, the Zone Coordinator can replace him. All Coordinators may be recalled at any time by a majority vote of the level below. For example, if the Network Coordinators in a region lose faith in the ability of an Regional Coordinator to effectively perform, they may vote to remove the Regional Coordinator and replace him/her. Further, decisions made at any level above the Network Coordinator may be overridden by a majority vote of the level below. This override ability is limited to the level IMMEDIATELY below the original decision-making level. In short, Network Coordinators may not overrule a Regional Coordinator in a matter where the Regional Coordinator is only implementing a decision made by the Zone Coordinator or the International Coordinator. 1.3 Definitions 1.3.1 FidoNews FidoNews is a weekly newsletter distributed in electronic form throughout the network. It is an important medium by which FidoNet sysops communicate with each other. FidoNews provides a sense of being a community of people with common interests. Accordingly, sysops and users are encouraged to contribute to FidoNews. Contributions are submitted to node 1:1/1; a file describing the format to be used is available from 1:1/1 and many other systems. 1.3.2 Geography The FidoNet nodelist is organized on a geographic basis, with zones, regions, and networks each covering a specified, non-overlapping geographic area. (There are never two zones, two regions, or two networks which cover the same geographic area.) Nodes are listed within this geographic framework based on the geographic location of that system. Geographic boundaries are based on the geographical organization of the telephone system(s) in that area. In this way, the geographically-based nodelist serves as an "address book" for FidoNet, revealing by its structure the location of individual systems. Network boundries are determined by the boundries of local (free, where possible) calling areas. A system which is a local call to a Network Coordinator or a Hub Coordinator of a network will be listed in that network. If there is no Network Coordinator or Hub Coordinator system accessible by a local call to a system, the system is considered to be outside of the formal boundries of that network. In this case, the node will be treated as a Regional Independant. There are three major types of telephone cost structures. First, there is the local-call area. This is defined by an area in which all calls made within are free. If an area like this exists, the network boundries will be set along the local-calling lines. The second is the "ringed" system, usually used in large cities, wherein calls are charged according to the distance across the city they cover. In most cases, these areas may still grant local-call access to all members in the area through the careful placement and organization of Hub Coordinator systems. Therefore, network boundries in "ringed" areas will be set according to the coverage of any Hub system. The third, and most difficult, is the "metered" system, in which ALL calls are charged a rate per-mile of the call. In these cases, no local-call access is possible (since all calls cost money) and network boundries will be set according to the best judgement of the Regional Coordinator. The geographic structure of the nodelist dictates where a node will be listed. For example, a node within the geographic area of a network will be listed in that network. However, the geographic structure of the nodelist does NOT dictate in-practice routing of mail, except in some cases of inbound host-routed mail. In practice, nodes who do not wish to receive their mail through FidoNet's geographically-based distribution systems may receive mail via the most financially and personally convenient routing. For example, a node which does not wish to receive mail through its geographic host may, without changing or eliminating its geography-based node listing, operate a parallel point system off of a distant network and receive mail and even FidoNet distribution files (FidoNews and nodelist difference files) from that source. Such a node should, however, make minimal arrangements to receive inbound host-routed mail to the sysop's geographic address (for example, set up to poll the NC once a week). Nodes which are outside of the formal (local call) boundries of a network are considered, by default, to be Regional Independants. To minimize the load on the Regional Coordinator systems and the financial burden on the Regional Independant nodes, Regional Independants are allowed to join any network in the region which will have them. Regional Independants which thus join a long-distance network are treated from that point onward as if they lived in the geographic coverage of the network they have joined. Regional Independants which join long-distance networks may not change networks at a later time, nor may they revert to Regional Independant status. FidoNet geographic policy is not completely rigid. Nodes with special technical conditions (such as unusually high amounts of host-routed mail) may, with the approval of the Regional Coordinator, be listed as Regional Independants. 1.3.3 Zone Mail Hour Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are required to be able to accept netmail. Each Fidonet zone defines a ZMH and publishes the time of its ZMH to all other Fidonet zones. See sections 2.1.8 and 10.2. Zone Mail Hour has previously been referred to as National Mail Hour and Network Mail hour. The term Zone Mail Hour is more accurate. 1.3.4 Nodelist The nodelist is a file updated weekly which contains the addresses of all recognized FidoNet nodes. This file is currently made available by the Zone Coordinator not later than Zone Mail Hour each Saturday, and is available electronically for download or file request at no charge. To be included in the nodelist, a system must meet the requirements defined by this document. No other requirements may be imposed. Partial nodelists (single-zone, for example) may be made available at different levels in FidoNet. The full list as published by the International Coordinator is regarded as the official FidoNet nodelist, and is used in circumstances such as determination of eligibility for voting. All parts that make up the full nodelist are available on each Zone Coordinator's and each Regional Coordinator's system. 1.3.5 Excessively Annoying Behavior There are references throughout this policy to "excessively annoying behav- ior", especially in section 9 (Resolution of Disputes). It is difficult to define this term, as it is based upon the judgement 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 FidoNet. It is a rare sysop who, at some point in this journey, does not manage to annoy others. Only when such behavior is both legitimately annoying and persistent despite good- faith attempts to unofficially solve or mediate the problem does it become excessively annoying and worthy of a formal policy complaint. This does not imply that it is not possible to be excessively annoying without repetition (for example, election fraud would likely be excessively annoying on the very first try), but simply illustrates that a great deal of tolerance is extended to account for varying personalities, etc. Refer to section 9 and the case studies (section 10.3) for more information. 1.3.6 Commercial Use FidoNet is an amateur network. Participants spend their own time and money to make it work for the good of all the users. It is not appropriate for a commercial enterprise to take advantage of these volunteer efforts to further their own business interests. On the other hand, FidoNet provides a convenient and effective means for companies and users to exchange informa- tion, to the mutual benefit of all. Network Coordinators could be forced to subsidize commercial operations by forwarding host-routed netmail, and could even find themselves involved in a lawsuit if any guarantee was suggested for mail delivery. It is therefore FidoNet policy that commercial mail is not to be routed. "Commercial mail" includes mail which furthers specific business interests without being of benefit to the net as a whole. Examples include company-internal mail, inter-corporate mail, specific product inquiries (price quotes, for in- stance), orders and their follow-ups, and all other subjects specifically related to business. 2 Sysop Procedures 2.1 General 2.1.1 The Basics 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 FidoNet, and do not promote or participate in the distribution of pirated copyrighted software or other illegal behavior via FidoNet. 2.1.2 Familiarity with Policy In order to understand the meaning of "excessively annoying", it is incumbent upon all sysops to occasionally re-read FidoNet policy. New sysops must familiarize themselves with policy before requesting a node number. The most recent policy statement will be made available for file request and download on all Coordinator systems. 2.1.3 Responsible for All Traffic Entering FidoNet Via the Node The sysop listed in the nodelist entry is responsible for all traffic entering FidoNet via that system. This includes (but is not limited to) traffic entered by users, points, and any other networks for which the system might act as a gateway. If a sysop allows "outside" messages to enter FidoNet via the system, the gateway system must be clearly identified by FidoNet node number as the point of origin of that message, and it must act as a gateway in the reverse direction. Should such traffic result in a violation of Policy, the sysop must rectify the situation. 2.1.4 Encryption and Review of Mail FidoNet 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. See section 1.3.6 for a definition of commercial traffic. 2.1.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 FidoNet node to another. 2.1.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. 2.1.6.1 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. This does not apply to echomail which is by definition a broadcast medium and is not covered by this policy, and where private mail is often used to keep a sysop-only area restricted. 2.1.6.2 Private mail addressed to you The issue of private mail which is addressed to you is more difficult than the in-transit question treated in the previous section. 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 FidoNet. This ideal is often compromised, as FidoNet 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. Judgement and common sense should be used in this area as in all other aspects of FidoNet behavior. 2.1.7 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 FidoNet with an explanation of why it was not forwarded. Simply being offended by the content of a message is not a valid reason for refusal to route that message. (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 attempts have been made to unofficially resolve the problem (i.e. offers of technical assistance in resolving the problem.) 2.1.8 Exclusivity of Zone Mail Hour Zone Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication (FTSC-0001 at this writing). It is permissible to have greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTSC-0001 capability during this one hour of the day. This time is exclusively reserved for netmail. Many phone systems charge on a per-call basis, regardless of whether a connect, no connect, or busy signal is encountered. For this reason, any activity other than normal network mail processing that ties up a system during ZMH is considered annoying behavior. Echomail should not be transferred during ZMH. User (BBS) access to a system is prohibited during ZMH. A system which is a member of a local network may also be required to observe additional mail events, as defined by the Network Coordinator. Access restrictions during local network periods are left to the discretion of the Network Coordinator. However, no system shall be required to observe more than two hours of mandatory FidoNet mail hours daily, including ZMH. 2.1.9 Private Nodes The rare exception to ZMH compliance is private nodes. Persons requesting private nodes should be supported as points if possible. A private listing is justified when the system must interface with many others, such as an echomail distributor. In these cases, the exact manner and timing of mail delivery is arranged between the private node and other systems. Such an agreement between a private system and a hub is not binding on any replace- ment for that hub. A private node must be a part of a network (they cannot be independents in the region.) Private listings impact each member of FidoNet, since they take up space in everyone's nodelist. Private listings which are for the convenience of one sysop (at the expense of every other sysop in FidoNet) are a luxury which is no longer possible. Non-essential redundant listings (more than one listing for the same telephone number, except as mandated by FTSC standards or as necessary for administrative purposes, such as administrative node numbers within a zone) also fall into this category. Sysops requesting private or redundant listings must justify them with a statement explaining how they benefit the local net or FidoNet as a whole. The Network Coordinator or Regional Coordinator may review this statement at any time and listings which are not justified may be removed. 2.1.10 Observing Mail Events Failure to observe the proper mail events is grounds for any node to be dropped from FidoNet without notice (since notice is generally given by netmail) provided that notice is, at least, attempted by netmail. 2.1.11 Use of Current Nodelist Network mail systems generally operate unattended, and place calls at odd hours of the night. If a system tries to call an incorrect or out-of-date number, it could cause some poor citizen's phone to ring in the wee hours of the morning, much to the annoyance of innocent bystanders and civil authori- ties. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical. 2.1.12 Excommunication A system which has been dropped from the network is said to be excommunicated (i.e. denied communication). If you find that you have been excommunicated without warning, your coordinator was unable to contact you. You should rectify the problem and contact your coordinator. Systems may also be dropped from the nodelist for cause. See section 10, and sections 4.3 and 5.2. Excommunicated systems may remain as point systems to the extent that their boss nodes will be responsible for their future behavior in accordance with section 2.1.3. If an excommunicated node continues to be annoying, that system may be excommunicated as a point, in which case it may no longer operate as a point system in FidoNet. Further, the boss node may be subject to punitive action as it is responsible for the behavior of its points. Excommunication is the ultimate sanction and should only be used where unofficial resolutions, mediations, and lesser sanctions have failed to reform the annoying behavior. Alternate sanctions may include marking a node as DOWN in the nodelist for a specified time, listing the node in the "doghouse" nodelist, suspension from the nodelist for a specified time, warnings, admonitions, etc. 2.1.13 Timing of Zone Mail Hour The exact timing of Zone Mail Hour for each zone is set by the Zone Coordina- tor. See section 12.2 2.1.14 Non-observance of Daylight Savings Time FidoNet does not observe daylight savings time. FidoNet events are scheduled in Universal Time (also known as Greenwich Mean Time or Zulu time). In areas which observe daylight savings time the FidoNet mail schedules must be adjusted in the same direction as the clock change. Alternatively, you can simply leave your system on standard time or set it to Universal Time. 2.1.15 Compliance with Laws All FidoNet systems will comply with all applicable laws of the locality in which those systems operate. These laws include but are not limited to laws governing the activities of computer users and/or networks, copyright laws, libel laws, sedition laws, and laws protecting individual civil rights. Utilizing FidoNet position or FidoNet structure in the commission of a crime will be grounds for immediate removal from FidoNet position and immediate elimination from FidoNet. 2.2 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. The first step in obtaining a current nodelist is to locate a FidoNet bulletin board. Most bulletin board lists include at least a few FidoNet systems, and usually identify them as such. Use a local source to obtain documents because many networks have detailed information available which explains the coverage area of the network and any special requirements or procedures. Once you have a nodelist, you must determine which network or region covers your area. Regions are numbered 1-99; network numbers are greater than 99. 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. Coordinator systems must have the most recent nodelist, nodediff, and policy as well as any applicable local policies available for user download. Further, Coordinator systems are recommended to allow user download of such documents as FidoNews. Once you have located the network or region in your area, send a message containing a request for a node number to node zero of that network or region. The request must be sent by netmail, as this indicates that your system has FidoNet capability. You must set up your software so that the from-address in your message does not cause problems for the coordinator who receives it. If you pick the address of an existing system, this will cause obvious problems. If your software is capable of using address -1/-1, this is the traditional address used by potential sysops. Otherwise use net/9999 (e.g. if you are applying to net 123, set your system up as 123/9999). Many nets have specific instructions available to potential sysops and these procedures may indicate a preference for the from-address. The message you send must include at least the following information: 1) Your name. 2) Your voice telephone number 3) The name of your system. 4) The city and state where your system is located. 5) The phone number to be used when calling your system. 6) Your hours of operation, netmail and BBS. 7) The maximum baud rate you can support. 8) The type of mailer software and modem you are using. Your coordinator may contact you for additional information. All information submitted will be kept confidential and will not be supplied to anyone except the person who assumes the coordinator position at the resignation of the current coordinator and any applicable Hub Coordinators. By accepting a node number, you indicate that you have read, and agree to abide by, this document and all the current policies of FidoNet. 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 Network Coordinator. 2.3 If You are Going Down If your node will be down for an extended period (more than a day or two), inform your coordinator as soon as possible. It is not your coordinator's responsibility to chase you down for a status report, and if your system stops accepting mail without notice it may be removed from the nodelist. 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. 2.4 How to Form a Network If there are several nodes in your area, but no network, a new network can be formed. This has advantages to both you and to the rest of FidoNet. You receive better availability of nodelist difference files and FidoNews, and everyone else can take advantage of host-routing netmail to the new network. The first step is to contact the other sysops in your area. You must decide which nodes will comprise the network, and which of those nodes you would like to be the Network Coordinator. Then consult your Regional Coordinator. You must send the following information: 1) The region number(s), or network number(s) if a network is splitting up, that are affected by the formation of your network. The Regional Coordinator will inform the Zone Coordinator and the coordinators of any affected networks that a new network is in formation. 2) A copy of the proposed network's nodelist segment. This file should be attached to the message of application for a network number, and should use the nodelist format described in the current version of the appropriate FTSC publication. Please elect a name that relates to your grouping, for example SoCalNet for nodes in the Southern California Area and MassNet West for the Western Massachusetts Area. Remember if you call yourself DOGNET it doesn't identify your area. Granting a network number is not automatic. Even if the request is granted, the network might not be structured exactly as you request. Your Regional Coordinator will review your application and inform you of the decision. Decisions will be made in accordance with telephone system geography (local calling area boundries). Do not send a network number request to the Zone Coordinator. All network number requests must be processed by the Regional Coordinator. 3 General Procedures for All Coordinators 3.1 Make Available Difference Files and FidoNews Any Coordinator is responsible for obtaining and making available for file request, on a weekly basis, nodelist difference files, and FidoNews. Coordinators are also encouraged to make such files available for download by users. 3.2 Processing Nodelist Changes and Passing Them Upstream Each coordinator is responsible for obtaining nodelist information from the level below, processing it, and passing the results to the level above. The timing of this process is determined by the requirements of the level above. 3.3 Ensure the Latest Policy is Available A Coordinator is responsible to make the current version of this document available to the level below, and to encourage familiarity with it. In addition, a coordinator is required to forward any local policies received to the level above, and to review such policies. Although not required, common courtesy dictates that when formulating a local policy, the participa- tion of the level above should be solicited. 3.4 Minimize the Number of Hats Worn Coordinators are encouraged to limit the number of FidoNet-related functions they perform. A coordinator who holds two different positions compromises the appeal process. For example, if the Network Coordinator is also the Regional Coordinator, sysops in that network are denied one level of appeal. As such, Coordinators may not hold two appeal-chain positions. There is one exception. When a coordinator is elected to another coordinator position, that individual may hold both positions until such time as the vacated position may be filled by an election. This interim period may not exceed 45 days in length. Coordinators are discouraged from acting as echomail and software- distribution hubs. If they do so, they should handle echomail (or other volume distribution) on a system other than the administrative system. A coordinator's system should be readily available to the levels immediately above and below. Another reason to discourage multiple hats is the difficulty of replacing services if someone leaves the network. For example, if a coordinator is the echomail hub and the software-distribution hub, those services will be difficult to restore when that person resigns. 3.5 Be a Member of the Area Administered A coordinator must be a member of the area administered. That is, a Network Coordinator must be a member of that network by virtue of geography. When a network is formed, the local-call geographic boundries are defined first, then a Network Coordinator is elected from the nodes in that local call area. A Regional Coordinator must be either a member of a network in the region, or an independent in the region. 3.6 Encourage New Sysops to Enter FidoNet A coordinator is encouraged to operate a public bulletin board system which is freely available for the purpose of distributing Policy, FidoNews, and Nodelists to potential new sysops. Dissemination of this information to persons who are potential FidoNet sysops is important to the growth of FidoNet, and coordinators should encourage development of new systems. 3.7 Tradition and Precedent A coordinator is not bound by the practices of predecessor or peers beyond the scope of this document. However, it must be made clear that coordinators are bound by all requirements of this document, both as FidoNet sysops and as Coordinators. The holding of a Coordinator title does not grant licence to annoy others or to flaunt policy. In addition, a new coordinator has the right to review any decision made by predecessors for compliance with Policy, and take whatever actions may be necessary to rectify any situations not in compliance, provided that such action does not unduly inconvenience FidoNet members (i.e. a new requirement to abruptly abolish all private node listings regardless of justifications) and is not retributive in nature. When a new version of Policy is adopted, decisions made under previous policies are not subject to mandatory review or retrial under the new policy unless specifically provided for in the new policy. 3.8 Technical Management The primary responsibility of any coordinator is technical management of network operations. Decisions must be made on technical grounds. Personalities and personal preferences of "the way things SHOULD be run" have no place in official Coordinator actions. 4 Network Coordinator Procedures 4.1 Responsibilities A Network Coordinator has the following responsibilities: 1) To receive incoming mail for nodes in the network, and arrange delivery to or pickup by its recipients. 2) To assign node numbers to nodes in the network. 3) To maintain the nodelist for the network, and to send a copy of it to the Regional Coordinator whenever it changes. 4) To make available to nodes in the network new nodelist difference files, new issues of FidoNews, and new revisions of network policy documents as they are received, and to periodically check to insure that nodes use up to date nodelists. 4.2 Routing Inbound Mail It is your responsibility as Network Coordinator to coordinate the receipt and forwarding of host-routed inbound netmail for nodes in your network. The best way to accomplish this is left to your discretion. If a node in your network is receiving large volumes of mail you can request that the sysop contact the systems which are sending this mail and request that they not host-route it. If the problem persists, you can request your Regional Coordinator to assign the node a number as an independent and/or drop the system from your network. Occasionally a node will make a "bombing run" (sending one message to a great many nodes). If a node in another network is making bombing runs on your nodes and routing them through your inbound host, then you can complain to the network coordinator of the offending node. (If the node is an indepen- dent, complain to the regional coordinator.) Host-routed bombing runs are considered to be annoying. You are not required to forward encrypted, commercial, or illegal mail. However, you must follow the procedures described in section 2.1.7 if you do not forward the mail. 4.3 Assigning Node Numbers It is your responsibility to assign node numbers to new nodes in your net- work. You may also change the numbers of existing nodes in your network, though you should check with your member nodes before doing so. You may assign any numbers you wish, so long as each node has a unique number within your network. You must not assign a node number to any system until you have received a formal request from that system by FidoNet mail. This will ensure that the system is minimally operational. The strict maintenance of this policy has been one of the great strengths of FidoNet. It is also recommended, though not required, that you call a board which is applying for a node number before assigning it a node number. You may not assign a node number to a node in an area covered by an existing network (other than, of course, your own). Further, if you have nodes in an area covered by a network in formation, those nodes must be transferred to the new network. Long-distance nodes are allowable so long as they are in your region and are not in another network's local calling area. Further exceptions to geographic restrictions may be granted by the Regional Coordinator. You 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. If a node in your network is acting in an excessively annoying manner, then you can take whatever action you deem fit, according to the circumstances of the case and according to section 10 of this policy. 4.4 Maintaining the Nodelist You should implement name changes, phone number changes, and so forth in your segment of the nodelist as soon as possible after the information is received from the affected node. You should also on occasion send a message to every node in your network to ensure that they are operational. If a node turns out to be "off the air" with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to be marked DOWN for a maximum of two weeks, after which the line should be removed from the node- list.) At your discretion, you may distribute a portion of this workload to routing hubs. In this case, you should receive the nodelists from the Hub Coordina- tors within your network. You will need to maintain a set of nodelists for each hub within your network, since you cannot count on getting an update from each Hub Coordinator every week. You should assemble a master nodelist for your network every week and send it to your Regional Coordinator by the day and time designated. It is suggested that you do this as late as is practical, so as to accommodate any late changes, balanced with the risk of missing the connection with your Regional Coordinator and thus losing a week. 4.5 Making Available Policies, Nodelists and FidoNews As a Network Coordinator you should obtain a new issue of FidoNews and a new nodelist difference file every week from your Regional Coordinator. The nodelist difference file is currently made available each Saturday, and FidoNews is published each Monday. You must make these files available to all nodes in the network, and you are encouraged to make them available to the general public for download. You should also obtain the most recent versions of the Policy documents that bind the members of your network, and make those available to the nodes in your network. Policies are released at sporadic intervals, so you should also inform the nodes in your network when such events occur, and ensure the nodes are generally familiar with the changes and that they are informed of any upcoming referenda. Policy, FidoNews, and the nodelist 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. 5 Regional Coordinator Procedures 5.1 Responsibilities A Regional Coordinator has the following responsibilities: 1) To assign node numbers to independent nodes in the region. 2) To encourage independent nodes in the region to join existing net- works, or to form new networks. 3) To assign network numbers to networks in the region and define their boundaries in accordance with local-call telephone system boundries. 4) To compile a nodelist of all of the networks and independents in the region, and to send a copy of it to the Zone Coordinator whenever it changes. 5) To ensure the smooth operation of networks within the region. 6) To make new nodelist difference files, Policies, and issues of FidoNews available to the Network Coordinators in the region as soon as is practical. 5.2 Assigning Node Numbers It is your responsibility to assign node numbers to independent nodes in your region. You may also change the numbers of existing nodes in your region, though you should check with the respective nodes before doing so. You may assign any numbers you wish, so long as each node has a unique number within your region. You should not assign a node number to any system until you have received a formal request from that system by FidoNet mail. This will ensure that the system is minimally operational. The strict maintenance of this policy has been one of the great strengths of FidoNet. It is also recommended, though not required, that you call a board which is applying for a node number before assigning it a node number. You 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. If an independent node in your region is acting in an excessively annoying manner, then you can take whatever action you deem fit, according to the circumstances of the case and according to section 10 of this policy. If you receive a node number request from outside your region, you must forward it to the most local coordinator for the requestor as you can deter- mine. If you receive a node number request from a new node that is in an area covered by an existing network, then you must forward the request to the Coordinator of that network instead of assigning a number yourself. If a network forms in an area for which you have independent nodes, those nodes will be transferred to the local network as soon as is practical. 5.3 Encouraging the Formation and Growth of Networks One of your main duties as a Regional Coordinator is to promote the growth of networks in your region. You should avoid having independent nodes in your region which are within the coverage area of a network. There are, however, certain cases where a node should not be a member of a network, such as a system with a large amount of inbound netmail; see section 4.2. If several independent nodes in your region are in a local area you should encourage them to form a network, and if necessary you may require them to form a network. Refer to section 2.4. Note that this is not intended to encourage the formation of trivial networks. Obviously, one node does not make a network. The exact number of nodes required for an effective network must be judged according to the circumstances of the situation, and is left to your discretion. 5.4 Assigning Network Numbers It is your responsibility to assign network numbers to new networks forming within your region. You are assigned a pool of network numbers to use for this purpose by your Zone Coordinator. As a part of this function, it is the responsibility of the Regional Coordinator to define the boundaries of the networks in the region. Telephone (local-call) geography should be the overriding factor in the setting of network boundaries. For example, network boundries should, in no case, require nodes to join the network which will have to call long-distance for their mail within that network. 5.5 Maintaining the Nodelist As a Regional Coordinator, you have a dual role in maintaining the nodelist for your region. First, you must maintain the list of independent nodes in your region. You should attempt to implement name changes, phone number changes, and so forth in this nodelist as soon as possible. You should also on occasion send a message to every independent node in your region to ensure that they are operational. If a node turns out to be "off the air" with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to marked DOWN for a maximum of two weeks, after which the line should be removed from the nodelist.) Second, you must receive the nodelists from the Network Coordinators within your region. You will need to maintain a set of nodelists for each network within your region, since you cannot count on getting an update from each Network Coordinator every week. You should assemble a master nodelist for your region every week and send it to your Zone Coordinator by the day and time designated. It is suggested that you do this as late as practical, so as to accommodate late changes, balanced with the risk of missing the connec- tion with your Zone Coordinator and thus losing a week. 5.6 Geographic Exemptions There are cases where local calling geography does not follow FidoNet re- gions. In such cases, the node will be listed in the most financially convenient network and/or region. Such an exemption is not a right, and is not permanent. When a network is formed in the proper region that would provide local calling access to the exempted node, it is no longer exempt. An exemption may be reviewed and revoked at any time by the Zone Coordinator. 5.7 Overseeing Network Operations It is your responsibility as Regional Coordinator to ensure that the networks within your region are operating in an acceptable manner. This does not mean that you have the right to interfere in those networks, that is the domain of the Network Coordinators. It means that you are responsible for assuring that the Network Coordinators within your region are acting responsibly and according to policy. If you find that a Network Coordinator within your region is not properly performing the duties outlined in Section 4, you should take whatever action you deem necessary to correct the situation. Generally, a Regional Coordinator may not intervene in affairs regarding nodes within networks without the express request of the Network Coordinator or the node as part of an appeal. If a network grows so large that it cannot reasonably accommodate traffic flow during the Zone Mail Hour, the Regional Coordinator can direct the creation of one or more new networks from that network. These new networks, although they may be within a single local-calling area, must still conform to a geographical basis for determining membership. The formation of Hub Coordinator systems within large networks should be encouraged in order to prevent overload problems. It is also the responsibility of the Regional Coordinator to ensure that network boundries are set, insomuch as is possible, along local-calling lines. Where free-call or reduced-rate/flat-charge areas exist, network boundries should be set along those lines. Where there are "ringed" systems (usually in large cities) where a properly-structured network can offer local-call Hubs to all systems, the Regional Coordinator should ensure that such networks are appropriately structured for efficient coverage. Where there are "metered" systems in which all calls are charged variable rates according to distance called, network boundries should be set as is dictated by local circumstances. It is your obligation as Regional Coordinator to maintain direct and reason- ably frequent contact with the networks in your region. The exact method of accomplishing this is left to your discretion. 5.8 Making Available Nodelists, Policies, and FidoNews As a Regional Coordinator, it is your responsibility to obtain the latest nodelist difference file, network policies, whole nodelist and the latest issues of FidoNews as they are published, and to make them available to the Network Coordinators and nodes within your region. The nodelist is posted weekly on Saturday by the Zone Coordinator, and FidoNews is published weekly on Monday by node 1/1. Contact them for more details on how to obtain the latest copies each week. It is your responsibility to make these available to all Network Coordina- tors in your region as soon as is practical after you receive them. The method of distribution is left to your discretion. You are not required to distribute them to any independent nodes in your region, though you may if you wish. You are encouraged to make all these documents available for downloading by the general public. 6 Zone Coordinator Procedures 6.1 General A Zone Coordinator for FidoNet has the primary task of maintaining the nodelist for the Zone, sharing it with the other Zone Coordinators, and ensuring the distribution of the master nodelist (or difference file) to the Regions in the Zone. The Zone Coordinator is also responsible for coordinat- ing the distribution of Network Policy documents and FidoNews to the Regional Coordinators in the zone. The Zone Coordinator is responsible for the maintenance of the nodelist for the administrative region. The Administrative Region has the same number as the zone, and consists of nodes assigned for administrative purposes not related to the sending and receiving of normal network mail. A Zone Coordinator is charged with the task of ensuring the smooth operation of the Zone, which is done by supervising the Regional Coordi-nators. A Zone Coordinator does not have the right to interfere in affairs regarding nodes within networks or listed as independants within a region without the express request of the appropriate Coordinator or the node as part of an appeal. If a Zone Coordinator determines that a Regional Coordinator is not properly performing the duties outlined in section 5, a replacement should be found. The Zone Coordinator defines the geographic boundaries of the regions within the zone and sets the time for the Zone Mail Hour. The Zone Coordinator is responsible for reviewing any geographic exemptions as described in section 5.6. The Zone Coordinator is responsible for insuring the smooth operation of gates between that zone and all other zones for the transfer of interzonal mail. 6.2 Selection The Zone Coordinator is selected by a majority vote of the Regional Coordinators within the zone. 7 International Coordinator Procedures 7.1 General The International Coordinator has the primary task of coordinating the creation of the master nodelist by managing the distribution between the Zones of the Zone nodelists. The International Coordinator is responsible for definition of new zones and for negotiation of agreements for communica- tion with other networks. ("Other network" in this context means other networks with which FidoNet communicates as peer-to-peer, not "network" in the sense of the FidoNet organizational level.) The International Coordinator is also responsible to act as the representative of FidoNet to outside entities, such as governments or corporations. The International Coordinator is also responsible for coordinating the distribution of Network Policies and FidoNews to the Zone Coordinators. The International Coordinator is responsible for coordinating the activities of the Zone Coordinator Council. The International Coordinator acts as the spokesman for the Zone Coordinator Council. Like lower Coordinators, the International Coordinator does not have the right to interfere in lower-level affairs without the specific request of the Zone Coordinator and any applicable levels below that. 7.2 Selection The International Coordinator is selected by a majority vote of the Zone Coordinators. 8 Referenda The procedures described in this section are used to ratify a new version of FidoNet policy, which is the mechanism by which policy is changed. 8.1 Initiation A referendum on policy modification is invoked when a third of the FidoNet Regional Coordinators inform the International Coordinator that their region wishes to consider a proposed new version of Policy. A Regional Coordinator must make this request upon receiving a request to consider a new version of policy from one-third of the Network Coordinators in the region or from one- third of the nodes in the region within a three-month period. A Regional Coordinator may not make such a request until receiving a request from the required number of nodes or Network Coordinators. 8.2 Announcement of Proposed Policy Proposed changes to Policy are distributed using the same structure which is used to distribute nodelist difference files and FidoNews. Results and announcements related to the referendum are distributed by the coordinator structure as a part of the weekly nodelist difference file. The Interna- tional Coordinator provides copies to the editor of FidoNews for inclusion there, although the official announcement and voting dates are tied to nodelist distributions. If it is adopted, the International Coordinator sets the effective date for a new policy through announcement in the weekly nodelist difference file. The effective date will be not more than one month after the close of balloting. 8.3 Eligibility to Vote Eligibility to vote will be determined by the most recent nodelist at the opening of balloting. Any system listed within that nodelist as a publicly available system (published phone number, not a PVT node) is entitled to one vote. In cases where an individual holds multiple node numbers, that individual will be entitled to one vote only. (* Comment: Let's get on the software writers, especially those familiar with parsing nodelists, to get us a quick-and-dirty utility which can process the nodelist and get us a list of all the names in a specified area while parsing each name down to a single listing. Specifically, get a list of eligible voters out of the nodelist without including multiple listings for those individuals who run more than one system. *) 8.4 Voting Mechanism Procedures relevant to all elections are specified in Appendix 12.5 -- Election Policy. Priorities in further development of election procedures should be security, simplicity, and fairness. 8.5 Voting on a whole Policy Document Given that Policy is intertwined and self-referencing, a relatively simple change may require several alterations of the document. In order to simplify the process, balloting is done on choices between whole documents, rather than individual amendments. In the simplest case, this means voting yea or nay to a new document. If a number of alternatives are to be considered, they must be presented as whole documents, from which one is chosen. 8.6 Decision of vote A Policy is considered in force if, at the end of the balloting period, it has received a majority of the votes cast. For example, if there were 3500 eligible voters, 2100 of which cast a vote, then at least 1051 affirmative votes would be required to declare the policy in force. In the case of multiple policy changes which are considered on the same ballot, each version will be voted on separately. A version must receive over 50% of the votes cast to be considered ratified. Voters may vote yes on more than one policy in such an election. If more than one version garners more than 50% of the vote, the highest vote-getting version will be the one considered ratified. If there is a tie, the Zone Coordinator Council will choose the "ratified" version by vote. 9 Elections of Coordinators Each Coordinator level is elected by the level below (the nodes elect the Network Coordinator. The Network Coordinators elect the Regional Coordinator, etc) 9.1 Eligibility to Vote Eligibility to vote will be determined by the most recent nodelist at the opening of balloting. Any system listed within that nodelist as a publicly available system (published phone number, not a PVT node) is entitled to one vote. In cases where an individual has more than one listing, that individual is only entitled to one vote. 9.2 Conducting Elections Procedures relevant to all elections are specified in Appendix 12.5 -- Election Policy. Priorities in further development of election procedures should be security, simplicity, and fairness. 9.3 Term Limit No Coordinator shall serve a term of more than two years without facing election. There is no limit to the number of total or consecutive terms a Coordinator may serve. 9.3 Recall of Coordinators At any time, a coordinator may be removed by a majority vote of the level below. In such a case, the level above will immediately administer an election to re-fill the position vacated by recall. The removal of a Coordinator is primarily intended to be a mechanism by which the level below expresses displeasure with the way Policy is being interpreted. At one time or another, everyone is unhappy with the way policy is interpreted. In order to keep the Coordinators interpreting policy as opposed to defending themselves, at least one full calendar year must elapse between recalls of a given position. Such "recall" elections may be initiated by the level above or the level below. The level above should initiate such an election if, in their opinion, there is evidence to suggest that the coordinator below may not have the support of those served. The level above is also required to call such a recall election upon receipt of requests for recall from 1/3 of the level below within a three month period. Unneccesarily repetitive or frivolent calls for a recall is annoying behavior as a recall (or calls for one) disrupts the normal flow of FidoNet business. Should a Coordinator resign during an impeachment process, the process is considered null and void, and does not consume the "once per year quota". 10 Resolution of Disputes 10.1 General The FidoNet judicial philosophy can be summed up in two rules: 1) Thou shalt not excessively annoy others. 2) Thou shalt not become excessively annoyed. In other words, there are no hard and fast rules of conduct, but reasonably polite behavior is expected on both sides. Also, in any dispute both sides are examined, as both likely violated at least one rule, and action could be taken against either or both parties. ("Judge not, lest ye be judged!") The coordinator structure has the responsibility for defining "excessively annoying". Like a common definition of pornography ("I can't define it, but I know it when I see it."), a hard and fast definition of acceptable FidoNet behavior is not possible. The guidelines in this policy are deliberately vague to provide the freedom that the coordinator structure requires to respond to the needs of a growing and changing community. The first step in any dispute between sysops is for the sysops to attempt to communicate directly, at least by netmail, preferably by voice. Any com- plaint made that has skipped this most basic communication step will be rejected. The second step in any dispute is mediation. Both sides should first attempt to agree on an independent person acceptable to both. In the absence of agreement, the dispute should be taken to the Regional Mediator in the region of the node accused of annoying behavior. The Regional Mediator or independent (mutual agreement) mediator will attempt to informally mediate the dispute in accordance with section 10.4. Filing a formal complaint is not an action which should be taken lightly. Investigation and response to complaints requires time which coordinators would prefer to spend doing more constructive activities. Persons who persist in filing trivial policy complaints may find themselves on the wrong side of an excessively-annoying complaint. Complaints must be accompanied with verifiable evidence, generally copies of messages; a simple word-of- mouth complaint will be dismissed out of hand. Failure to follow the procedures herein described (in particular, by skipping a coordinator or mediator, or involving an individual not in the appeal chain) is in and of itself annoying behavior. 10.2 Problems with Another Sysop If you are having problems with another sysop, you should first try to work it out via netmail or voice conversation with the other sysop. You should not expect any positive reaction to a policy complaint or a request for mediation if you have skipped this basic step. If this fails to resolve the problem, you should obtain mediation in accordance with section 10.4. If this fails, complain to the offending sysop's Network Coordinator. If the offending node is not in a network, then complain to the appropriate Regional Coordinator. Should this fail to provide satisfaction, you have the right to follow the appeal process described in section 10.5. 10.3 Problems with Coordinators Complaints concerning annoying behavior on the part of any coordinator are treated as in section 10.2 and should be filed with the next level of coordi- nator after mediation. For example, if you feel that your Regional Coordinator is guilty of annoying behavior (as opposed to a failure to perform duties as a coordinator) you should file your complaint with the Zone Coordinator. Complaints concerning the performance of a coordinator in carrying out the duties mandated by policy are accepted only from the level immediately below. For example, complaints concerning the performance of Regional Coordinators would be accepted from Network Coordinators and independents in that region. Such complaints should be addressed to the Zone Coordinator after an appro- priate attempt to work them out by direct communications. 10.4 The Regional Mediator (RM) The RM is not a coordinator and therefore has a distinct set of duties and responsibilities geared towards his/her political rather than technical role. 10.4.1 Selection The Regional Mediator shall be elected by a raw vote of the members in his/her region for a two-year term. In the RM election, the Network Coordinators shall report the raw results of the vote within their net to the RC of the region for tabulation. Those numerical results shall be totalled and a winner publicly announced. 10.4.2 Duties and Authorities The Regional Mediator is the position behind the goals in resolution of disputes. Ideally, there should be no formal policy complaints, therefore the RM is structured to "informalize" the resolution of disputes. Further, if a complaint does become formal, ideally, the problem would be resolved without harm to anyone and without undue emotionalism. The Regional Mediator shall be available for mediation and arbitration of disputes in an informal manner. In these cases, the RM shall attempt to bring both parties to mutually acceptable terms. Should a mediation fail and a complaint result, the RM shall provide the NCs of both parties (or the RC of an NC if the NC is a party) a copy of the messages exchanged to that point and a report regarding the behavior of the two parties (i.e. are they being excessively annoying or becoming excessively annoyed). If, in any case, a complaint is brought to the RM which involves the RM as complaint-filer or defendant or which involves a FidoNet member who is a personal friend (or enemy) of the RM, the Regional Coordinator shall appoint an interim mediator who shall administer that individual case as RM. The Regional Coordinator shall have the authority to determine when such a "conflict of interest" exists. The Regional Mediator will also act as an advisor to the coordinator structure. As the RM is a region-level official elected directly by the sysops, the RM is useful as a reasonably direct representative of the sysops within a region to the higher levels of FidoNet. 10.4.3 Accountability The RM is accountable to the nodes in his/her region. If, at any time, the Regional Coordinator receives a request to recall the RM from 1/3 of the nodes in the region within a three-month period, the RC shall immediately inform the Network Coordinators in the region and a recall election shall be held. 10.5 Appeal Process A decision made by a Coordinator may be appealed to the next coordinator level. It may also be overridden by the level below above the level of Network Coordinator. Appeals must be made within two weeks of the decision which is being appealed. An appeal will not result in a full investigation, but will be based upon the documentation supplied by the Network Coordinator and the records of previous mediation(s). For example, an appeal of a Network Coordinator's decision will be decided by the Regional Coordinator based upon information provided by the coordinator, the Regional Mediator, and the sysop involved; the Regional Coordinator is not expected to make an independent attempt to gather further information. Network Coordinator decisions may be appealed to the appropriate Regional Coordinator. The Regional Coordinator will make a decision and communicate it to the Network Coordinators in that region. This decision may be reversed by a majority vote of the Network Coordinators in that region. Regional Coordinator decisions may be appealed to the appropriate Zone Coordinator. At this point, the Zone Coordinator will make a decision and communicate it to the Regional Coordinators in that zone. This decision may be reversed by a majority vote of the Regional Coordinators in that zone. Zone Coordinator decisions may be appealed to the International Coordinator. The International Coordinator will make a decision and communicate it to the Zone Coordinator Council, which may reverse it by majority vote. 10.6 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. An exception to this rule is cases involving a pattern of infractions extending over an extended period of time. 10.7 Right to a Speedy Decision A coordinator (or mediator in an appeal) is required to render a final decision and notify the parties involved within 30 days of the receipt of the complaint or appeal. 10.8 Return to Original Network Once a policy dispute is resolved, any nodes reinstated on appeal are re- turned to the local network or region to which they geographically or technically belong. 10.9 Case Histories Most of FidoNet Policy is interpretive in nature. No one can see what is to come in our rapidly changing environment. Policy itself is only a part of what is used as the ground rules for mediating disputes -- as or more impor- tant are the precedents. In order to accommodate this process, case histories may be added to or removed from this document by the International Coordinator, with such a revision subject to reversal by the Zone Coordinator Council. Should Policy be amended in such a way to invalidate a precedent, Policy supersedes said precedent. (A carefully prepared amendment would address this by removing the precedent reference as a part of the amendment.) Although a case may be removed, the text of a case history may not be modi- fied by any mechanism. Case history is written close to the time of the decision, by those involved with it. Amending the text of a case history is the same as revising history, something quite inappropriate in an organiza- tion dedicated to moving information. 11.0 Echomail Echomail distribution within FidoNet is administered by the FidoNet Echomail Coordinator structure. As echomail is a different flavor of netmail with different technical and social requirements, it is administered separately from FidoNet Policy in Echomail Policy (EchoPol). This EchoPol is administered by the Echomail Coordinator structure. While EchoPol may rely in part on the FidoNet Coordinator structure for ultimate enforcement authority, echomail structures have separate structures available for enforcement which should be utilized prior to placing an echomail problem within the jurisdiction of FidoNet. In the absence of an in-force EchoPol, FidoNet members are not subject to punitive action under this policy for behaviors related _exclusively_ to echomail unless those behaviors are also in violation of FidoNet Policy. for example, an echomail complaint based on "flaming" (publicly insulting behavior) is not actionable under this policy as it deals exclusively with echomail. Situations which are considered "exclusively echomail" include echomail link policies, moderator authorities, echomail fees, echomail- specific social standards (such as "flaiming"), and echomail duplicates. However, an individual posting credit card numbers in echomail would be punishable under this policy as it would violate section 2.1.15 "Compliance with Laws" in FidoNet Policy. Similarly, an individual cross-posting netmail into echomail may be in violation of section 2.1.6. Such cases, which may violate BOTH echomail standards and FidoNet policy, are still actionable within FidoNet channels. In general, until such time as specific rules and specific procedures are outlined in an in-force EchoPol, the FidoNet Coordinator structure should have only peripheral involvement in echomail affairs. "Minimal contact" is a good rule of thumb. 12 Appendices 12.1 General The Appendices of this document are exceptions to the normal ratification process. Section 12.2 can be changed by the appropriate Zone Coordinator, and section 12.3 may be modified by the International Coordinator (see Section 10.9). Section 12.5 is changed only by a direct ratification as if it were a separate policy. However, Section 12.5 may be changed separately from the rest of the Policy document. In short, it is not necessary to vote on an entire new policy in order to make changes in the election procedures. 12.2 Timing of Zone Mail Hour Zone Mail Hour is observed each day, including weekends and holidays. The time is based upon Universal Coordinated Time (UTC), also known as Greenwich Mean time (GMT). In areas which observe Daylight Savings Time during part of the year, the local time of zone mail hour will change because FidoNet does not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set for each zone by the Zone Coordinator. In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC. In each of the time zones, this is: Eastern Standard Time 4 AM to 5 AM Central Standard Time 3 AM to 4 AM Mountain Standard Time 2 AM to 3 AM Pacific Standard Time 1 AM to 2 AM Hawaii Standard Time 11 PM to Midnight In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC. In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC. In each of the time Zones involved this is: GMT +12 Zone 6:00 AM to 7:00 AM (New Zealand) GMT +10 Zone 4:00 AM to 5:00 AM (East Australia) (Papua New Guinea) (Micronesia) GMT +9.5 Zone 3:30 AM to 4:30 AM (Central Australia) GMT +9 Zone 3:00 AM to 4:00 AM (Japan) (Korea) (Eastern Indonesia) GMT +8 Zone 2:00 AM to 3:00 AM (Hong Kong) (Taiwan) (Central Indonesia) (Philippines) GMT +7 Zone 1:00 AM to 2:00 AM (Malaysia) (Singapore) (Thailand) (Western Australia) (Western Indonesia) 12.3 Case Histories Case histories of past disputes are instructive to show general procedures and methods. Any decision may be included in this document by a majority vote of either the Zone Coordinator Council or the Regional Coordinators. Policy4 significantly changed the functions of the Zone and International Coordinators. In the following cases which were decided using Policy3, substitute "Zone Coordinator" for all occurrences of "International Coordina- tor(*)". 12.3.1 The Case of the Crooked Node A sysop of a local node was using network mail to engage in unethical busi- ness practices. The Network Coordinator became very annoyed at this, and dropped the local from the nodelist. The local appealed to the Regional Coordinator for assignment as an indepen- dent node. The Regional Coordinator, after checking with the Network Coordi- nator, decided that the Network Coordinator was right to be annoyed. Inde- pendent status was denied. The International Coordinator(*) did not intervene. 12.3.2 The Case of the Hacker Mailer A sysop of a local node made use of file attaches for extra users to mail himself the USER.BBS file from several local boards. The sysops of these boards felt annoyed at this, and appealed to their Network Coordinator, who agreed and dropped the offending node from the nodelist. The Regional Coordinator was not consulted. The International Coordinator(*) did not intervene. 12.3.3 The Case of the Bothered Barker A local node became annoyed with the Network Coordinator for failing to provide services. Repeated complaints to the Network Coordinator did not satisfy him, so he appealed to the International Coordinator(*). The International Coordinator(*) dismissed the complaint because the Regional Coordinator had not been consulted. The local node submitted the complaint to his Regional Coordinator, who investigated the case and discovered that there was some justice to the complaint. He advised and assisted the Network Coordinator in configuring his system to provide an improved level of service to the local nodes. The Regional Coordinator also decided that the local node was being too easily annoyed, in that he was expecting services not normally required of a Network Coordinator. The local node was informed as to the true duties of a Network Coordinator, and was advised to lower his expectations. 12.3.4 The Case of the Busy Beaver A local node which was operated by a retail establishment was engaged in making "bombing runs" to mail advertisements over FidoNet. The Network Coordinator felt annoyed and handling the outgoing traffic for a commercial operation, and asked the local node to leave the network. The local node applied to the Regional Coordinator, and was granted status as an independent node in the region. 12.3.5 The Mark of the Devil A local sysop whose board was used in conjunction with voodoo rites, hacking, phreaking, and obscene material applied to a Network Coordinator for a node number. The Network Coordinator deemed that this board was exceptionally annoying, and denied the request. The Regional Coordinator was not consulted. The International Coordinator(*), on seeing that the Regional Coordinator had not been consulted, dismissed the case out of hand. No further appeals were made. 12.3.6 The Case of the Sysop Twit A patron of various local nodes had been roundly recognized by all sysops as a twit. The user obtained his own system, became a sysop, and applied for a node number. The Network Coordinator denied the request. No appeals were made. 12.3.7 The Case of the Bouncing Board A local user decided to establish a node to promote a worthy charity. The machine being used was also used for various other activities during the day, and the sysop was often called away. His coworkers would often forget to bring the board up at the end of the day while he was away, so the node was often down for extended periods. The Network Coordinator, finding the node unable to receive mail, would mark it down. The sysop would return, restart the board, and ask to be reinstated. The Network Coordinator eventually decided that the sysop was not able to maintain a reliable system, and removed him from the nodelist completely. Subsequent requests for a node number from the same sysop were turned down. No appeals were made. 12.4 Implementation of Policy 5 Upon approval of this document by the RCs in accordance with Policy 4, all current coordinators will be "grandfathered" into their current positions. All current coordinators will then be subject to the two-year limit on terms before facing election. It is recommended that, where convenient and/or necessary, current coordinators be subject to a "vote of confidence" by the level below. Elections for Regional Mediators will be held no later than three months after the approval of this policy. No recall elections shall be allowed for three months following approval of this policy to allow for a "cooling-off" period. To enable some "bootstrapping" of democratic approval of policy, upon implementation, this policy shall be submitted to the network as a whole for ratification. Policy5 must be ratified by a majority of the votes in the received in that ratification to remain in force. Failure will result in termination of this Policy and Policy version 4 will be considered to be in force. Policy cases initiated before the date of approval of this policy will continue to be handled under previous rules to allow for continuity of operations. Upon implementation of this Policy, all network boundries will be subject to modification to ensure that nodes are within FidoNet geographic standards (local-call networks). Nodes released from networks as a result of boundry modification shall have full rights as Regional Independants under section 1.3.2. This section shall be removed from Policy upon completion of all the requirements within this section. 12.5 Election Procedures 12.5.1 General Election Procedures 12.5.1.1 Announcement of Elections In order to allow for a substantive discussion period, all elections must be publicly announced at least two weeks prior to the opening of balloting. At this time, the administrator of the election, subject matter of the election, date of opening of balloting, and date of closure of balloting must all be publicly announced. 12.5.1.2 Balloting Period At least two weeks must be allowed for balloting in all elections. No ballots may be accepted by the administrator system outside of the period of balloting. The sole exception to this rule is a case of documentable technical failure preventing delivery of ballots by a voter or receipt by the administrator. 12.5.1.3 Proxy Votes No proxy votes will be allowed in any FidoNet coordinator election or Policy referenda. 12.5.1.4 Requirements for Administrators The Administrator of an election must be able to receive a high volume of netmail in a very short time. Further, an Administrator must be politically neutral in regards to the election. (It would be ridiculous to have a candidate for a coordinator position as the Administrator for that election. Further, it is equally ridiculous to have the candidates best friend as an Administrator.) The system upon which the Administrator is receiving ballots must be a continuous mail, publicly available system. Further, the Administrator system may not be an echomail hub or routing hub (except for coordinator systems in Policy referenda), as the potential high traffic on these systems would interfere with availability for balloting calls. An Administrator may only administrate one election at a time. 12.5.2 Coordinator Elections and Recalls 12.5.2.1 Appointment of Administrator The coordinator at the level above the one being elected is responsible to call the election. If conditions for a recall are met or if it is time for the bi-yearly election of a coordinator, the level above shall appoint an administrator. For example, if it is time for an election for a Network Coordinator within a network, the Regional Coordinator will appoint an Administrator for that election. 12.5.2.2 Pre-Balloting Procedures Upon appointment of an Administrator, the appointing coordinator shall publicly announce the election in accordance with section 12.6.1.1. The Administrator shall then take nominations. Nominees must have the technical capability to do the job. For example, a nominee for the position of Network Coordinator should have a modem baud rate, experience and hard disk capacity for the job. While there is no right for anyone to preemptively exclude a particular individual from an election for a particular position, a technically incapable individual would become a problem to those beneath him as well as the rest of FidoNet. Further, were a technically incapable individual elected, inability to perform would necessitate an early removal and another election would have to be held, inconveniencing all involved. Nominating shall be closed no later than one week prior to the opening of balloting and the Administrator shall then publicly announce the candidates for the election. During the two week nomination process, the Administrator is also responsible to compile a list of eligible voters and issue a unique password to each by netmail. The Administrator shall keep a list of eligible voters and their corresponding passwords for election security. 12.5.2.3 Balloting Procedures Upon opening of balloting, each node voting shall send their ballot DIRECTLY to the Administrator. Ballots may not be routed as this compromises election security. In order to encourage the development of automatic election software, the following format must be used in ballot messages: To: Election Administrator, From: Subj: Election 1st Line: 2nd Line: 3rd Line: : The Administrator shall keep all ballots in an archive after tabulation. 12.5.2.4 Post-Election Procedures Upon closure of balloting, the Administrator shall compile a report of the election and forward it to the appointing coordinator with the archive containing all ballots. The following format shall be used for the report: Election: Final Count: Vote Accountability: Winner: The report shall be kept in a file called: .rpt and must be made available for public file request to any node in the nodelist. If there is no individual winning more than 50% of the votes cast, the top two vote-getters will run in an election administered by the same Administrator. 12.5.2.5 Challenge of Elections Sysops eligible to vote in an election are also eligible to challenge it, as is the appointing coordinator. In order to challenge, the sysop MUST be able to show evidence of erroneous electoral procedures. For instance, the sysop may claim, based on the report issued by the Administrator, that that sysop's vote was improperly counted. As evidence, the sysop must produce his ballot which contradicts the report. The appointing coordinator must then compare that ballot with its corresponding ballot in the archive record compiled by the Administrator. If there is solid evidence of a discrepancy, the appointing coordinator may take actions ranging from simple changing of the report to invalidation of the election. If there is solid evidence of discrepancies which affected the election to the point that it may have changed the final outcome, the appointing coordinator MUST call another election. 12.5.2.6 Implementation of an Election A newly elected coordinator takes office immediately upon announcement of the winner. Since the new coordinator will often need time to set up, the appointing coordinator may require a transition period in which the outgoing coordinator may continue to assist in certain technical functions for a period of time not to exceed on month. A newly elected coordinator IMMEDIATELY assumes all authorities in resolution of disputes and related appeal processes. The only limit on this is that a coordinator may not, as a result of a new election, review his/her own decision(s). These cases will defer to the next appeal level. 12.5.3 Policy Referenda 12.5.3.1 Pre-Election Procedures The Administrators in a Policy referendum are the coordinators. Upon fulfillment of the requirements for the holding of a policy referendum, the International Coordinator shall announce, in FidoNews and in the nodelist announcement block, the name of the Policy proposal, the date of opening of balloting, and the date of close of balloting. At least two weeks shall be allowed for discussion between this announcement and the opening of balloting and at least two weeks shall be allowed for a balloting period. If there is more than one Policy proposal, each shall be given a unique name. 12.5.3.2 Election Procedures The Network Coordinators (and the Regional Coordinators in the case of independent nodes in a region) shall act as Administrator systems in Policy referenda. The Administrator shall issue a unique password to each eligible node in that Administrator's area. Format of ballots in Policy referenda shall be the same as for coordinator elections with the following exceptions: 1) Subj: Policy Referendum 2) Line 3: Yes/No There may be multiple "Line 3's" if there is more than on Policy being voted on to allow a single ballot for the entire referendum. The Administrators shall maintain an archive of all ballots. 12.5.3.3 Post-Election Procedures Upon close of balloting, the votes shall be compiled as follows: 1) The Administrators shall compile election reports for their areas as specified in section 12.6.2.4. Report filename will be "policy.rpt". 2) Network Coordinators shall forward raw, numerical results to the Regional Coordinator. Network Coordinators shall also publicly announce the numerical results for their networks. 3) Regional Coordinators shall compile the raw results from the networks in their regions as well as the raw results from the independents in the region and shall forward the compiled numerical results to the Zone Coordinator. The Regional Coordinators shall also publicly announce the numerical results for their regions. 4) Zone Coordinators shall compile the results from the regions in the zone and shall forward the numerical results to the International Coordinator. Zone Coordinators shall also publicly announce the numerical results for their zones. 5) The International Coordinator shall compile the results from the FidoNet zones into final results. The International Coordinator shall publicly announce the final, numerical results in accordance with section 8.2. If a policy is ratified, then it will be implemented in accordance with section 8.2 and any implementation planks within the policy. 12.7 Credits, acknowledgments, etc. Fido and FidoNet are registered trademarks of Fido Software, Inc. Thanx to David Dodell for a fine term as IC. Thanx to Chris Baker for tolerating endless phone calls filled with my ranting and raving. Thanx to Rod Lamping for giving a much needed boost to Policy5.DEM. Thanx to Steve Boyd, Michael Corbin, Zhahai Stewart, Chris Anderson, and Jonathan Wood for support within my local net. Thanx to Marv Carson for RC support. Thanx to Steve Bonine for tolerating all the BS for a LONG time. Thanx to Zhahai Stewart and Donn Bly for prying me off my white horse. Thanx to the inventor of caffeine for making this Policy possible. Development will take place in the POL5_DEM echo, available from the following sources: Jason Steck -- 1:104/424 -- 2400 baud Steve Bonine -- 1:115/444 -- 9600 baud Region 15 backbone Chris Baker -- 1:135/14 -- 2400 baud (might be 9600, unknown) A variety of other sources. POL5_DEM is an open FidoNet sysops who agree to abide by the conference rules. Jason Steck Coordinator, Policy5.Dem