Volume 6, Number 14 3 April 1989 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Dale Lovell Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Al Arango FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Copyright 1989 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and are used with permission. We don't necessarily agree with the contents of every article published here. Most of these materials are unsolicited. No article will be rejected which is properly attributed and legally acceptable. We will publish every responsible submission received. Table of Contents 1. ARTICLES ................................................. 1 Policy4 Draft Released for Comment ....................... 1 ZOW, Yet Another Fantastically New File Packer! (Part 2 .. 35 2. COLUMNS .................................................. 37 The Veterinarian's Corner: Winter Weather & Antifreeze ... 37 3. LETTERS TO THE EDITOR .................................... 38 4. LATEST VERSIONS .......................................... 39 Latest Software Versions ................................. 39 5. NOTICES .................................................. 40 The Interrupt Stack ...................................... 40 FidoNews 6-14 Page 1 3 Apr 1989 ================================================================= ARTICLES ================================================================= FidoNet Policy4 Comments Solicited David Dodell, FidoNet International Coordinator 1:114/15 -- 1:1/0 Included in this article is a proposed policy document for FidoNet. The existing policy has served well, but FidoNet has grown and changed a great deal since it was adopted. This proposal has been prepared by the Regional Coordinators, and your comments are sincerely solicited. Discussion at the net level is encouraged, and Network Coordina- tors will represent their net to the Regional Coordinator. The RC's realize that the net has significant input into the process of preparing policy, and your comments will be thoughtfully considered. The deadline for comments is April 30. A final proposal will be issued on May 8, and a vote will be conducted of NC's and RC's. The voting period will end on June 5, and results will be announced in the nodediff which is released on June 9. You are encouraged to read the proposal in its entirity, but here are a few of the differences between this proposal and Policy3. Greater detail: Throughout the document, more detail has been provided in an effort to clarify procedures. The intent is to make expectations clear for new and existing sysops to reduce the potential for unintentional policy violations, and to simplify the resolution of disputes when they do occur. This is an admin- istrative document which will assist both coordinators and sysops. Description of "new" developments: Routing hubs, point systems, and zone coordinators are described. None of these existed when Policy3 was written. Change procedure: A procedure is included to modify policy. This procedure will be used to adopt or reject Policy4. Dispute resolution: A statute of limitations and a limit on response time by a coordinator have been added. The appeal process has been clarified. Specific requirements have been added for a dialog between the complaining parties before the filing of a formal complaint. Mail: Specific procedures are included for private mail, echomail, and mail routing. Index: An index has been added to help you find that section that you know is there, but can't seem to locate. FidoNews 6-14 Page 2 3 Apr 1989 The full text of the proposal follows: FidoNet Policy Document Version 4.03 *** DRAFT *** March 24, 1989 This policy document has been released for comment, and is not yet in force. Please direct comments to your Network Coordi- nator. 1 Overview 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 participants 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 inde- pendent, constituent nodes may individually provide public access to the network on their system. FidoNet is large enough that it would quickly fall apart of its own weight unless some sort of structure and control were imposed on it. 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 nodes are grouped on several levels. Separate documents may be issued at the zone, region, or net level to provide additional detail on local procedures. Ordi- narily, these lower-level policies may not contradict this policy. However, with the approval of the International Coordinator, local policy can be used to implement differences required due to local requirements. The Zone Coordinator Council may reverse the decision of the International Coordi- nator. These local policies may not place additional restric- FidoNews 6-14 Page 3 3 Apr 1989 tions on members of FidoNet beyond those included in this document, other than enforcement of local mail periods. 1.2.1 Points A point is a FidoNet-compatible system that is not in the nodelist, but communicates with FidoNet through a node re- ferred to as a bossnode. A point is generally regarded in the same manner as a user, for example, the bossnode is responsi- ble for mail from the point. (See section 2.1.3.) Points are addressed by using the bossnode's nodelist address; for exam- ple, 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 visible outside of the bossnode- point relationship except as the first entry in the ^aPATH line. 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.2 Nodes A node is a single FidoNet address, and is the smallest offi- cial unit of FidoNet. 1.2.3 Networks A network is a collection of nodes in a local geographic area. Networks coordinate their mail activity to decrease cost. 1.2.3 Regions 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 indepen- dent nodes which are not a part of any network. 1.2.5 Zones A zone is a large geographic area containing many regions, covering one or more countries and/or continents. 1.2.6 FidoNet FidoNet indicates the entire amateur mail network as defined by the weekly nodelist (see section 1.3.4). FidoNews 6-14 Page 4 3 Apr 1989 1.3 Definitions 1.3.1 FidoNews FidoNews is a weekly newsletter distributed throughout the network by the coordinator structure. 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 encour- aged to contribute to FidoNews. Contributions are submitted to node 1/1; a file describing the format to be used is avail- able on many systems. 1.3.2 Geography Each level of FidoNet is geographically contained by the level immediately above it. A given geographic location is covered by one zone and one region within that zone, and is either in one network or not in a network. There are never two zones, two regions, or two networks which cover the same geographic area. If a node is in the area of a network, it should be listed in that network, not as an independent in the region. (The primary exception to this is a node receiving inordinate amounts of host-routed mail; see section 4.2). Network bound- aries are based on calling areas as defined by the local telephone company. Even in the case of areas where node density is so great that more than one network is needed to serve one local calling area, a geographic guideline is used to decide which nodes belong to what network. Network member- ship is based on geographic or other purely technical ratio- nale. It is not based on personal or social factors. There are cases in which the local calling areas lead to situations where logic dictates that a node physically in one FidoNet Region should be assigned to another. In those cases, with the agreement of the Regional Coordinators and Zone Coordinator involved, exemptions may be granted. Such exemp- tions are described in section 5.6. 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 ad- FidoNews 6-14 Page 5 3 Apr 1989 dresses of all recognized FidoNet nodes. This file is cur- rently 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 standards 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 Coordina- tor's and each Regional Coordinator's system. 1.3.5 Excessively Annoying Behavior There are references throughout this policy to "excessively annoying behavior", 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. Gener- ally speaking, annoying behavior irritates, bothers, or causes harm to some other person. It is not necessary to break a law to be annoying. Refer to section 9 and the case studies (section 10.3) for more information. 1.4 Administration of FidoNet FidoNet has a hierarchical structure for administration of the network, with the following levels: 1.4.1 International Coordinator The International Coordinator is the "first among equals" Zone Coordinator. He coordinates the joint production of the master nodelist by his fellow Zone Coordinators. The International Coordinator acts as the chair of the Zone Coordinator Council and as the overseer of elections -- ar- ranging the announcement of referenda, the collection and counting of the ballots, and announcing the results for those issues that affect FidoNet as a whole. 1.4.2 Zone Coordinator Council In certain cases, the Zone Coordinators work as a council to provide advice to the International Coordinator. The arrange- ment 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 such issues not addressed at a lower level of FidoNet. FidoNews 6-14 Page 6 3 Apr 1989 1.4.3 Zone Coordinator 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 routing services for the zone. 1.4.4 Regional Coordinator The Regional Coordinator maintains the list of independent nodes in the region and accepts nodelists from the Network Coordinators in the region. He compiles these lists to create a regional nodelist, which he then sends to the Zone Coordina- tor. A Regional Coordinator does not perform routing services for any nodes in the region. 1.4.5 Network Coordinator The Network Coordinator is responsible for maintaining the list of nodes for the network, and for forwarding netmail sent to the network from other FidoNet nodes. The Network Coordi- nator may make arrangements to handle outgoing netmail, but is not required to do so. The Network Coordinator is not re- quired to provide a source for echomail. 1.4.6 Network Routing Hub Network Routing Hubs exist only in some networks. They share duties of the Network Coordinator, in order to ease the man- agement of a large network. The exact duties and procedures are a matter for the Network Coordinator and his hubs to arrange, and will not be discussed here, except that a network coordinator cannot delegate responsibility to mediate dis- putes. 1.4.7 System Operator The system operator (sysop) formulates a policy for running his board and dealing with users. The sysop must mesh with the rest of the FidoNet system if he is to send and receive mail, and the local policy must be consistent with other levels of FidoNet. 1.4.8 User 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 considered to be from a user, and is the responsibility of the sysop. This includes messages from FidoNews 6-14 Page 7 3 Apr 1989 point systems. 1.4.9 Summary 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. Adminis- tration is made possible by operating in a top-down manner. That is, a person at any given level is responsible to the level above, and responsible for 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 Coordina- tor 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, the person at the next level may replace them. For example, if a Regional Coordinator fails to per- form, the Zone Coordinator can replace him. The exceptions to this top down organization are the Zone and International Coordinators. See sections 6.2 and 7.2. 2 Sysop Procedures 2.1 General 2.1.1 The Basics The sysop of an individual node can generally do as he pleases, as long as he observes the mail events, is not exces- sively annoying to other nodes on FidoNet, and does not pro- mote 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 Fido- Net policy. New sysops must familiarize themselves with policy before requesting a node number. 2.1.3 Responsible for All Traffic Entering FidoNet Via His Node A Sysop is responsible for all traffic entering FidoNet via his system. This includes (but is not limited to) traffic entered by his users, points, and any other networks for which FidoNews 6-14 Page 8 3 Apr 1989 he might act as a gateway. If a sysop allows "outside" mes- sages to enter FidoNet via his system, he has a responsibility to ensure his system is clearly identified by FidoNet node number as the point of origin of that message, and a responsi- bility to 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. Any sysop has the right to review traffic flowing through his 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 and/or commercial traffic that is routed without the express permission of all the links in the delivery system constitutes annoying behavior. 2.1.5 No Alteration of Routed Mail A sysop 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. If a sysop is offended by the content of a message, he must follow the procedure described in section 2.1.7. 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 recipi- ent can read messages. Sysops who cannot provide this dis- tinction 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 recip- ient or another individual to whom that sysop has given autho- rization can read the message. Thus, a sysop may have differ- ent expectations than a casual user. 2.1.6.1 No Disclosure of in-transit mail Disclosing or in any way using information contained in pri- vate netmail traffic not addressed to you or written by you is considered annoying behavior, regardless of how you come upon that traffic. This does not apply to echomail which is by definition a broadcast medium, and where private mail is often FidoNews 6-14 Page 9 3 Apr 1989 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 Fido- Net. 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 A sysop is not required to route traffic if he has not agreed to do so. He is not obligated to route traffic for all if he routes it for any, unless he holds 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 a sysop does not forward a message when he had 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. (It is not necessary to return messages which are addressed to a node which is not in the current nodelist.) Intentionally stopping an in-tran- sit message without following this procedure constitutes annoying behavior. In the case of a failure to forward traf- fic due to some technical problem, it does not become annoying unless it persists after being pointed out to the sysop. 2.1.8 Exclusivity of Zone Mail Hour Zone Mail Hour is the heart of FidoNet, as this is when net- work mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail from any node in the nodelist during this time. This time is exclu- sively 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 FidoNews 6-14 Page 10 3 Apr 1989 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 re- quired 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. 2.1.9 Private Nodes The rare exception to ZMH compliance is Private Nodes. Per- sons 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 replacement for that hub. A private node must be a part of a network (they cannot be independents in the region.) Private nodes are encouraged to honor ZMH. 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). 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 authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practi- cal. 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 9, and sections 4.3 and 5.2. It is considered annoying behavior to assist a system which FidoNews 6-14 Page 11 3 Apr 1989 was excommunicated in circumventing that removal from the nodelist. For example, if you decide to provide an echomail feed to your friend who has been excommunicated, it is likely that your listing will also be removed. 2.1.13 Timing of Zone Mail Hour The exact timing of Zone Mail Hour for each zone is set by the Zone Coordinator. See section 10.2. 2.1.14 Non-observance of Daylight Savings Time FidoNet does not observe daylight savings 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. 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. 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 net- mail, use address -1/-1, and include the following: 1) Your name. 2) The name of your system. 3) The city and state where your system is located. 4) The phone number to be used when calling your system. 5) Your hours of operation, netmail and BBS. 6) The maximum baud rate you can support. FidoNews 6-14 Page 12 3 Apr 1989 You must indicate that you have read, and agree to abide by, this document and all the current and future policies of Fido- Net. Using a node number other than -1/-1 can cause problems for the coordinator involved. Simply assigning yourself a net/node number can be annoying, and can be grounds to reject your request. Your coordinator may want additional information. If so, he will contact you. Please allow at least two weeks for a node number request to be processed. If you send your request to a Regional Coordi- nator, he may forward it to the appropriate Network Coordina- tor. 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. If you do not do this, other systems will try to reach you while you are down, much to their annoyance. Never put an answering machine or similar device on your phone line while you are down. If you do, calling systems will get the machine repeat- edly, racking up large phone bills, which is very annoying. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your coordinator. Systems 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 Coordi- nator. Then consult your Regional Coordinator. You must send the following information: 1) The region number(s), or network number(s) if a net- work 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. FidoNews 6-14 Page 13 3 Apr 1989 2) A copy of the proposed network's nodelist segment. This file should be attached to the message of applica- tion for a network number, and should use the nodelist format described in the current version of the appro- priate FTSC publication. Please elect a name that re- lates 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 your- self 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 exact- ly as you request. Your Regional Coordinator will review your application and inform you of the decision. 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 Nodelists, Difference Files, and FidoNews Any Coordinator is responsible for obtaining and making avail- able, on a weekly basis, nodelist difference files and Fido- News. 3.2 Processing Nodelist Changes and Passing Them Upstream Each coordinator is responsible for obtaining nodelist infor- mation from the level below, processing it, and passing the results to the level above. The timing of this process is determined by the requirements imposed by 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 he receives to the level above, and to review such policies. Although not required, common courtesy dictates that when formulating a local policy, the participation of the level above should be solicited. 3.4 Minimize the Number of Hats Worn Coordinators are encouraged to limit the number of FidoNet functions they perform. In particular, a coordinator's system should be readily available to the levels immediately above FidoNews 6-14 Page 14 3 Apr 1989 and below, and a coordinator should not rule on the appeal of his own decision. Coordinators are discouraged from acting as echomail and soft- ware-distribution hubs. If they do so, they should handle echomail (or other volume distribution) on a system other than the administrative system. 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 soft- ware-distribution hub, those services will be difficult to restore when he 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. A Regional Coordinator must be either a member of a network in his region, or an independent of 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 distribut- ing 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 his predecessor or peers beyond the scope of this document. In addition, a new coordinator has the right to review any decision made by his predecessors for compliance with Policy, and take whatever actions may be necessary to rectify any situations not in compliance. 3.8 Technical Management The primary responsibility of any coordinator is technical management of network operations. Decisions must be made on technical grounds. 4 Network Coordinator Procedures 4.1 Responsibilities FidoNews 6-14 Page 15 3 Apr 1989 A Network Coordinator has the following responsibilities: 1) To receive incoming mail for nodes in his network, and arrange delivery to its recipients. 2) To assign node numbers to nodes in his network. 3) To maintain the nodelist for his network, and to send a copy of it to his Regional Coordinator whenever it changes. 4) To make available to his nodes 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 his 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 he cease and desist routing these vol- umes. If he refuses to do so, then you can request your Regional Coordinator to assign the node a number as an inde- pendent and drop him 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 coor- dinator of the offending node. (If the node is an indepen- dent, complain to the regional coordinator.) Bombing runs are considered to be annoying. Another source of routing overload is echomail. Echomail cannot be allowed to degrade the ability of FidoNet to handle normal message traffic. If a node in your network is routing large volumes of echomail, you can ask him to either limit the amount of echomail or to stop routing his echomail. You are not required to forward encrypted, commercial, or illegal mail. However, you must follow the procedures de- scribed 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 network. You may also change the numbers of existing nodes in your network, though you should check with your member nodes before doing so. You may assign any numbers you FidoNews 6-14 Page 16 3 Apr 1989 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. Further, if you have nodes in an area covered by a network in formation, those nodes must be trans- ferred to the new network. You should use network mail to inform a new node of his node number, as this helps to insure that he is capable of receiv- ing network mail. If a node in your network is acting in a sufficiently annoying manner, then you can take whatever action you deem fit, ac- cording to the circumstances of the case. 4.4 Maintaining the Nodelist You should to implement name changes, phone number changes, and so forth in your segment of the nodelist as soon as possi- ble 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 marked DOWN for a maximum of two weeks, after which the line should be removed from the nodelist.) At your discretion, you may distribute a portion of this work- load to routing hubs. In this case, you should receive the nodelists from the Hub Coordinators 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 he designates. It is suggested that you do this as late as is practical, so as to accommodate any late changes, balanced with the risk of miss- ing 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 6-14 Page 17 3 Apr 1989 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 pub- lished 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. 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 networks, or to form new networks. 3) To assign network numbers to networks in the region and define their boundaries. 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 indepen- dent 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. FidoNews 6-14 Page 18 3 Apr 1989 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 opera- tional. 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 node of his node number, as this helps to insure that he is capable of receiv- ing network mail. If a node in your region is acting in a sufficiently annoying manner, then you can take whatever action you deem fit, ac- cording to the circumstances of the case. 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 determine. 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 pro- mote 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, howev- er, 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 circumstan- ces 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 FidoNews 6-14 Page 19 3 Apr 1989 of network numbers to use for this purpose by your Zone Coor- dinator. As a part of this function,