Volume 6, Number 17 24 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 Reflections on the new Policy ............................ 1 POLICY4 Reaction ......................................... 11 Reflections on POLICY4 ................................... 14 2. LETTERS TO THE EDITOR .................................... 29 Message Encryption ....................................... 29 3. LATEST VERSIONS .......................................... 30 Latest Software Versions ................................. 30 4. NOTICES .................................................. 31 The Interrupt Stack ...................................... 31 FidoNews 6-17 Page 1 24 Apr 1989 ================================================================= ARTICLES ================================================================= Vince Perriello Fidonet 1:141/491 Reflections on the new Draft Policy document I believe that the new Policy document is a good document. I also believe that it has some important flaws and omissions. Most of these are in the area of unnecessarily rigid or arbitrary text. I've covered the areas I feel need to be either further explained or corrected below. This document should be corrected before the ratification vote. But I feel that both the corrections and the vote should take place as soon as possible. The author(s) of Policy4 have done a good job addressing problems that have cropped up since the prior version and we need to have it in force as soon as possible. [Beginning of quoted passages] > The official language of FidoNet is English. All documents > must exist in English. Translation into other languages is > encouraged. I thought this somewhat jingoistic until someone pointed out to me that this had first appeared in a submission from Henk Wevers. Maybe I have gotten too sensitive to the North American bias issue. If Henk thought this necessary, then I'll go with it. But why was it considered so important that it even preceded the definition of Fidonet? > 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. What a difference five years makes. It's too bad we don't have 5,000 FRIENDS swapping messages back and forth . > 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. Good. Though I would prefer that we also said something here like "individual nodes providing commercial services using Fidonet as a transport mechanism are acting solely for their own purposes and not as a member or agent of Fidonet as a whole". FidoNews 6-17 Page 2 24 Apr 1989 > 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. Now HERE's an interesting paragraph. You mean that the IC, the Z1C and the Z1RC's are planning on relaxing the iron fist? The use of the word "decentralized" seems to imply this. Good. More power to them, er, to the Nodes and NC's I mean. > 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. What's a ^aPATH line? Is this Echomail? Why are we talking about specific Echomail implementation issues in Policy? > 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. May I infer from this that if a point makes a file request from a node other than its bossnode that it is operating in a manner which is consistent with Policy? This issue nearly brought the BINKLEY echomail conference to its knees recently. Some clear statement on the issue would be a welcome relief. > A zone is a large geographic area containing many regions, > covering one or more countries and/or continents. This language is probably too restrictive. How about "which MAY cover one or more ..."? I trust you agree that, for example, the Soviet Union or (Mainland) China are so large they might require multiple zones? > FidoNews is a weekly newsletter distributed throughout the > network by the coordinator structure. I don't believe that the distribution is limited to coordinators. > 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. (Newsletter Editor hat on) Thank you very much. (hat off) > Contributions are submitted to node 1/1; a file describing > the format to be used is available on many systems. Why not say it's available on 1/1? And why not say 1:1/1? FidoNews 6-17 Page 3 24 Apr 1989 There ARE other Zones, you know. > Network boundaries are based on calling areas as defined by > the local telephone company. Not totally. Check out Net 132 in Zone 1, for example. It includes at least two states and area codes. > 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 membership is based on > geographic or other purely technical rationale. It is not > based on personal or social factors. This makes a lot more sense than the preceding sentence. Maybe the former should be scrapped or rewritten in favor of the latter? Seems like what we really have is geography rightfully taking precedence over local phone companies (which come in a close second). > Zone Mail Hour (ZMH) is a defined time during which all nodes in > a zone are required to be able to accept netmail. Might I suggest here you add a sentence? Such as " A given node may use any method preferred by its operator to transfer mail, but all nodes must be capable of falling back to the base Fidonet protocol as defined in FTSC document FTS-0001"? > 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. Does this mean that 1:1/0 now allows file requests for this file starting immediately after ZMH on Saturday? > To be included in the nodelist, a system must meet the > standards defined by this document. No other requirements may > be imposed. All the more reason to take FTS-0001's name in vain above. Did you really mean to shut FTSC out here or was this just bad language? If it was bad language, we'd best fix it. Like "standards defined in this document or technical standards ratified by the FTSC and accepted by the International Coordinator" in place of "standards defined in this document"? > In certain cases, the Zone Coordinators work as a council to > provide advice to the International Coordinator. When does the Council meet? > The Network Coordinator is not required to provide a source > for echomail. FidoNews 6-17 Page 4 24 Apr 1989 No such statements were made about the IC, ZC or RC. Does this mean that they ARE so required? > (in discussion of Hubs) > ... a network coordinator cannot delegate responsibility to > mediate disputes. Why not, as long as the NC will step in if the decision of the Hub is not acceptable to all parties? > The system operator (sysop) formulates a policy for running > his board and dealing with users. You meant "his or her", right? Also, how about cases where a Fidonet node isn't a BBS? Or are we phasing those nodes out? > 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. Here you meant to say "He or She", didn't you? I'll assume you mean the policy of the board when you say "local policy" here. So, let me see if this works. If the International Coordinator states that messages about "foo" are considered annoying, then I can't allow messages about "foo" on my system even if they are in local-only message bases? Balderdash. Rewrite this part. > 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.) Does this mean that any user may get his sysop thrown out of Fidonet with one well-placed message? Seems like the sysop should be given an opportunity to correct, limit access, or remove a user before a determination is made that the sysop is being annoying due to the actions of a user. > 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 > point systems. Seems fair, but please see the previous point. By the way, is there any reason why this logic can't include BIDIRECTIONAL gateways with so-called "Alternative Networks" which use Fidonet technology? > 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. Exactly what we should have in Zone 1. Low-level ADMINISTRATION and high-level COORDINATION. > The sysop of an individual node can generally do as he > pleases, as long as he observes the mail events, is not FidoNews 6-17 Page 5 24 Apr 1989 > excessively annoying to other nodes on FidoNet, and does not > promote or participate in the distribution of pirated > copyrighted software or other illegal behavior via FidoNet. How about if the sysop decides to do something completely legal but blatantly commercial, and advertises access to Fidonet as a valuable part of the service he or she (I try to stay gender neutral myself) has to offer? Then for some reason a legal proceeding is initiated due to some action this person has or has not taken. Are we protected? Enquiring minds ... > 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. Too bad we can't have some kind of exam too, like they do for drivers' licenses. But just having this here is something. Please don't forget to make sure that NC's are familiar with this section and take some steps to determine that the operator of a new node has in fact read POLICY (though I have no idea what those steps would be) > 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 > he might act as a gateway. If a sysop allows "outside" > messages 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 responsibility to act as a gateway in the reverse > direction. Should such traffic result in a violation of > Policy, the sysop must rectify the situation. How come a Sysop can fix problems with gateways and points but is considered annoying if she has an annoying user? > 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. I'm not saying that something doesn't need to be said about routed encrypted messages. But I have a problem with this black and white stuff. No room for interpretation. No room for any kind of mitigating circumstances, such as pilot error. We may be judged by future generations on the quality of our mercy. > 2.1.6 Private Netmail This entire section makes a lot of sense. Of course it reads more like something out of a "guide to novice sysops" rather FidoNews 6-17 Page 6 24 Apr 1989 than a Fidonet Policy and Procedures document. But I agree it needs to be stated somewhere. Good show. > 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. OK. How about messages which are sent to a given node in error? Is the receiving node obligated to either forward or bounce? It appears that there's nothing to cover this here. > 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 > from any node in the nodelist during this time. Sure wish you'd mention FTS-0001 somewhere. > Echomail should not be transferred during ZMH. That's a little stiff. I don't see any problem with ultra low volume Echomail. Can we fix the language to make individual interpretations possible for individual cases? > User (BBS) access to a system is prohibited during ZMH. Yeah! > 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. Why not let the NC judge whether such things as Echomail transfer constitute annoying behavior as well? You can see a problem better when you're in the same town with the guy than if you're a couple of states removed. Though the exceptions should be few and far between. > 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 replacement for that hub. A private node must be a part > of a network (they cannot be independents in the region.) That all sounds good. I can think of other applications of Private nodes, but your example is adequate. > Private nodes are encouraged to honor ZMH. I'm not quite sure why. As I see it, the main purpose of a FidoNews 6-17 Page 7 24 Apr 1989 private node is to have a Fidonet mailbox with restricted access. Since other systems will be able to contact the private node directly only by prior arrangement, what's the point of having the private node honor ZMH? > It is considered annoying behavior to assist a system which > 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. Hmmm. Would I be presumptuous to call this the Lee Kemp Clause? You know, there are reasons other than what you envisioned. How about this: a system is excommunicated because he doesn't observe ZMH. So he decides to become a point off your system. Does that mean you're history in Fidonet? > 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, 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. So far, so good. Though I don't understand the insistence on using -1/-1 for an address. I'm aware of an old default address in Fido of -1/-1 and of an undocumented feature in one or more current network mailers. But I'm also told that several nets already have a preferred address other than -1/-1 which they use for the purpose of new node applications. > You must indicate that you have read, and agree to abide by, > this document and all the current and future policies of > FidoNet. Yeah, right. Give me a break. Who on earth is crazy enough to agree to abide by some future nonexistent document? Contact your legal eagle and see if she thinks that any such agreement is worth the oxide it's written on. > 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. See comment above regarding -1/-1. > 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 repeatedly, racking up large phone bills, which is > very annoying. FidoNews 6-17 Page 8 24 Apr 1989 Why is it you use the magic phrase "annoying behavior" elsewhere in cases where there are definite grey areas, and don't use it HERE? A system that answers with a machine should be marked DOWN! PERIOD! Make some effort to reach its owner, if you can't then JUST MARK THAT SYSTEM DOWN! > 3.1 Make Available Nodelists, Difference Files, and FidoNews > > Any Coordinator is responsible for obtaining and making > available, on a weekly basis, nodelist difference files and > FidoNews. Well, which is it? In the heading, nodelists are mentioned; in the accompanying text, they are not. > 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. This appears to be the only mention of local policy. Does this mean that as long as it's not inconsistent with general policy, that any local policy at all can be defined? With no consent needed from the coordinators above? > 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. Does this include excommunication for cause (or refusal to do so)? If so, we need some kind of statute of limitations. >(From responsibilities of a Network Coordinator) > 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. As a USER? Why? If there are acceptability issues, they should be documented here. If not, then what purpose would be served? > You should use network mail to inform a new node of his node > number, as this helps to insure that he is capable of > receiving network mail. That's the ticket. So why does an NC need to call a system before granting a node number? > You should to implement name changes ... ^^ Did this word just creep in? > 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. FidoNews 6-17 Page 9 24 Apr 1989 So why doesn't a host need to have a full nodelist available any more? Where does somebody get one if they need it? > A Zone Coordinator is charged with the task of ensuring the > smooth operation of his Zone. He does this by supervising the > Regional Coordinators. I hate that word "supervise". What place does the term "supervision" have in an "amateur" network? By the way, it doesn't seem to me that "coordinate" and "supervise" are the same thing. So where can I find the description of the Zone Supervisor? >(from the section relating to Policy votes) > Network coordinators are expected to assess the opinions of > the members of their network, and to vote accordingly. And what if they don't? > If a number of alternatives are to be considered, they must be > presented as whole documents, from which one is chosen. What if more than one of them receives the requisite votes? > A Policy amendment is considered in force if, at the end of > the balloting period, it has received a majority of the votes > cast, and has received a majority of the network-coordinator > votes cast, and has received a majority of the regional- > coordinator votes cast. Let me get this straight. If 100% of the NC's vote in favor of something but only 49% of the RC's do, then it fails? That's democracy for ya. Can we at least make it a majority of one plus a plurality of the other? > In the case of multiple policy changes which are considered on > the same ballot, a version must receive more than 50% of the > votes cast to be considered ratified. "Abstain" is a valid > vote in this case, effectively being a vote for not changing > the current policy as it simply increases the number of votes > required to ratify the proposed change. This makes me even more certain that majority of one plus plurality of the other makes sense. I don't believe in sleazy voting tactics like this. >(From Statute of Limitations clause) > 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. That's fine. Now let's say that the Coordinator finds in favor of the person accused. Then the Coordinator leaves office. Can the new coordinator reinitiate the proceedings, regardless of FidoNews 6-17 Page 10 24 Apr 1989 the amount of time which has passed? Based on the earlier stuff I pointed out, I would say that the answer is YES. That needs to be addressed. [End of quoted passages] Those are the specific areas in which I saw problems in the document. By and large, it's a good one, as I said above. I'd like to see most of the changes proposed above in the final version, though. Particularly the areas concerning FTSC. I trust that the areas where annoying behavior is defined are meant primarily to establish criteria for filing complaints and not to lock a given Coordinator into a set course of action. The reason I highlighted those areas was to make certain that this was indeed the case. I look forward to seeing language corrections and clarifications added to the document, and to seeing it accepted by the *C's. I can't encourage you enough to read this document yourself and to discuss it with your fellow Sysops and with your respective Net or Regional Coordinator. YOU are Fidonet. It's YOUR Policy. Help make it the best Policy possible. ----------------------------------------------------------------- FidoNews 6-17 Page 11 24 Apr 1989 Randall Greylock Fidonet 1:321/202 Disclaimers I was involved in the process First off, I'm biased. Much of the work on this Policy 4 was done while I was an RC, and I had some influence on the form of the document. However, I do not pretend to speak for the coordinator structure. I also have to apologize to the coordinators, for in making my comments to them when initially requested, I skimmed one big section (Policy ratification), and missed what I feel is one of the biggest flaws in the document. I've seen Vince's Article I've also seen a draft of Vince's article. For the most part, I agree with his comments, although in some cases, what seemed obvious to me was not obvious to others. (This is basically the same problem as exists in P3.) Oh, and I'm writing in extreme haste. It's 22:45 right now, I have to have this sucker in by 23:00. It hasn't been spell checked, grammar checked, or seriously logic checked. Sorry. Original Design Goals Minimal Changes from P3 One of the major goals of P4 (during my tenure, at least) was a minimal set of changes from P3. The more changes there are, the more argument there will be. My feeling is this goal has largely been met. Clear Path to P(N+1) Another primary goal was the definition of how we get from P(n) to P(n+1). While this goal has been met, I share the reservations Vince has on this section of the document. All in all, though, I can live with it. Casting In Policy The Learning From Precedent Finally, much of what was not so much to change Policy, but to refine it - taking things decided by dispute and putting them FidoNews 6-17 Page 12 24 Apr 1989 into clear Policy language. Much of the new text is not new policy, but the application of Policy. Problems - Perceived and Otherwise Dual Majorities The democratic procedures have changed greatly since last I saw P4. At that time, the concept of two kinds of majorities was in place in order to balance geography against population. In order for Policy to be put in place, it had to be ratified by a majority of those voting, and a majority of the Zones. The intention (which may or may not have been well served) was to ensure that a broad geographic consensus be reached for Policy changes. The concept of dual majorities applied to the levels of FidoNet does not seem to provide any protection against anything. It leaves the system such that a very small number of sysops can dictate network philosophy - i.e., the RC's essentially have veto power over any Policy initiative. I do not necessarily believe democratic procedures are the best way to run a network. But I do believe the majority of the network feels otherwise. The language as it stands is an affront to that viewpoint. An argument can (and will) be made that the RC's are in the best position to formulate and evaluate Policy. Further argument can and will be made that most people don't participate anyway. While there is merit to both of these arguments, this is not a good reason to institionalize a caste system in the decision making process. Usage of the Word Annoying During my involvement in the P4 formulation, the word annoying and the phrase excessively annoying were used rather precisely. Annoying behaviour is not, in and of itself, excommunicatable. Excessively annoying behaviour is. Annoying behaviour can CUMULATIVELY become excessively annoying if steps are not taken to rectify it. Unfortunately, given the lack of precision in the usage of other terms and phrases in the document, this distinction may have been lost. Somewhere along the line, it would be nice to have some word other than annoying to describe the "lesser" mode of the term. References to Technical Standards Documents The biggest problem with Policy in all its incarnations is that what seemed obvious to the authors is not nearly so obvious to the readers. This is particularly true in the case of technical standards and their relationship to this document. FidoNews 6-17 Page 13 24 Apr 1989 It seemed obvious that saying "One must be capable of receiving netmail during ZMH" implied FTS-0001 compliance. There is a flip side of this problem Vince fails to mention, however - to the best of my knowledge, there is no official list of compliant software. Further, there is a serious problem of existence. Does FidoNet exist? Does a relationship between FidoNet and IFNA exist? Does a relationship between IFNA and FTSC exist? Does a relationship between FidoNet and FTSC exist? The answers to these questions are not clear to me, and I'm not sure hardening such relationships is the best way to clarify them. There was, during my involvement, a feeling on the part of many that we could not solve all the problems of the world, and we'd be better off clearly saying how we should go about addressing them than doing a bad job of addressing them in an environment where the right to do so was unclear. Also, there are some issues that are political as well as technical. One of them is the appearance of "non-FidoNet" address information in traffic flowing through FidoNet's routing systems. Is it fair to impose the burden of another network's routing information on nodes operating in an official FidoNet capacity? Personally, I think not. No matter what, I do not think this is a purely technical decision. Similar arguments can be made about the -1/-1 new node number request. The goal was to make it possible for hosts to be able to honor requests for node numbers, while still being able to maintain control of their systems. It is possible with many mailers to close out unidentified systems, and regulate the access of known ones. The goal was to provide a known number for the request of a new node number to simplify the lives of those hosts that wish to otherwise exclude unknown systems. -1/-1 was chosen because of historical precedent. I suggest that a single number like 1/32000 be used in its stead. (We don't need yet another administrative entry in each net.) Overall Reaction Overall, I still urge any and all coordinators to ratify this document. Even with the flaws, the existance of a clear ratification process provides a mechanism for other issues to be addressed in the future. The process has taken much too long as it is, and has caused too much turmoil. Let's get the sucker out the door, then take six months or a year to carefully address many of the perceived problems of the net. Specifically, I would leave aside the issue of commercialism that seems to be sweeping the net lately - the current Policy seems to have mostly worked, and rules should not be made in haste. Many, many dates have been set and past for the implementation of this document; I believe that the credibility of the *C structure simply cannot take too many more election dates set, missed, voted on, then overturned, all of which is done with little public notice. ----------------------------------------------------------------- FidoNews 6-17 Page 14 24 Apr 1989 Jack Decker Fidonet 1:154/8 LCRnet 77:1011/8 NetWork 8:70/8 REFLECTIONS ON POLICY4 After reading POLICY4, I have a few comments I'd like to share with you. I haven't had access to the SYSOP or IFNA echoes for close to four months now (another result of ECHOPOL), so these thoughts are not repetitions of anything I've heard there recently. First, I'll take some of the parts of POLICY4 and comment on them individually, then I'll close with some general comments. Starting near the beginning (a very good place to start!), we find this small but significant (and somewhat confusing) paragraph: 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. Highlight the words "unless some sort of structure and control were imposed on it." The problem here is that most Fidonet sysops that I've spoken to don't want structure and control IMPOSED ON THEM from on high. It's strange that in America, the land of democracy, the people in Fidonet would be forced to live under a document that sounds like something that the Russian government would issue (in pre-glastnost days, no less). 1.2.3 Networks A network is a collection of nodes in a local geographic area. Networks coordinate their mail activity to decrease cost. This is mention #1 of geography. I'll get back to this later. 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 independent nodes which are not a part of any network. Mention #2 of geography. More later. 1.2.5 Zones A zone is a large geographic area containing many regions, covering one or more countries and/or FidoNews 6-17 Page 15 24 Apr 1989 continents. Mention #3 of geography. For those in other (non-Fidonet) networks it also ignores current usage of zones, but then I hear they're trying to come up with some spiffy new "Domain" proposal that will once again break all existing software, so the other nets won't have to (be allowed to?) use zones for this purpose. 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. Why? Would the world come to an end if there were two nets in the same geographic area? Maybe we ought to give AT&T the northern U.S., Sprint the Eastern seaboard, MCI the West and Southwest, and divide the rest of the U.S. among the other long distance carriers. What's that got to do with anything? Well, recent history should tell us that when you can only obtain a service from one provider, they can charge whatever they want, and often treat those they serve in any way they like. When there is competition, or the ability to go to more than one source for a service, the providers of that service seem to be just a little nicer and more considerate. Even where real competition doesn't exist, the fact that competition is possible can make a big difference. If I had the only gas station in a town and decided to charge $5 a gallon for gas, you can bet that somebody would soon get the idea that they would be a local hero if they opened a station and charged only $1.50 a gallon. That thought would probably keep me from charging totally ridiculous prices for my gas. I know some are saying "That's fine for business, but what has it to do with Fidonet?" Simple, human nature being what it is, the same principles apply. If you have a net coordinator or a regional coordinator who can tell people to do things his way or get out of the net, or to accept the few services he chooses to provide even though someone else might be willing to offer more services, that gives the *C structure the ability to "play dictator" to those under them. Of course, MOST *C's wouldn't do that, but life can be no fun at all if YOU happen to be under a heavy-handed *C. 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 boundaries are based on calling areas as defined by the local telephone company. Even in the case of areas where node density is so great FidoNews 6-17 Page 16 24 Apr 1989 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 membership is based on geographic or other purely technical rationale. It is not based on personal or social factors. More geography. Also, who determines "calling areas as defined by the local telephone company?" Some cities have a metro area (where it's a free call to anywhere in that area from anywhere in that area), but in other places calling areas overlap (for example, everyone gets their home exchange plus all surrounding exchanges as part of their local calling area). Some folks may live just outside a local calling area for a net, but may wish to participate in that net anyway, while others in the same situation may prefer to remain independent. 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 exemptions are described in section 5.6. An admission that basing everything on geography is going to cause problems. But wait 'til you see section 5.6! 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. 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, and responsible for the level below. This strikes me as being backward. A coordinator SHOULD be responsible to those he governs. "Government by the consent of the governed", it's called. Seems I recall that the United States fought some wars to win this right a couple of hundred years ago. 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, the person at the next level may replace them. For example, if a Regional FidoNews 6-17 Page 17 24 Apr 1989 Coordinator fails to perform, the Zone Coordinator can replace him. What this means, folks, is that if your NC decides to back you in a dispute against the Fidonet hierarchy, they can order him replaced. You have no say as to who you want for your NC. Does any of this remind you of the government structure used in certain countries that don't have many Fidonet nodes? 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, 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 used to keep a sysop-only area restricted. There are several clauses in the proposed policy dealing with private mail. My feeling is that this is an amateur network, and therefore we shouldn't handle mail for which any level of "security" is expected. There are private commercial services intended for that purpose (e.g. MCI Mail, Compuserve, GEnie, etc.). Given that, I would prefer not to see clauses like the one above, which could (under the right circumstances) subject a Fidonet sysop to litigation. 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 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. What happens if a person needs to operate a private node (for whatever reason) but is not part of the geographical coverage area of any network? The point may be a bit moot, because since a private node is by definition unlisted, it could be part of any net and nobody would be the wiser (so long as the real geographic location of the node was not given in the nodelist, and folks were careful not to reveal the real location). But why force folks to go through that type of sham? 2.2 How to obtain a node number [Regarding application for a new Fidonet node] ..... FidoNews 6-17 Page 18 24 Apr 1989 You must indicate that you have read, and agree to abide by, this document and all the current and future policies of FidoNet. How can one "read and agree to abide by" all FUTURE policies of Fidonet? Especially when they often seem to be imposed "at will" by power-hungry coordinators? 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. .... 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. Does this now give the RC veto power over which nodes can and cannot be in a local network? Again, it seems the power is flowing from the wrong direction here... 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. More geography (I've lost count by now...). 4.3 Assigning Node Numbers ... 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 transferred to the new network. Though perhaps not readily apparent, this is still more geography! 5.1 Responsibilities A Regional Coordinator has the following responsibilities: FidoNews 6-17 Page 19 24 Apr 1989 ... 3) To assign network numbers to networks in the region and define their boundaries." "...and define their boundaries???" So the RC can come in and in one fell swoop, cut a bunch of nodes out of your net by changing the boundaries! More geography! More power flowing in the wrong direction! 5.2 Assigning Node Numbers ... 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. Normally this would be desirable, but in certain cases it may not be. Why not give the independent nodes the option of joining or not joining the new network? Let me give you one example of a potential problem. There are, we'll say, ten independent nodes in a given area. One of the local sysops reads Policy one day and decides to apply to form a net, listing all ten of the independent nodes in his area as part of the new net. Unfortunately, this guy is well known to the local Sysop community (but NOT to the RC) as a real twit, someone that can't get along with anybody. The RC approves the request, and these other nine sysops suddenly find themselves under the thumb of Mr. Twit. 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. This puts a lot of power... much TOO MUCH power in my FidoNews 6-17 Page 20 24 Apr 1989 opinion... into the hands of the RC. Of course it goes without saying that we're still talking geography here. 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. "define the boundaries of the networks???" Here we go again (sorry if it's getting monotonous, I was getting pretty tired of it by the time I waded through the whole document! I didn't agree with it the first time, and the endless repetition sure didn't win me over!). 5.6 Geographic Exemptions There are cases where local calling geography does not follow FidoNet regions. In exceptional cases, exemptions to normal geographic guidelines are agreed upon by the Regional Coordinators and Zone Coordinator involved. 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 any of the coordinators involved. Finally we arrive at section 5.6. Don't you love this? They admit that in some cases there may be good reasons to bend the rules on the geography, but then they allow any of who knows how many coordinators to kill the arrangement on a whim (thus forcing some nodes to go long distance for services they should be able to get for free). The way this clause is worded sucks eggs, in my opinion. It allows the RC's to get much too involved in what should be a matter of concern only to a local net. 5.7 Overseeing Network Operations ... 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. Not only is this getting confusing, it's getting ridiculous! Does this mean that in some cases a sysop may have to join a FidoNews 6-17 Page 21 24 Apr 1989 new net if he moves across town? Would it be so awful terrible to give sysops a choice of which net they prefer to belong to? Oh, yeah, you did notice they mentioned geography again, didn't you? 9.1 General The FidoNet judicial philosophy can be summed up in two rules: 1) Thou shalt not excessively annoy others. 2) Thou shalt not be too easily annoyed. In other words, there are no hard and fast rules of conduct, but reasonably polite behavior is expected. Also, in any dispute both sides are examined, 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. I'm glad they used that example. It makes the difference between the proposed policy and a democratic governing system fairly obvious. Pornography is supposed to be judged according to "prevailing community standards." In other words, it is NOT supposed to be the opinion of the judges hearing the case. Suppose the judge were a closet Ted Bundy, or a straight-laced Puritan? No matter, it's not HIS opinion that's supposed to count, rather the offense is to be measured against community standards... that is, what would most of the PEOPLE in the community think about this? But in Fidonet, "Excessively Annoying Behaviour" is judged not against the views of the common sysops of Fidonet, but rather against the values and ideals of the *C structure, which are often diametrically opposed to the views of the common sysop. For example, common sysops might find it very annoying that a Regional Coordinator would try to step in and say which nodes could or could not be in their net! MANY sysops have found it VERY annoying that certain coordinators with very big egos (or worse?) have tried to prohibit cross-regional echo feeds. 9.8 Return to Original Network FidoNews 6-17 Page 22 24 Apr 1989 Once a policy dispute is resolved, any nodes reinstated on appeal are returned to the local network or region to which they geographically or technically belong. Just one more mention of geography... but the "or technically" is interesting. I wish there were a lot more "or technically"'s in this document, it might put things in a much different light. 9.9 Echomail Echomail is an important and powerful force in FidoNet. For the purposes of Policy Disputes, echomail is simply a different flavor of netmail, and is therefore covered by Policy. By its nature, echomail places unique technical and social demands on the net over and above those covered by this version of Policy. In recognition of this, an echomail policy which extends (and does not contradict) general Policy, maintained by the Echomail Coordinators, and ratified by a process similar to that of this document, is recognized by the FidoNet Coordinators as a valid structure for dispute resolution on matters pertaining to echomail. At some future date the echomail policy document may be merged with this one. Well, that's a whole discussion unto itself. Suffice it to say that the current echomail policy was formed by a small group of people who seemed to have specific goals in mind (inhibiting communications within the network!) and who were not very tolerant of dissenting views. For example, one of the primary people involved in echomail policy described those who didn't agree with geographic echomail restrictions as "fools". Many people felt that there was a real attempt to "railroad" this policy into place. The big problem with the Echo Policy is that it really represents the views of only a few in Fidonet, rather than the many. The average sysop was given NO real say in the formation of Echopol. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ You may wonder why I am so hung up on geography? Basically, because it gives those in control the ability to suppress dissent. It's the old "divide and conquer" routine. I've seen some real efforts to keep those who disagree with Fidonet policies from talking to each other, or to the other Sysops in Fidonet. Besides, it doesn't make sense technically, at least not in North America. I would estimate that out of those sysops who make a large number of long distance calls in a month, a fairly good percentage are using some type of calling plan that is not distance sensitive, whether on a packet switching network (e.g. FidoNews 6-17 Page 23 24 Apr 1989 PC Pursuit, Starlink) or a long distance service (e.g. Reach Out America, or Telecom Canada's "Between Friends"). Still other sysops have access to company tie lines, Foreign Exchange lines, or WATS lines that can give them access to other areas of the country at little or no cost. Many sysops have lost echo feeds in recent months, because they (or their feeds) were formerly able to get feeds from PC Pursuitable points (or even nearby points outside their region), but were cut off from those feeds when regional restrictions on echomail traffic started to be imposed IN ANTICIPATION of an Echomail policy allowing these restrictions. You heard me right. Many of the *C's were so into their power trip that they went ahead and began enforcing a policy that was still in the draft stage! Now it may make some sense to base some things on geography, but Fidonet regions make no sense at all (as a matter of fact, I heard they were based on NFL football regions, or some such thing. No one's yet been able to explain to me what football has to do with computer networks). The major problem is that Fidonet regions divide up the country and inhibit folks from talking to each other, yet they are too large to be meaningful in terms of reducing costs. For example, a person living near the border of a region might know that a feed for an echo he wants exists only thirty miles away, but across a regional boundary. The next nearest feed (and the only "legal" feed for him) is several hundred miles away in his own region. Now phone rates are a funny thing... even if you're on a distance-sensitive long distance service (and keep in mind that many sysops are not), most of the increases in phone rates are within the first 125 miles from your location. After that, the rates taper off, and the cost of a call remains pretty uniform across the country (there's only a two or three cents per minute difference between a call to a point 125 miles away, and a call a couple of thousand miles distant). Also, in many places, calls within your own state cost significantly more than calls going a similar distance to an out-of-state point. So, setting strict geographical boundaries for echomail can often increase costs for sysops. At the net level, basing net boundaries on a geographical factor can have several undesirable results. It may keep those who live near the net, or who have strong emotional ties with the net, from getting into that net. But the biggest problem, I think, it that it sets up a situation where the NC has too much power. He can service nodes on a "take it or leave it" basis. Nothing wrong with that IF there are other sources. We don't require Standard Oil to put a gas station in every city, because if they don't someone else probably will, and if that firm charges too much, a competitor will no doubt appear sooner or later. But, we do require Bell Telephone to serve every customer in their service area, and not only that, we have an FidoNews 6-17 Page 24 24 Apr 1989 body of people independent of the phone company (the Public Utilities Commission) who can step in and intervene on behalf of customers who have been overcharged, or otherwise wrongly treated. The trouble is that in Fidonet, all the "oversight" comes from above... from the very people who appointed the coordinator to his position. Nowhere are those who receive any services from these coordinators given any say in the process. Given that, I believe that the least we can do is to allow sysops some amount of choice in which net they will join. That way, if you manage to get a real dictator as an NC or RC, and the RC or ZC refuses to replace him (thereby admitting that they made a mistake in appointing the guy in the first place), sysops don't have to leave Fidonet entirely to get out from under the guy. Now I have one more thing to say about geography. Some people have come up with the bright idea that if cross-regional echomail feeds are prohibited, it will somehow cause dupe messages to magically disappear. What these folks fail to understand is the difference between geography and topology. You can have faulty topology no matter where the individual nodes are geographically located, or you can have a "clean" topology even if nodes are spread across the country. The physical location of a node makes no difference at all. For example, suppose you have a node that has been participating in a local net and not causing dupes. Let's further suppose he polls his net host nightly for mail and echoes. Now, one night he quietly packs up in the middle of the night and moves across the country, and begins polling his net host via long distance. Does his computer contain a sensor that says, "oops, I've changed times zones, so I have to generate duplicate messages?" Not hardly! As long as the node maintains the same topology within his original net (connecting to the same node for his feeds), he isn't going to screw up echomail. What does this prove? Simply that whether the network topology is good or bad has nothing to do with geography. You could draw a network topology map without ever knowing or caring where the nodes are geographically located. So, I have two major reason for not liking all the fuss about geography (and we must admit they've gone out of their way to get it into this document!) One is that these restrictions COST PEOPLE MONEY. They are particularly unfair to those who live near the border of a geographic area, since they are often forced to make long distance calls to more distant points than would be necessary without the restrictions. They other is that they provide a perfect spawning ground for petty dictators (and Fidonet has seen far too many of THOSE types already!). THESE RULES ARE UNENFORCEABLE There is a saying that when lawmakers create unenforceable laws, they create disrespect for the law in general. There are generally two reasons that laws can be considered FidoNews 6-17 Page 25 24 Apr 1989 unenforceable. One is that you can never catch the someone in the act in order to find out that the rules are being broken. The other is that such a high percentage of people consider the law ridiculous and/or unenforceable, so they make no attempt to comply with it. If everyone is breaking a certain law, it is de facto unenforceable, and eventually the law is usually change to reflect reality. Policy documents are the "laws" of Fidonet. If certain provisions are unenforceable, it can't help but create a climate of disrespect for Policy in general. I believe that parts of the proposed Fidonet policy are unenforceable for both of the above-mentioned reasons. First, because Fidonet is really a hobbyist organization, few sysops read Policy more than once, and a lot of those who do read it ignore it anyway, especially the parts that don't seem to make much sense. Since BBS's come and go, this problem will ever be with us. But, more importantly, sysops often conspire to "bend" certain rules in such a way that the higher-ups will never find out about it unless some fluke occurs. Some examples I've heard of (actually, none of these refer to a specific situation, but are composites of many tales I've heard): * A node lets callers on during ZMH, but few callers call at that time of morning anyway. If the NC or RC calls to deliver mail and the line's not busy, the mail gets through and they are none the wiser. If the line IS busy, they have no way of knowing that it's a BBS caller rather than another mail call in progress. * A sysop wants to feed echomail to a node in another region. Since he doesn't normally communicate with anyone else in the distant node's net, he just defines the distant net as a "pointnet" in his software, and uses some other software to strip or change PATH lines and other information on incoming messages from that node, so that the messages appear to have originated on his board. Of course, should a dupe loop occur in this setup, there is no easy way for anyone to track it down because all records of the "wild feed" have been expunged from the messages. Sure, it's an intentional violation of the rules, but he feels justified because after all, he never had any vote in the rules! * Another sysop has moved to a different region, but he wants to keep in touch with the folks in his old home town. So, his old net/node number is still in the nodelist, and he polls his net host every night for mail. Right now his node is listed as private/unlisted, so nobody can call him, but should the RC ever decide to try and remove all private nodes from the nodelist, he knows a nice "permanently busy" official phone company number that he can place in the nodelist. * Then there is the guy who always wanted to be an echo hub, so he set up his own point net. Since points are considered BBS users, they can be located just about anywhere, and his point users are (mostly because he's in a PC Pursuitable city). FidoNews 6-17 Page 26 24 Apr 1989 Strangely enough, some of his points also happen to be BBS sysops (who, coincidentally, seem to be getting their echo feeds from unknown sources), but as far as he is concerned, they are just users of his BBS, and entitled to get echoes just like any of his other point users... One other point... many sysops have come to realize that the ONLY possible sanction in Fidonet is excommunication, and while many RC's would be more than happy to excommunicate all of the "troublemakers" from their regions, most NC's (who generally know the "offenders" personally) are not usually so inclined, especially in the case of a policy regulation that nobody asked for in the first place. So, the only way that the RC can get a node excommunicated is to replace the NC of the net, but that isn't always so easy, either. One RC tried that and discovered that over 90% of the nodes in his region were ready to pull out of Fidonet and start their own network (the RC resigned instead). In another case, the RC wanted to replace an NC, but out of about twenty sysops, only one even thought about taking the job... and was gently but firmly persuaded not to by the other sysops of that net. The NC stayed put. The fact that excommunication is the only sanction gives sysops a lot more power than many of them realize. Suppose the only possible penalty for a crime were death? How would you ever enforce littering laws? You wouldn't... you'd concentrate on the really important crimes and forget the small stuff. But those in the Fidonet power structure like to issue a lot of proclamations regarding minor things, totally forgetting that they have no way short of excommunication to enforce these dictums... and you can't excommunicate too many nodes, or folks begin to suspect that maybe there's something wrong here! WHY THE POWER GRAB? The thing I can't understand is why such a small number of people have subjected themselves to such a large number of flames to try and bring about something that at least 90% of the sysops are either actively opposed to, or just don't care about. Why are they so doggedly determined to push policies that have caused some of the brightest software developers in Fidonet to consider leaving the net? (some have done more than just consider it!) Why are they trying to promote policies that will restrict the free flow of information and communications? These are questions you should be asking yourself, if you are a Fidonet sysop. There are probably a lot of entities that don't care much for our amateur network, both in the commercial and governmental spheres. Commercial interests would rather you use their services (and pay the associated per-minute charges). The government is probably a bit unsettled by the fact that we're moving massive amounts of data around containing all sorts of information, pretty much at will. I'm sure that some in FidoNews 6-17 Page 27 24 Apr 1989 government would really appreciate a move to funnel all echomail through eight or ten central collection points, which could be more easily monitored. Now, some have said that this kind of thinking is just plain silly, even if some of the principal players in the creation of Fidonet policy don't live all that far from our nation's capitol. Well, if that be the case, I apologize. Only thing is, for months now, I've been trying to figure out why these people would subject themselves to flames, harrassment, and the generally negative comments about their motives, character, and integrity that have come from the many sysops who simply don't want the vision of Fidonet that they're trying to sell. IF I COULD CHANGE FIDONET... If I could change Fidonet any way I wanted, I'd only make two changes. First, I'd get rid of all geographic restrictions. In most cases they aren't needed. In most cases, folks will join the net nearest them. If they don't, there may just be a good reason why they don't. Second, I'd get rid of Regions. They aren't needed. In fact, they aren't even used for mail routing purposes. They just set up artificial barriers to communications. If the ZC needs folks under him to divide the workload, then let's have "Coordinators at large". Each NC would be assigned to a Coordinator at Large, and would sent his nodelist updates to that person and receive his Fidonews and Netdiff feeds from that person. In the event of a personality conflict, the ZC could allow the NC to go through a different Coordinator at Large (and if all the NC's requested a transfer away from a certain coordinator, wouldn't that be a pretty good indicator that the guy has no business being a Coordinator?). I know some folks will quickly add that *C's should be elected, not appointed. I believe that, too, but don't think that would be quite so important if people were not forced to deal only with a single *C (at any level), based strictly on where they happen to be physically located. Now, I've been saying all this for quite some time, and a lot of other good, sincere sysops have been saying some of the same things. But the idea of taking the Geography out of Fidonet seems to scare the out of some of the current crop of Fidonet *C's. Why? Is it because some don't want to lose their Fiefdoms? Or is there some other reason they want to keep bottleneck control over Fidonet, and inhibit communication between different geographical areas? Those of you in alternate networks shouldn't feel so smug because you're not having these problems. Think about it... where do your echoes come from? In most cases, are they either received from or passed to Fidonet through a gate? That FidoNews 6-17 Page 28 24 Apr 1989 gateway connection could be easily monitored or disrupted. And right now, none of the alternate nets are all that large. If one of THEM grows to 4,000 nodes, we may see some occurrences in those networks that are difficult to understand. It's time for all sysops to wake up and see how our freedom to communicate is being gradually eroded by the added layers of Policy proclamations being foisted upon us. Tell your *C's that you do not support restrictions upon our freedom to communicate! Let the voice of the average sysop be heard! Ask yourself... are things really better now than they were before we had "Echomail Coordinators"? Do you really feel that restrictions based on artificial geographic boundaries have any merit? If not, write a message to your *C's today, and let your voice be heard! ----------------------------------------------------------------- FidoNews 6-17 Page 29 24 Apr 1989 ================================================================= LETTERS TO THE EDITOR ================================================================= Garth Kidd Fidonet 3:680/809 There is currently a large discussion (argument?) going on in some echo areas as to the legality of encrypting messages. The draft FidoNet policy in FidoNews 6.14 stated that encryption of any form was considered "annoying behaviour". In echo areas, this is entirely fair. People pay large sums of money to transport echo areas around the place, and people should not use them as an alternative to NetMail. The ruling, however, has one worrying aspect: It effectively bans encryption of messages, whether by DES means or simply by rotating the message 13 characters through the alphabet. Unfortunately, it also prevents the only means of keeping our privacy. It is a simple matter for sysops to read "private" messages (most don't: some might), and thus people will want to encrypt. Unfortunately, this makes it harder to tell if people are using the Net for illegal purposes (transfer of classified documents, etc). Discounting the last point, it seems fair to ban encryption in all places BUT private messages. Including the last point, it seems that it should be totally banned, or performed in a simple matter that anyone needing to check for illegal activity. This seems to be a trivial exercise, as it removes the privacy aspect again! I suggest an open debate in an echo area, or pehaps a vote of some kind by the participants in FidoNet. As voting by e-mail would be difficult, I suggest that it be restricted to sysops only, and the voting to be restricted to one vote per node. Comments on this method, please. Finally, I would like to point out that the echo area I have seen on some bulletin board, containing USENET and ACSNET jokes, have in them messages encryped with ROT13 (rotating letters forward 13 characters), which is quite popular and necessary for legal reasons on potentially offensive jokes. The ruling in the draft policy makes these messages rather illegal. How should these be handled? Yours, Garth Kidd. ----------------------------------------------------------------- FidoNews 6-17 Page 30 24 Apr 1989 ================================================================= LATEST VERSIONS ================================================================= Latest Software Versions Bulletin Board Software Name Version Name Version Name Version Fido 12k Opus 1.03b TBBS 2.1 QuickBBS 2.03 TPBoard 5.0 TComm/TCommNet 3.4 Lynx 1.30* Phoenix 1.3 RBBS 17.1D Network Node List Other Mailers Version Utilities Version Utilities Version Dutchie 2.90C* EditNL 4.00 ARC 6.01 SEAdog 4.50 MakeNL 2.12 ARCmail 2.0 BinkleyTerm 2.20* Prune 1.40 ConfMail 4.00 D'Bridge 1.18* XlatList 2.90 TPB Editor 1.21 FrontDoor 2.0 XlaxNode 2.32 TCOMMail 2.2* PRENM 1.40 XlaxDiff 2.32 TMail 8901 ParseList 1.30 UFGATE 1.03 GROUP 2.07* EMM 1.40 MSGED 1.99 XRS 2.0* * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 6-17 Page 31 24 Apr 1989 ================================================================= NOTICES ================================================================= The Interrupt Stack 28 Apr 1989 Start of Gateway '89 show at the Viscount Hotel in Queens, New York. Contact Gateway '89 at (516) 678-7180 for info. 8 May 1989 Digital Equipment Corporations User Society (DECUS) will be holding its semi-annual symposium in Atlanta, GA. Runs through May 12. As usual sysop's will get together and chat. 15 May 1989 Denmark changes telephone numbers from 7 to 8 digits. 19 May 1989 Start of EuroCon III at Eindhoven, The Netherlands. Contact Hans Ligthelm of 2:500/3 for details. 5 Jun 1989 David Dodell's 32nd Birthday 24 Aug 1989 Voyager 2 passes Neptune. 24 Aug 1989 FidoCon '89 starts at the Holiday Inn in San Jose, California. Trade show, seminars, etc. Contact 1/89 for info. 5 Oct 1989 20th Anniversary of "Monty Python's Flying Circus" 11 Nov 1989 A new area code forms in northern Illinois at 12:01 am. Chicago proper will remain area code 312; suburban areas formerly served with that code will become area code 708. If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- FidoNews 6-17 Page 32 24 Apr 1989 OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION Mort Sternheim 1:321/109 Chairman of the Board Bob Rudolph 1:261/628 President Matt Whelan 3:3/1 Vice President Bill Bolton 3:711/403 Vice President-Technical Coordinator Linda Grennan 1:147/1 Secretary Kris Veitch 1:147/30 Treasurer IFNA COMMITTEE AND BOARD CHAIRS Administration and Finance Mark Grennan 1:147/1 Board of Directors Mort Sternheim 1:321/109 Bylaws Don Daniels 1:107/210 Ethics Vic Hill 1:147/4 Executive Committee Bob Rudolph 1:261/628 International Affairs Rob Gonsalves 2:500/1 Membership Services David Drexler 1:147/1 Nominations & Elections David Melnick 1:107/233 Public Affairs David Drexler 1:147/1 Publications Rick Siegel 1:107/27 Security & Individual Rights Jim Cannell 1:143/21 Technical Standards Rick Moore 1:115/333 IFNA BOARD OF DIRECTORS DIVISION AT-LARGE 10 Courtney Harris 1:102/732 Don Daniels 1:107/210 11 Bill Allbritten 1:11/301 Mort Sternheim 1:321/109 12 Bill Bolton 3:711/403 Mark Grennan 1:147/1 13 Irene Henderson 1:107/9 (vacant) 14 Ken Kaplan 1:100/22 Ted Polczyinski 1:154/5 15 Scott Miller 1:128/12 Matt Whelan 3:3/1 16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628 17 Neal Curtin 1:343/1 Steve Jordan 1:206/2871 18 Andrew Adler 1:135/47 Kris Veitch 1:147/30 19 David Drexler 1:147/1 (vacant) 2 Henk Wevers 2:500/1 David Melnik 1:107/233 ----------------------------------------------------------------- FidoNews 6-17 Page 33 24 Apr 1989 __ The World's First / \ BBS Network /|oo \ * FidoNet * (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / Fido \ _//|| _\ / (________) (_/(_|(____/ (tm) Membership for the International FidoNet Association Membership in IFNA is open to any individual or organization that pays a specified annual membership fee. IFNA serves the international FidoNet-compatible electronic mail community to increase worldwide communications. Member Name _______________________________ Date _______________ Address _________________________________________________________ City ____________________________________________________________ State ________________________________ Zip _____________________ Country _________________________________________________________ Home Phone (Voice) ______________________________________________ Work Phone (Voice) ______________________________________________ Zone:Net/Node Number ____________________________________________ BBS Name ________________________________________________________ BBS Phone Number ________________________________________________ Baud Rates Supported ____________________________________________ Board Restrictions ______________________________________________ Your Special Interests __________________________________________ _________________________________________________________________ _________________________________________________________________ In what areas would you be willing to help in FidoNet? __________ _________________________________________________________________ _________________________________________________________________ Send this membership form and a check or money order for $25 in US Funds to: International FidoNet Association PO Box 41143 St Louis, Missouri 63141 USA Thank you for your membership! Your participation will help to insure the future of FidoNet. Please NOTE that IFNA is a general not-for-profit organization and Articles of Association and By-Laws were adopted by the membership in January 1987. The second elected Board of Directors was filled in August 1988. The IFNA Echomail Conference has been established on FidoNet to assist the Board. We welcome your input to this Conference. -----------------------------------------------------------------