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.)