Volume 5, Number 24 13 June 1988 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief Dale Lovell Editor Emeritus: 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. Copyright 1988 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. The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. We publish EVERYTHING received. Table of Contents 1. ARTICLES ................................................. 1 Everything You Always Wanted to Know About the #CM: Fla .. 3 Indios (A Network Yarn) .................................. 7 A proposed International Policy .......................... 10 Kids & Computers ......................................... 13 A Sample Net Policy Document Neal Curtin 1:343/1 ......... 16 Proposed Zone 1 Policy ................................... 23 2. COLUMNS .................................................. 36 What is the Price of ECHOMAIL ............................ 36 Top Downloads 5/27/88 - 6/3/88 ........................... 39 3. NOTICES .................................................. 42 The Interrupt Stack ...................................... 42 Latest Software Versions ................................. 42 And more! FidoNews 5-24 Page 1 13 Jun 1988 ================================================================= ARTICLES ================================================================= IDEAS FOR A NEW -AND BETTER- FIDONET (Let's make some changes...) Time goes by, and FidoNet grows every day faster. I don't think that, when creating the Fido Bulletin Board System, Tom Jennings knew he was starting something this big. I have lately read some articles, where sysops express their discomformity regarding the way things are going right now, specially with IFNA. Some sysops chose to form another, parallel net (like Ryugen Fisher, for example), some others just expressed their disappointness, and/or moved away from the "BIG net". Trhu this article, I want to give your my opinion, and to present you a new idea, a new idea that also contains new concepts. From my point of view, DEMOCRACY (not a "new concept"!) doesn't exist on FidoNet. And when one of the basic things needed for a large group to survive is not present, it is likely to fall in an anarchy, where everyone does what he/she wants, no matter what. When you live in a country that has a democratic constitution since 1853, and that while democracy lasted was one of the most rich and one of the TEN worldpowers and when it lost democracy, went from being THE RICHEST in the world to one of the poorest (yes, Argentina was *the richest* country in the world after WW2, and please, don't ask how it is right now...), you learn how important democracy is, for something to survive. I think something MUST BE DONE in FidoNet, before it is "too late". The FidoNet nodelist has already 3000+ members, in all the 5 continents of the world, on about 30 countries. FidoNet has become a totally INTERNATIONAL network, rather than an "American one with some nodes overseas". One of the main purposes of this new concept is to prevent the desintegration of FidoNet, as well as to make the actual conditions (a lot) better. In Latin America we are just starting with the net. There is still a "familiar climate" within the net, and everybody cooperates with each other, but as we read some echomail conferences or FidoNews, we ask ourselves: "Is it gonna happen the same way down here? Are we working so hard just to get to that point?". What I want to propose is the following: One "FidoNet Association" is created for each of the 4 zones (I'm assuming Latin America as Zone 4). Those associations may vary in their internal organization, since each zone's requirements and neccesities are very different. When they are finally established, each designates 3 members to take part on the International FidoNet Council, that is finally formed by those 12 representants of the 4 zones. FidoNews 5-24 Page 2 13 Jun 1988 Each zone has the right to have the presidency of the Council for 6 months a year (each has the right to preside the council once every two years). The Council's president must be one of the 4 representants sent by the zone who designates him/her, and has the right to a double vote when a votation is tied. The International Council is in charge of various things, like designating the International Technical Coordinator, setting the technical standards (either directly or by naming a "technical comitee"), publishing the net's official newsletter, and establishing the net's basic, international rules. Comprehensive rules are established by each zone's association. The International Council also acts as a "supreme tribunal" for interzonal disputes. Any disputes within a zone are to be arbitrated by the zone's association. The Zonal FidoNet Associations are to be TRANSPARENTLY DEMOCRATIC, which ensures the democratic qualities of the International FidoNet Council, as well as of the net itself. The Zonal Associations have the right to name the coordinators for all the networks, regions as well as the zone's. I personally think this idea has still to be shaped up. Anyway, the "main idea", that puts a special emphasis in democracy, as well as on each sysops' right to determine their coordinators, authorities and delegates to the main, International Council, is there. I would like everybody to participate in the development of this new idea, to ensure it's representability of all the sysop's wishes. Please, send mail to node 1200/1 with your opinions (in North America, you can send it thru 135/14 which is the gateway to Latin America). If FidoNet's current authorities, as well as IFNA's AND a large group of sysops consider the idea feasible, an echomail conference could be created to ensure everybody's participation on the development of this new idea. Thank you for taking the time to read this article, and thanks IFNA for maintaining a publication where everyone can express oneself freely. Pablo Kleinman (1:1200/1 aka 1:60/0) Sysop's Elected Latin American RC Buenos Aires, 28 de Mayo de 1988. ----------------------------------------------------------------- FidoNews 5-24 Page 3 13 Jun 1988 and then Some. Recently there has been a push to clean up the baud flags in the nodelist. It seems they often get misused and it also seems that sysops are not following any standard in their use or nomenclature. Apparently there is a host of new software becoming available that depends on the correct use and code for the baud flags, and so an effort is underway to get these nodelist flags cleaned up. Therefore, this seems like an opportune time to talk about the use of the #CM: flag. From my discussions with local sysops it would appear that the #CM: flag is greatly misunderstood and often misused. To begin with, the #CM: flag refers to "CONTINUOUS MAIL" capability, not "CRASH MAIL" capability. There is a distinct and important difference. Many sysops are running bulletin board and/or mailer software that supports CRASH mail, but do not have their systems available for incoming mail 24 hours per day. The #CM: flag means that you are able to accept mail anytime day or night, 365 days out of the year (barring unforeseen acts of God, or nuclear holocaust). In other words, to qualify for the #CM: flag, you have to have CRASH mail capability AND be running a system that accepts incoming mail at all times. The above description would probably get you past the FIDONET boarder patrol in terms of qualifying you for the #CM: flag, but there is more to consider. A #CM: "purest" would argue that to REALLY qualify, you would have to be able to release any outgoing mail destined for a system that happens to call your system delivering mail. For example, lets say you are system X/1 and have some mail to go out to system Y/1. Your outgoing mail for Y/1 has not been labeled as CRASH mail. Your intent is for the mail for Y/1 to go out during your next regularly scheduled mail event (perhaps National Mail Hour). But prior to your next mail event, system Y/1 happens to call your system to deliver mail (completely unaware that you have mail for him). The ideal #CM: system would release the mail to Y/1 at that time, eliminating the need to wait until X/1's (your) next mail event, and also preventing X/1 (you) from picking up the cost for the mail intended for Y/1. Having this kind of continuous mail capability requires a little more routing finesse. In order to build a system with this "mail releasing" capability requires you to have outgoing mail "bundled" at all times because you cannot predict when a call will come in for which you happen to have some outgoing mail. How do you do that? It is really quite easy. The following description refers to how I do it using SEAdog. I am sure there are other ways to accomplish the same thing (perhaps even better ways, though I doubt it). I do not know how this would be accomplished using OPUS, or Binkley, or any of the myriad other mailer programs. I only speak SEAdog, I've never learned OMMM (is that some mystical East Indian mantra???). You'll have to suffer through someone else's description of this stuff to learn how to do it with other software. FidoNews 5-24 Page 4 13 Jun 1988 The idea, as I said before, is to have all outgoing mail bundled and to give SEAdog permission to release all outgoing mail at all times. With this in mind, the routing commands are straightforward: Hold All Send-to All Give-to All This combination of routing statements bundles all of your outgoing mail with a "hold" flag on each parcel, and gives SEAdog permission to release any parcel when the destination system happens to call in. Now, all that remains is to give this set of commands a routing tag and stuff that Schedule in between all your other events. Lets say you give this set of commands the Schedule J tag (that just happens to be the tag I am using for this purpose). Now lets say a segment of your CONFIG.DOG looks like this: event X40 All 01:00 ;some external event event C All 01:00 02:00 ;a 1-hour mail event event D All 03:00 04:00 ;another mail event You have an hour in there (from 2 until 3 in the AM) when you are not in a mail event. You are going to want to stuff your Schedule J in there so that, if a system for which you have outgoing mail happens to call during that time period, your mail to him will be released. The revised CONFIG.DOG segment would look like this: event X40 All 01:00 ;some external event event C All 01:00 02:00 ;a 1-hour mail event event J All 02:00 03:00 ;HERE'S THE BEEF event D All 03:00 04:00 ;another mail event As described in the preceding example, you would go through your entire schedule of events in CONFIG.DOG and stuff "event J" in between all of your other events such that you are running "event J" at all times that you are not involved in some other scheduled event. There are a couple of other considerations: Most of you probably are running a bulletin board as well as running a mailer, and want the ability to have incoming "human" callers (although I have heard more than one sysop say that they could run a really neat BBS if people would just stop calling it...). Remember to add the "BBS" statement in conjunction with each "event J" so that SEAdog will know to relinquish control to your BBS when a human calls in during one of those events. event J All 02:00 03:00 BBS ^^^ Secondly, you are likely to have large blocks of time where you have no other scheduled events and will want to be running "event J". For example, I don't have any events to speak of on FidoNews 5-24 Page 5 13 Jun 1988 my board between 6am and midnight the following day. It is possible to put one "event J' in there to fill in that entire block of time. However, that is not extremely desirable because it limits your use of CRASH mail events. Let me give you an example. Lets say it's noon and I'm on my lunch break (one of the few times during the normal business day when I get to play with my bulletin board). I decide to send some CRASH mail, so I compose the messages and attach the CRASH flag, then go and eat my day-old tunafish sandwich. The system will go about its business attempting to send out my messages, but if the destination system happens to be busy and the mail does not go through, then "event J" would be re-installed and the system would not attempt to send the CRASH mail again until the next time I have a scheduled event, which in this fishy example, is not for several more hours. The way around this problem is to avoid an "event J" that covers multiple hours. Instead, start a new schedule J every hour when you have large blocks of time in the day without other scheduled events. Here is an example of another segment of my CONFIG.DOG that demonstrates this: event J All 12:00 13:00 BBS event J All 13:00 14:00 BBS event J All 14:00 15:00 BBS ...and so forth and so on Oh...if that weren't enough... to bore you even further with additional trivia about the #CM: flag, there is one more consideration that comes to mind. We need to turn this thing around and look at it from the opposite direction. Lets say you are sending out CRASH mail and the destination system happens to have mail waiting for you to pick up, and the sysop of that destination node has read this silly article and has sprinkled "event J's" throughout his CONFIG.DOG. His mail for you is properly bundled and waiting for your call, and his SEAdog has permission to release mail to you if you happen to call in. Unfortunately, if you are using SEAdog's predefined "Schedule S" for your CRASH mail event, you won't pick up your mail even if the sysop of the destination node has gone to the trouble to set it up this way, because SEAdog's Schedule S is defined as "Send- only" (that's what the "S" in Schedule S stands for guys). So your system will not look for mail addressed to you when it's out delivering your CRASH mail. There is a quick fix to this problem however. Simply define a "Schedule S" in your ROUTE.DOG and give it one simple command: Schedule S Pickup All If you follow the above suggestions, you will have a system that truly qualifies you for the use of the #CM: flag. You will accept incoming mail at all times, you will have outgoing mail bundled and will release those mail packets if they are addressed to incoming "mail" callers, and you will pick up mail FidoNews 5-24 Page 6 13 Jun 1988 addressed to you when you are sending out CRASH mail. Remember, the #CM: flag is preceded with the "#" sign. It is one of a group of baud flags that indicate the time of day your system is available for incoming mail. The other members of this group reflect the beginning of an hour in Greenwich Mean Time: #09: Accepts incoming mail beginning 0900 GMT #18: Accepts incoming mail beginning 1800 GMT ...and #CM: Accepts incoming mail any ol' time and lastly (as if that weren't enough), remember that the #CM: flag is followed with a colon (:). All baud flags are followed with a colon. If you have several baud flags assigned to your system, they should be separated by a comma. For example, the baud flags for my system are: XP:,#CM: Next month we'll talk about the XP: flag (gag! belch!...) Dave Davidson OPTOMETRY ONLINE 100/514 (Region 14 Coordinator) ----------------------------------------------------------------- FidoNews 5-24 Page 7 13 Jun 1988 James Zachary 445/2 Indios (A Network Yarn) (c) 1988 James Zachary "JERKS!" Ron jumped up from his desk and began pacing furiously. "Stupid self-serving twits!" he bellowed at his computer screen. A shadow in the doorway startled him. "Indios? Oh! I wasn't ... I mean ... sorry if I disturbed you." Indios was the caretaker and general handyman for the condominium complex where Ron lived. Rarely did he pay much attention to anything other than his duties. "Your sink is fixed." he said with his deep, gravely voice. "What upsets you?" the old Indian then asked through lips that barely moved. "Ahhhhh, I dunno! I am sick and tired of everyone treating me like dirt!" His dark, withered face frowning, Indios shuffled his large frame to an overstuffed chair and sat down. "How do they do this? I am not understanding." Ron was surprised. In over 2 years he had never known Indios to solicit a conversation. "Well, some people are real idiots and think they know it all. They like to lord over other people, pretending they are smarter or better. All they really have are big mouths! I am going to start defending myself! I am going to be more assertive!" "Tell to me the difference of you being 'assertive' and them having 'big mouths'?" Indios asked without expression. Ron did not answer. "You sit in front of this for hours," Indios continued, pointing to the computer on Ron's desk, "and it angers you. How can this be?" "It started off to be fun," Ron answered, "then everyone started flaming at each other!" Ron could see that he was only confusing Indios. FidoNews 5-24 Page 8 13 Jun 1988 "See, with the computer, a bunch of people can leave messages to each other. It's like a big hobby for computer buffs. There is an amateur network that I belong to where we can leave mail. It was fun until it became too crowded. Now everyone just fights with each other. If someone misspells a word, someone jumps on him. If someone asks a question or has an idea that someone else thinks is stupid, then the name calling starts. We call it 'flaming'." Indios grunted and nodded that he understood. "So, you meet people on your machine so you can get angry at each other. You go to work and your clubs and get angry at others. Driving your car makes you angry at others ..." "Exactly!" Ron exclaimed. "Unless you stand up for yourself, someone will walk all over you! Believe me, when someone shoves it to me I am going to pay them back in spades!" The Indian brushed his long, white hair back with his weathered hands and looked sadly at Ron. "So much anger ... This will make you better than them? Anger can at times be a tool but, like a surgeons knife, it should only be used when all else has failed and the cause is just ... only then with great care and control. Most swing this blade recklessly and wound themselves." "I am sick and tired of reading this crap! I am sick and tired of these pious bastards jumping on every little thing I do!" "Maybe they have a fear ... maybe they have a need. The smallest pups always growl the loudest. The others that are secure will allow this because they know these pups have needs that only can be provided for by their pretending dominance. Even with wolves, the strongest and fastest in the pack will allow the pretenders their moments, as they know it is their need and all they can really achieve." Now Ron was puzzled. "You mean I should just ignore these twinks?! That I should let them say vile things about me and others?!" "Do they strip you of your honor? Are you denied all dignity? Your family was not threatened, your ability to provide for those that depend on you was not threatened ... your honor was not taken." "I have my pride!" "Pride is not honor. You must know when NOT to fight before you will ever know when it is proper TO fight. Your words of anger are that of a child. Show me the burial sites of those killed by mere words ..." Ron knew he was losing the debate. This one was face to face FidoNews 5-24 Page 9 13 Jun 1988 and the words had texture, tone and emphasis ... not like text written on a flat monitor screen. "Take what is good with this and all else in life and leave behind what is bad." Indios continued, leaning forward, his eyes fixed in a gaze at Ron. "I know enough about you to say that you were granted neither the natural gift of a powerful body nor a powerful mind at birth. You were granted a more valuable gift, the gift to build whatever body and mind you choose. There are no boundaries for this gift. All you do, every day, in all walks, makes you what you are and what you will be." Indios then stood and walked to the doorway. Ron remained silent. "Will you build your body and soul of sound materials or will you use the waste of the earth and become all that you despise?" Indios asked with a hint of a smile as he departed. Ron strolled slowly back to his desk and sat down in front of the computer. He hit a key to awaken his blank screen and then began rereading the message that had upset him earlier. After a moment he moved on to the next message, leaving the hate unanswered. "We're just puppies ... " he mumbled under his breath. "I guess Fido grew up and had a whole lot of puppies ..." He then began a reply to a message from a friend in Puerto Rico. "Take what is good ..." ----------------------------------------------------------------- FidoNews 5-24 Page 10 13 Jun 1988 Neal Curtin 1:343/1 Proposed International Policy Section I: FidoNet 1. What is FidoNet FidoNet is the worldwide collection of Bulletin Boards that operate under a protocol established by Tom Jennings called Fido. The basic structure of the network is as follows, from the lowest point to the highest. POINT: A point is the lowest subdivision, and is a system that is mail only and will only connect to a parent or BOSS node. It is not listed in the nodelist. NODE: A node is the lowest public position in the nodelist. It is normally a fully functional system that can act as a bulletin board and also send and receive mail and files. HUB: A hub is a system which is set up to provide a service to a small group of nodes that is a sub geographical group of a net. NET: A net is a geographical collection of Nodes that has banded together in order to share common interests or reduce costs. REGION: This is a collection of nets and independent nodes that are contained in a larger geographical or geopolitical entity. The net may also be a special interest group. ZONE: The zone is a larger collection of regions and nets. Currently there are three zones, zone1 is North and South America, zone2 is Europe and Africa, and zone3 is Australia and the South Pacific area. There are additional zones, but these are large networks that do not want to directly participate in the FidoNet Nodelist. They are zone7, AlterNet, and zone99, GoodEggNet. Communication can be established with these zones either by means of zone gates or by including them in your local nodelist. SECTION II: LEVELS OF FIDONET The FidoNet Network is broken down into many different levels much as the hierarchy within any efficient organization. Thru past history, the following hierarchy has developed: 1. All System Operators (SysOps) taken collectively (FidoNet). This is the highest level of the structure, and represents the entirety of FidoNet. FidoNews 5-24 Page 11 13 Jun 1988 2. International Coordinator (IC) This position is an administrative position and is responsible for the publication of the Nodelist. The IC is also the court of last resort in disputes between zones. 3. Zone Coordinator (ZC). This position oversees one Zone of FidoNet and is responsible for the smooth functioning of FidoNet within that Zone. The ZC is the court of last resort within his zone, unless the dispute is inter zonal in nature. 4. Regional Coordinator (RC). This position oversees one Region within a Zone and is responsible for the smooth functioning of FidoNet within that Region. 5. Network Coordinator (NC). This position oversees one Network in one Region and is responsible for the smooth functioning of FidoNet within that Network. 6. SysOp. This is the singular unit of FidoNet. The SysOp runs his or her own FidoNet capable software such that their system can function as part of FidoNet within the guidelines imposed by the various levels of FidoNet above the SysOp level. Those guidelines are formulated over time as defined in this document. SECTION III: RESOLUTION OF DISPUTES Disputes are bound to arise, and the solutions are many. This document is cover only disputes which are between zones. Each zone is to develop it's own policy statement for disputes within it's own area, and each region/net is encouraged to set up it's own policy, not to conflict with a higher policy. 1. A zone council will be set up comprised of three regional coordinators from within each zone. In case of a dispute between zones, a disinterested zone will be selected to act as a court. Each zone will submit their side of the dispute, not to exceed 10 pages, to the selected zone council. The zone council shall then make their decision with 10 days of the submittal. The majority rule applies. Appeals may be made to the IC, who may also form a council. The IC decision will be final, and there will be no further mediation. 2. The IC council will consist of at least 2 regional coordinators from each zone. They will review the same submittal as the zone council received, and will make their decision in 10 days. SECTION IV: POLICIES Each zone is responsible for setting up a zone policy. This policy will detail the requirements for a Zone Mail Hour (ZMH), the handling of echo mail, the responsibilities of the various regional coordinators, and any special conditions which may exist. FidoNews 5-24 Page 12 13 Jun 1988 Section V: INTERNATIONAL COORDINATOR Because of the high position of trust that the IC must hold, the position must be filled by someone who has not only the technical qualifications, but must also be free from political constraints. For this reason, the IC must not hold any other position with the entire FidoNet community. When the position becomes vacant, the senior ZC will assume the position until a new IC can be elected. The election procedures are as follows: 1. The RC's will nominate a slate of potential candidates from within their zone. These candidates will then be proposed to all the NC's, RC's within the zone will elect one candidate for a inter zonal election. 2. The candidates from the zone elections will then submit their position in the FidoNews for reading by all the members of the community. The election will then be held. 3. The time frame for the election of the IC must be short, and should be accomplished within 30 days. 4. Voting will be done by nets, regions, and zones. Each net will hold an election process, results to forwarded to the Region. The Regional independents will vote through the RC. The RC will forward the Region vote to the ZC. Only votes will be counted. Abstensions will not count. A pure majority will decide the outcome. RECALL procedures. 1. A recall can be initiated at any level. 2. A majority in a net or a region or a zone is required to start a recall election. The recall election will be conducted in the same manor as the IC election, but will be a yay or nay vote only. Upon completion, the IC must abide by the decision. 3. Each operating area will only be able to start one protest per year. ----------------------------------------------------------------- FidoNews 5-24 Page 13 13 Jun 1988 Claude Witherspoon Fido 100/525 KIDS ECHO CONFERENCE GUIDELINES 1. PURPOSE: The purpose of this document is to deleniate responsibilities, guidlines, and proceedures for the users of the KIDS Echo Conference. 2. SCOPE: The KIDS Echo Conference was established to allow young people up to the age of 18 to have freedom of information interchange in an environment that is directed primarily toward an adult audiance. Allowing our children to have an area of thier own is necessary to give our kids the opportunity to expand their capabilities in the age of electronics and home computing. Our children are our most valued resources in the persuit of a future for a nation with strong goals in computers. Our future belongs to them. They are our destiny. The KIDS Echo Conference was designed with them in mind. Therefore, each adult should encourage its use and give it direction. Direction without interferance except to insure that the echo is wholesome and that it grows with common decency as viewed by the public as a whole. 3. GENERAL: Teachers are encouraged to allow students to send traffic such as Pen-Pal letters, history, trivia, and anything that will encourage and assist in the growth of their students. Utilize the echo as a training aid limited only by your knowledge and immagination. Encourage the exchange of information between students of different geographical locations for computer science, history, cultures, etc. Spread the knowledge of this echo to local school boards and faculty for future projects in computer science and as a aid in the students growth in a nation with multiple goals in the arena of computer science. Parents are encouraged to assist thier children in the utilization of this echo. This will develope healthy computing habits and keep the echo interesting for the children. Parents are also encouraged to promote the echo at school meetings like the Parent Teachers Accosiation (PTA), open house funtions at the schools, and through any medium that will assist the growth of thier children in this area. Users are encouraged to submit suggestions, comments, and ideas to help with the growth of this echo. The users are the heart of the echo and its existance is dependant upon your utilization of it. Promote a healthy environment which is suitable for children. Use peer pressure as necessary to stop any misuse of the echo. Remember the children of this great nation are our future and they hold the key to the advancement of a nation with strong goals in the computer field. 4. RESPONSIBILITIES: FidoNews 5-24 Page 14 13 Jun 1988 a. SYSTEM OPERATORS (Sysops): Sysops that request and allow the KIDS Echo Conference on thier Bulletin Board System must monitor the echo to insure thier users do not abuse other users or the echo as a whole. This includes reporting any misuse that the sysop cannot control to the Net Coordinator or Echo Moderator as necessary. Sysops will not allow foul language for any reason, missuse of the echo by adults and children alike, and not allow what is commonly known as "Flames". If a user utilizes the KIDS echo for message traffic that is better served by another echo, then the sysop will direct that user to the appropriate area/echo. b. USERS: Users are responsible for the echo as a whole. Therefore, misuse by the users can cause the termination of the echo in part or as a whole. You must insure that foul language is not tolerated and not used. Peer pressure is your tool. Tell another user that he/she is incorrect in using foul language and that this echo is directed toward children under the age of 18. If the other user continues, report it immediately to the System Operator. This can be done in private as necessary. If the sysop does nothing in a reasonable leangth of time, report the problem to the Net Coordinator or to the Echo Moderator. You must utilize the echo in the context of its design. Keep a healthy acceptable attitude and enter messages that are suitable for the children that use the echo. Promote the free exchange of information and discourage misuse. Traffic such as love letters, private messages, sexual remarks, racist remarks, religous comments, and "Flames" are forbidden in this echo. There are other echoes that allow that kind of abuse or harrasement (Go there!). Wars are not allowed i.e. Johnny picking on Joe, Grade 12 verses grade 6, Texas against Porta Rico, country against country, unless they are in the context of learning and then they must be from the text book approved by the Educational Departments. 5. GENERAL INFORMATION: The following information is submitted for your use as necessary: a. KidsNews Newsletter: The kidsNews newsletter was created by Brandy Witherspoon, age 13, of Edwardsville, Illinous, Net/Node 100/525. She is the Editor and Chief of the newsletter and has done an outstanding job in its content. The newletter is maintained and utilized by the users of the KIDS echo in sharing information, ideas, articles, editorials, programs, trivia, etc. for the audiance which the echo is designed for (kids 18 and below). Distribution of the newsletter can be arranged through the Echo Moderator or Echo Coordinator. If you would like to submit articles in the newsletter, send it in the KIDS echo area or through NetMail to Claude Witherspoon, 100/525. This will ensure your article is included in the newsletter in a timely manner. b. Echo Coordinator: Paul Witherspoon, Net/Node 19/42, San FidoNews 5-24 Page 15 13 Jun 1988 Angelo, Texas. Data-(915) 949-5645. c. Echo Moderator: Claude Witherspoon, Net/Node 100/525, Edwardsville, Illinois. Data-(618) 656-5447. 6. These guidelines are just that "Guidelines". The success or failure of the KIDS echo is dependant upon your use or misuse of the echo. Please give comments and thoughts of a constructive nature to the Echo Coordinator and Echo Moderator on any topic that has been covered here. You will recieve a reply I assure you. Thank you for your time and attention in reguards to the echo. I hope to be talking with most of you in the future. Claude Witherspoon Net/Node 100/525 KIDS Echo Moderator ----------------------------------------------------------------- FidoNews 5-24 Page 16 13 Jun 1988 F I D O N E T Policy and Procedures Guide Net 343 version Version 1 Chapter 1 OVERVIEW 1.1 The Levels of the Net The Net is grouped on several levels. These are as follows: o Network; The network is a collection of nodes, specifically the city and surrounding territory of Seattle, reachable from the central area of Seattle by a no-charge fee from Pacific Northwest Bell. o Hub; Any Hub will be an extension of the network coordinator so as to increase the calling capability, or to extend the net into a new area, until such time as they may be able to form their own net. Hubs will be established for Echomail, and for other purposes as may arise. o Node; A node is a single FidoNet address, and is the smallest recognized unit of FidoNet. o Points; A point is a node on a private network which is accessible through a node on FidoNet. 1.2 Coordinator o The Network Coordinator; A Network Coordinator maintains the list of any nodes in his network that are not served by a hub and accepts node lists from the Hub Coordinators in his network. He compiles these lists to create a network node list for his network, which he then sends to his Regional Coordinator. A Network Coordinator is also responsible for forwarding any mail addressed to nodes in his network. o The Hub Coordinator; A Hub Coordinator maintains the list of nodes in his hub and sends it to his Network Coordinator. A Hub Coordinator is also responsible for forwarding any mail addressed to nodes in his hub. o The Echo Coordinator; The node in the net that acts as a FidoNews 5-24 Page 17 13 Jun 1988 gateway to the regional echo coordinator. The Sysop (or system operator) of that node then acts as the coordinator for the network. This Sysop will be responsible for the coordination and distribution of all echo mail within the net. Cooperation with the net coordinator is expected, but is not required. The final decision on echo distribution will reside with the echo coordinator. o The Sysop; A Sysop formulates his own policy for running his board and dealing with his users, so that will not be discussed in this document. However, a Sysop must also mesh with the rest of the FidoNet system if he is to send and receive mail, and that will be discussed here. The primary responsibility of any coordinator is technical management of network operations. Management decisions should be made strictly on technical grounds. SYSOP Procedures A sysop of an individual node can pretty much do as he pleases, as long as he observes the mail events, is not excessively annoying to other nodes on FidoNet, and does not promote the distribution of pirated copyrighted software. National 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 at this time. NMH is defined as 1 AM to 2 AM, pacific STANDARD time. This does not vary with daylight savings time. Additional time for mail within the net is from 2 AM to 2:30 AM PST. This is to allow for any mail received by the host (Coordinator) to be distributed. THIS TIME IS TO BE A RECEIVE ONLY TIME. Only the host will be sending during this time. During NMH and the net mail time, no users (callers) are allowed. Failure to observe the proper mail events is sufficient grounds for any node to be dropped from FidoNet without notice (since notice is generally given by FidoNet mail). 2.1 How to get a node number You must first obtain a current node list so that you can send mail. You do not need a node number to send mail, but you must have one in order for others to send mail to you. Once you have a node list, you must then send Net mail to the host, 343/0, during NMH. Your application for a node number must be sent to the coordinator by FidoNet mail, and must include at least the following: 1) Your name. 2) The name of your system. 3) The city and state where your system is located. FidoNews 5-24 Page 18 13 Jun 1988 4) The phone number to be used when calling your system. 5) Your hours of operation. 6) The maximum baud rate you can support. 2.2 If you are going down If your node will be down for an extended period (more than a day or two), then you should inform your coordinator as soon as possible. If you do not do this, then other systems will still try to reach you while you are down, much to the annoyance of everyone. Do not under any circumstances put an answering machine or similar device on your phone line while you are down. If you do, then calling systems will get the machine repeatedly, racking up large phone bills, which is very annoying. See the section on Resolution of Disputes for details on what happens to annoying people. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your coordinator. Systems do have a tendency to "crash" now and then, so you will probably want your coordinator to know that it is a temporary condition if it happens while you are away. COORDINATOR PROCEDURES This chapter describes the procedures followed by the coordinator at the NET level. The coordinator has four primary duties. In order of decreasing importance, they are: 1) Administrative tasks. 2) Node list distribution. 3) Newsletter distribution. 4) Network mail distribution. At first glance it would seem that network mail distribution should be the highest priority, since after all that's why we're running a network in the first place. But the first three priorities are needed to ensure smooth operation of the network, and hence must have a higher priority. Administrative tasks First and foremost, every coordinator is also the sysop of his own node. It must be possible for others to reach you by network mail. So in addition to the other tasks of a coordinator, you must also observe all of the requirements for being a node. FidoNews 5-24 Page 19 13 Jun 1988 Maintaining the node list A coordinator at any level must maintain his portion of the node list. Almost any coordinator will have some nodes in his node list which are not a part of any subgroup. For example, a Zone Coordinator must maintain a list of administrative nodes for his zone, and a Regional Coordinator must maintain a list of independent nodes in his region. A Hub Coordinator (or the Network Coordinator in a network without hubs) must maintain the list of all nodes in his area. A coordinator is responsible for seeing to it that his portion of the node list is kept reasonably accurate. You should attempt to implement name changes, phone number changes, and so forth in this node list as soon as possible. You should also check from time to time to ensure that all of the listed nodes are in fact capable of accepting network mail. How best to accomplish this is left to your discretion. Assigning node numbers A node number will not be assigned until a formal request from that system has been received by FidoNet mail. This will ensure that the system is at least minimally operational. Additionally, that system will be checked to ensure that it can receive both mail and files. Before accessing echomail, the system will have to demonstrate that it can use the echomail system by using the local NET343 echo. The strict maintenance of this policy has been one of the great strengths of FidoNet. Network mail will be used to inform a new node of his node number, as this helps to insure that he is capable of receiving network mail. Problem resolution If the problem is caused by a node within the net, then you will contact the net coordinator, who will attempt to resolve the problem. If the problem is outside of the net, then you should contact the coordinator of the other net, but be sure that you send a copy of the complaint to your own coordinator. If the problem is with the region, send the complaint to the network coordinators concerned, and to the regional coordinator. Any complaints received by the network coordinator will be forwarded to the regional coordinator for information purposes. Formulating local policy It is your responsibility to formulate any local policies which are required for the smooth operation of your assigned area. Any policies you establish must not conflict with any policies established by a coordinator above you or with this policy document. FidoNews 5-24 Page 20 13 Jun 1988 Node list distribution The node list is posted weekly on Saturday, along with a "difference file" giving the changes for the week. The nodediff will be distributed to each node as soon as possible. It is recommended you make it available for download by the general user, but this is not required. 3.3 Newsletter distribution The newsletter, called FidoNews, is published weekly on Monday and is distributed as an archive named FNEWSvnn.ARC, where "v" is the volume number and "nn" is the issue number. It will be distributed in the same manor as the nodelist. It is also desirable that you make it available for download by the general user in both archive an non archive form, but this is not required. Anything else You should encourage sysops and users in your region to contribute to FidoNews. If you receive any submissions, you should forward them to the FidoNews publisher. Think of yourself as being a regional bureau chief on the FidoNews editorial staff. FidoNews and the node list are the glue that holds us together. Without them, we cease to be a community, and become just another random collection of bulletin boards. Specific coordinator procedures A Network Coordinator is responsible for assigning node numbers to any nodes within his network which are not managed by a Hub Coordinator. A Network Coordinator is also responsible for allocating any hubs within his network and for appointing a Hub Coordinator for each hub. If a Network Coordinator assigns any Hub Coordinators, then he also assigns a pool of numbers to each Hub Coordinator for use in assigning node numbers. It is the responsibility of a Network Coordinator to receive all inbound mail for nodes in his network and to forward it to its recipients. How to accomplish this is left to the discretion of the Network Coordinator. However, there are a few exceptions: 1) Once in awhile a node will try to make a "bombing run" (sending one message to a great many nodes). Bombing runs are considered to be annoying, and will be cause for a formal complaint. 2) Occasionally a user will appear who receives a great deal of traffic. If a single node is receiving enough mail to interfere with mail delivery to the other nodes in his FidoNews 5-24 Page 21 13 Jun 1988 network, then his Network Coordinator can refer him to his Regional Coordinator for reassignment as an independent node. A Network Coordinator is responsible for assigning any additional mail events which may be required for operation of his network. Any node in a network may be excommunicated for failing to observe these additional mail events. A Network Coordinator may appoint a node as the outbound gateway for his network if he so desires and if one can be found. In no case should a node be appointed as an outbound gateway unless the sysop of that node is willing and able to provide reasonably reliable service. Note that a Network Coordinator is not required to appoint an outbound gateway. If a Network Coordinator chooses to appoint an outbound gateway, then it is left to the Network Coordinator to establish any rules, policies, and procedures relating to its use. Hub Coordinator procedures A Hub Coordinator is responsible for assigning node numbers to nodes in his area. Each Hub Coordinator will be assigned a pool of numbers to use when assigning node numbers. A Hub Coordinator should never assign a node number outside of this pool, and should never assign the same number to more than one node. If a Hub Coordinator assigns all of the numbers in his pool, he should apply to his Network Coordinator for additional numbers. It is the responsibility of a Hub Coordinator to receive all inbound mail for nodes in his hub and to forward it to its recipients. How to accomplish this is left to the discretion of the Hub Coordinator. However, the same exceptions apply here as for a Network Coordinator. A Hub Coordinator may have additional duties, as assigned by his Network Coordinator. RESOLUTION OF DISPUTES The world not being perfect, sometimes troubles crop up. Any organization larger than a cub scout pack needs some sort of grievance procedure, and FidoNet is no exception. 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 FidoNews 5-24 Page 22 13 Jun 1988 dispute both sides are examined, and action could be taken against either or both parties. ("Judge not, lest ye be judged!") In any case of annoying behavior the person to complain to is the coordinator of the person who is annoying you. For example, if you have a problem with a point or a user you would complain to his sysop, or if you have a problem with a Regional Coordinator you would complain to his Zone Coordinator, and so on. If the coordinator you complain to fails to resolve the problem, then you can complain to his coordinator. For example, if you had a problem with a Hub Coordinator, you would first complain to his Network Coordinator. Then if the Network Coordinator does not resolve the problem, you would complain to his Regional Coordinator. Do not ever skip over a coordinator when filing a complaint. That in itself is annoying. This net shall be the one noted for non-flames. No one in this net shall flame another in the net. If you are thinking of flaming someone outside the net, be forewarned, a complaint filed against you by someone outside the net, will be taken seriously, and steps will be taken. We are friendly, loyal, trustworthy, and HONEST. ----------------------------------------------------------------- FidoNews 5-24 Page 23 13 Jun 1988 Neal Curtin 1:343/1 F I D O N E T Policy and Procedures Guide Zone 1 version Version 0.001 * * * P R O P O S A L * * * Chapter 1 OVERVIEW FidoNet is an amateur electronic mail system. As such, all of its participants and operators are non-paid volunteers. From its early beginnings as a few friends swapping messages back and forth, it has now grown to (August 1987) over 2000 different systems on four continents. 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. Multi net operation provides the structure. Decentralized management provides the control. This document is an attempt to describe the procedures which have been developed to manage the network. 1.1 The Levels of FidoNet FidoNet nodes are grouped on several levels. These are as follows: o FidoNet; This indicates the entire public amateur mail network, as administered by the International FidoNet Association, and as defined by the weekly node list. o Zones; A zone is a large geographic area containing many regions, and covering one or more countries and/or continents. o 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. o Networks; A network is a collection of nodes, usually in a relatively small geographic area. Networks coordinate their mail activity to decrease cost and increase mail throughput. FidoNews 5-24 Page 24 13 Jun 1988 o Hubs; A hub is a subdivision of a network that assists in network management by routing mail to, and by coordinating for, a collection of nodes in that network. In general only the larger networks will have hubs. o Nodes; A node is a single FidoNet address, and is the smallest recognized unit of FidoNet. o Points; A point is a node on a private network which is accessible through a node on FidoNet. 1.2 Coordinators Each subdivision at each level is managed by a coordinator. A coordinator is a person who coordinates the technical aspects of network mail. This entails both administrative and technical tasks, which will be described later. The following levels of coordinators are currently recognized: o The International Coordinator; The International Coordinator compiles all of the node lists from all of the regions and creates the master node list, which is then distributed over FidoNet. o The Zone Coordinator; A Zone Coordinator maintains the list of administrative nodes in his zone and accepts node lists from the Regional Coordinators in his zone. He compiles these lists to create a zone node list, which he then sends to the International Coordinator for inclusion in the master node list. A Zone Coordinator is also responsible for overseeing any zone gateways in his zone. o The Regional Coordinator; A Regional Coordinator maintains the list of independent nodes in his region and accepts node lists from the Network Coordinators in his region. He compiles these lists to create a regional node list for his region, which he then sends to his Zone Coordinator. A Regional Coordinator does not perform routing services for any nodes in his region. o The Network Coordinator; A Network Coordinator maintains the list of any nodes in his network that are not served by a hub and accepts node lists from the Hub Coordinators in his network. He compiles these lists to create a network node list for his network, which he then sends to his Regional Coordinator. A Network Coordinator is also responsible for forwarding any mail addressed to nodes in his network. o The Hub Coordinator; A Hub Coordinator maintains the list of nodes in his hub and sends it to his Network Coordinator. A Hub Coordinator is also responsible for forwarding any mail addressed to nodes in his hub. o The Point Coordinator; Any node in FidoNet can act as a gateway to a point network. The Sysop (or system operator) of FidoNews 5-24 Page 25 13 Jun 1988 that node then acts as the coordinator for his point network. o The Sysop; A Sysop formulates his own policy for running his board and dealing with his users, so that will not be discussed in this document. However, a Sysop must also mesh with the rest of the FidoNet system if he is to send and receive mail, and that will be discussed here. 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 strict top-down manner. That is, a coordinator at any given level is responsible to the coordinator immediately above him, and responsible for everyone below him. For example, a Regional Coordinator is solely responsible to his Zone Coordinator for anything that may or may not happen in his region. From the point of view of the Zone Coordinator, the Regional Coordinator is totally and completely responsible for the smooth operation of his region. Likewise, from the point of view of the Regional Coordinator, the Network Coordinators are totally and completely responsible for the smooth operation of their networks. If a coordinator at any level above sysop is unable for any reason to properly perform his duties, he can be replaced by his coordinator at the next level up. For example, if a Regional Coordinator is failing to perform his duties, then his Zone Coordinator can appoint a new Regional Coordinator to replace him. The primary responsibility of any coordinator is technical management of network operations. Management decisions should be made strictly on technical grounds. Chapter 2 SYSOP PROCEDURES A sysop of an individual node can pretty much do as he pleases, as long as he observes the mail events, is not excessively annoying to other nodes on FidoNet, and does not promote the distribution of pirated copyrighted software. National 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 at this time. A system which is a member of a network may also be required to observe additional mail events, as defined by his Network Coordinator. FidoNews 5-24 Page 26 13 Jun 1988 Failure to observe the proper mail events is sufficient grounds for any node to be dropped from FidoNet without notice (since notice is generally given by FidoNet mail). Network mail systems generally operate unattended and place calls at odd hours of the night. If a system tries to call an incorrect or out of date number, it could cause some poor citizen's phone to ring in the wee hours of the morning, much to the annoyance of innocent bystanders and civil authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the node list as is practical. A system which has been dropped from the network is said to be excommunicated (i.e. unable to communicate). A node which has been excommunicated may or may not be listed for a time in the "dog house", which is included in the comments at the end of the node list. If you find that you have been excommunicated without warning, then that means that your coordinator was unable to contact you. You should rectify the problem and report back. The exact timing of National Mail Hour is set for each zone by the Zone Coordinator. In zone 2 National Mail Hour is observed from 0900 to 1000 GMT every day, weekends included. FidoNet does not observe daylight savings time. In areas which observe daylight savings time the FidoNet mail schedules must be adjusted in the same direction as the clock change. Alternatively, you can simply leave your system on standard time. 2.1 How to get a node number You must first obtain a current node list so that you can send mail. You do not need a node number to send mail, but you must have one in order for others to send mail to you. The first step in obtaining a current node list is to locate a FidoNet bulletin board. No help there; you're on your own. Most bulletin board lists include at least a few FidoNet systems, and usually identify them as such, so this shouldn't be too hard. If the sysop of any FidoNet system does not have a node list available for downloading, then he can probably tell you where to get one. Once you have a node list, you must determine which coordinator to apply to. The coordinator of any network or region is always node zero of that network or region. A Hub Coordinator will always be indicated in the node list by a "HUB" prefix. You should apply to the lowest-level coordinator that covers FidoNews 5-24 Page 27 13 Jun 1988 your area. For example, if you are located within the hub of a network, then you would apply to the Hub Coordinator. If there is no network that covers your area, then you would apply to the Regional Coordinator for your region. Your application for a node number must be sent to the coordinator by FidoNet mail, and must include at least 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. 6) The maximum baud rate you can support. Your coordinator may want additional information. If so, he will contact you. Please allow at least two to three weeks for a node number request to be processed. 2.2 If you are going down If your node will be down for an extended period (more than a day or two), then you should inform your coordinator as soon as possible. If you do not do this, then other systems will still try to reach you while you are down, much to the annoyance of everyone. Do not under any circumstances put an answering machine or similar device on your phone line while you are down. If you do, then calling systems will get the machine repeatedly, racking up large phone bills, which is very annoying. See the section on Resolution of Disputes for details on what happens to annoying people. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your coordinator. Systems do have a tendency to "crash" now and then, so you will probably want your coordinator to know that it is a temporary condition if it happens while you are away. 2.3 How to form a network If there are several nodes in your area, but no network, then you may wish to form your own. You may also be requested to form a network by your Regional Coordinator. Your first step is to contact the other sysops in your area. You must decide which nodes will comprise the network, and which of those nodes is going to be the Network Coordinator. Your next step is to inform your Regional Coordinator. You must send him a FidoNet message with the following information: 1) The region number(s), or network number(s) if a network is splitting up, that are affected by the formation of FidoNews 5-24 Page 28 13 Jun 1988 your network. The Regional Coordinator will inform the coordinators of any affected networks that a new network is in formation. 2) The name that you wish to call your network. Please try to select a name that relates to your grouping. For example, SoCalNet for nodes in the Southern California Area and MassNet for Massachusetts Area. Remember if you call yourself DOGNET it doesn't help others know what area of the country (or even what country) your group is in. 3) A copy of the proposed network's nodelist. The nodelist file should be named Frrr-nnn.NET where rrr is the proposed host's current region or network number and nnn is his current node number. For example, if the proposed host is currently listed as node 5 in region 13, then you would name the file F013-005.NET. This file should be sent attached to the message of Application for a Network Number. Granting of a network number is not automatic. Your Regional Coordinator will review your application and inform you of his decision. Do not send a network number request to the Zone Coordinator. All network number requests must be processed by the Regional Coordinator. Chapter 3 COORDINATOR PROCEDURES This chapter describes the procedures followed by all coordinators at all levels. Later we will go into more detail on those procedures which are specific to any given type of coordinator. All coordinators have four primary duties. In order of decreasing importance, they are: 1) Administrative tasks. 2) Node list distribution. 3) Newsletter distribution. 4) Network mail distribution. At first glance it would seem that network mail distribution should be the highest priority, since after all that's why we're running a network in the first place. But the first three priorities are needed to ensure smooth operation of the network, and hence must have a higher priority. FidoNews 5-24 Page 29 13 Jun 1988 3.1 Administrative tasks First and foremost, every coordinator is also the sysop of his own node. It must be possible for others to reach you by network mail. So in addition to the other tasks of a coordinator, you must also observe all of the requirements for being a node. 3.1.1 Maintaining the node list A coordinator at any level must maintain his portion of the node list. Almost any coordinator will have some nodes in his node list which are not a part of any subgroup. For example, a Zone Coordinator must maintain a list of administrative nodes for his zone, and a Regional Coordinator must maintain a list of independent nodes in his region. A Hub Coordinator (or the Network Coordinator in a network without hubs) must maintain the list of all nodes in his area. A coordinator is responsible for seeing to it that his portion of the node list is kept reasonably accurate. You should attempt to implement name changes, phone number changes, and so forth in this node list as soon as possible. You should also check from time to time to ensure that all of the listed nodes are in fact capable of accepting network mail. How best to accomplish this is left to your discretion. 3.1.2 Assigning node numbers You may assign node numbers to new nodes in your list, but keep in mind the following: 1) It is your responsibility to ensure that the node number you assign is unique within that region or network. 2) You should try to avoid assigning node numbers when an existing subdivision of your area already covers the location of the new node. For example, a Regional Coordinator should try to avoid assigning independent nodes in a city that has its own network. You may also change the numbers of existing nodes in your area, though you should check with the respective nodes before doing so. You should not under any circumstances assign a node number to any system until you have received a formal request from that system by FidoNet mail. This will ensure that the system is at least minimally operational. The strict maintenance of this policy has been one of the great strengths of FidoNet. It is also recommended, though not required, that you call a board which is applying for a node number before assigning it a node number. FidoNews 5-24 Page 30 13 Jun 1988 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. 3.1.3 Problem resolution From time to time you may be called on to resolve a problem in your area. This could be a technical problem relating to the four primary duties of a coordinator, or it could be related to annoying behaviour on the part of someone in your area. If the problem is caused by a node or a coordinator immediately under you, then it is your responsibility to resolve the problem in whatever manner you deem fit. If the problem is in a subdivision of your area, then you should first refer it to the appropriate coordinator. If that coordinator does not resolve the problem satisfactorily, then you can appoint a replacement. 3.1.4 Formulating local policy It is your responsibility to formulate any local policies which are required for the smooth operation of your assigned area. Any policies you establish must not conflict with any policies established by a coordinator above you or with this policy document. 3.2 Node list distribution The node list is posted weekly on Saturday, along with a "difference file" giving the changes for the week. It is your responsibility to obtain the difference file from your coordinator every week and to distribute it to the coordinators below you. The method of distribution is left to your discretion. It is also desirable that you make it available for downloading by the general user, but this is not required. 3.3 Newsletter distribution The newsletter, called FidoNews, is published weekly on Monday and is distributed as an archive named FNEWSvnn.ARC, where "v" is the volume number and "nn" is the issue number. It is your responsibility to obtain this archive from your coordinator every week and to distribute it to the coordinators below you. The method of distribution is left to your discretion. It is also desirable that you make it available for downloading by the general user in both archived an unarchived form, but this is not required. FidoNews 5-24 Page 31 13 Jun 1988 3.4 Network mail distribution It is your responsibility to ensure that network mail in your area is operating in an acceptable manner. Exactly what this involves will depend on what level you are at, and will be discussed in more detail below. 3.5 Anything else You should encourage sysops and users in your region to contribute to FidoNews. If you receive any submissions, you should forward them to the FidoNews publisher. Think of yourself as being a regional bureau chief on the FidoNews editorial staff. FidoNews and the node list are the glue that holds us together. Without them, we cease to be a community, and become just another random collection of bulletin boards. 3.6 Specific coordinator procedures The above outlines the procedures which are followed by all coordinators. We will now discuss additional procedures followed by specific types of coordinators. 3.6.1 International Coordinator procedures The International Coordinator is elected by all regional coordinators in all zones. In case of a vacancy, the senior zone coordinator will assume the position until such time as a new coordinator can be elected. The International Coordinator is responsible for format of the node-list and the update files. The International Coordinator is responsible for allocating zones, assigning zone numbers, and for appointing the Zone Coordinator for each zone. 3.6.2 Zone Coordinator procedures A Zone Coordinator is responsible for dividing his zone into regions, assigning region numbers, and for appointing the Regional Coordinator for each region. A Zone Coordinator also assigns a pool of numbers to each Regional Coordinator for use in assigning network numbers. A Zone Coordinator is responsible for locating nodes willing to act as zone gates for passing mail between his zone and the other zones, if at all possible. A Zone Coordinator should not appoint any node as a zone gate unless the sysop of that node is willing and able to provide reasonably reliable interzone mail. FidoNews 5-24 Page 32 13 Jun 1988 Zone gates are highly desirable, but if provided they must be reasonably reliable. A Zone Coordinator maintains the list of administrative nodes within his zone. The administrative nodes will always have a region number the same as the zone number. For example, the administrative nodes for Zone 3 will always be in Region 3. A Zone Coordinator may use administrative node addresses for whatever he likes, except that any node number which is the same as another zone number is reserved for the zone gate to that zone. For example, in Zone 3 the network address "3/2" is reserved for use by the zone gate that passes mail from Zone 3 to Zone 2. A Zone Coordinator may not assign a region number that is the same as any other zone number. This is because administrative regions are, by definition, present in all zones. A zone coordinator is responsible for the weekly zone and world nodelist to be published in his zone on Saturdays. 3.6.3 Regional Coordinator procedures A Regional Coordinator is responsible for approving new networks, assigning network numbers, and for appointing a Network Coordinator for each network. Each Regional Coordinator will be assigned a pool of numbers to use when assigning network numbers. A Regional Coordinator should never assign a network number outside of this pool, and should never assign the same number to more than one network. If a Regional Coordinator assigns all of the numbers in his pool, he should apply to his Zone Coordinator for additional numbers. A Regional Coordinator should try to avoid the needless proliferation of networks. Networks should not be allocated on any basis other than technical and practical considerations relating to network mail operations. For example, persons wishing to establish networks on the basis of special interests or for company mail should be encouraged to investigate the alternatives, such as echomail conferences and point networks. A Regional Coordinator is responsible for maintaining the list of independent nodes within his region. This will consist primarily of those nodes which are not within the coverage area of any network. There are, however, certain cases where a node should not be a member of a network, such as a commercial system with a large volume of traffic which would clog the network. The resolution of such special cases is left to your own discretion. If several independent nodes in a region are in a "clump", then the Regional Coordinator should encourage or require FidoNews 5-24 Page 33 13 Jun 1988 them to form a network. Refer to the sysop procedure on forming a network for more details. Note that this does not mean that a Regional Coordinator should 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 the discretion of the Regional Coordinator. It is the responsibility of a Regional Coordinator to ensure that the networks within his region are operating in an acceptable manner. This does not mean that he is required to operate those networks; that is the responsibility of the Network Coordinators. It means that he is responsible for seeing to it that the Network Coordinators within his region are acting responsibly. A Regional Coordinator is obligated to maintain direct and reasonably frequent contact with the networks in his region. The exact method of accomplishing this is left to the discretion of the Regional Coordinator. 3.6.4 Network Coordinator procedures A Network Coordinator is responsible for assigning node numbers to any nodes within his network which are not managed by a Hub Coordinator. A Network Coordinator is also responsible for allocating any hubs within his network and for appointing a Hub Coordinator for each hub. If a Network Coordinator assigns any Hub Coordinators, then he also assigns a pool of numbers to each Hub Coordinator for use in assigning node numbers. It is the responsibility of a Network Coordinator to receive all inbound mail for nodes in his network and to forward it to its recipients. How to accomplish this is left to the discretion of the Network Coordinator. However, there are a few exceptions: 1) Once in awhile a node will try to make a "bombing run" (sending one message to a great many nodes). Bombing runs are considered to be annoying, and may be dealt with accordingly. 2) Occasionally a user will appear who receives a great deal of traffic. If a single node is receiving enough mail to interfere with mail delivery to the other nodes in his network, then his Network Coordinator can refer him to his Regional Coordinator for reassignment as an independent node. 3) The most common source of routing overload is echomail. Echomail is a nice invention, and offers great benefits, but it cannot be allowed to degrade the ability of FidoNet to handle normal message traffic. If a node in a network is routing large volumes of echomail, the sysop can be asked to either limit the amount of echomail, or even to stop routing his echomail completely. The design of echomail is such FidoNews 5-24 Page 34 13 Jun 1988 that it is a simple matter to do either of these. A Network Coordinator is responsible for assigning any additional mail events which may be required for operation of his network. Any node in a network may be excommunicated for failing to observe these additional mail events. A Network Coordinator may appoint a node as the outbound gateway for his network if he so desires and if one can be found. In no case should a node be appointed as an outbound gateway unless the sysop of that node is willing and able to provide reasonably reliable service. Note that a Network Coordinator is not required to appoint an outbound gateway. If a Network Coordinator chooses to appoint an outbound gateway, then it is left to the Network Coordinator to establish any rules, policies, and procedures relating to its use. 3.6.5 Hub Coordinator procedures A Hub Coordinator is responsible for assigning node numbers to nodes in his area. Each Hub Coordinator will be assigned a pool of numbers to use when assigning node numbers. A Hub Coordinator should never assign a node number outside of this pool, and should never assign the same number to more than one node. If a Hub Coordinator assigns all of the numbers in his pool, he should apply to his Network Coordinator for additional numbers. It is the responsibility of a Hub Coordinator to receive all inbound mail for nodes in his hub and to forward it to its recipients. How to accomplish this is left to the discretion of the Hub Coordinator. However, the same exceptions apply here as for a Network Coordinator. A Hub Coordinator may have additional duties, as assigned by his Network Coordinator. Chapter 4 RESOLUTION OF DISPUTES The world not being perfect, sometimes troubles crop up. Any organization larger than a cub scout pack needs some sort of grievance procedure, and FidoNet is no exception. 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 FidoNews 5-24 Page 35 13 Jun 1988 against either or both parties. ("Judge not, lest ye be judged!") In any case of annoying behavior the person to complain to is the coordinator of the person who is annoying you. For example, if you have a problem with a point or a user you would complain to his sysop, or if you have a problem with a Regional Coordinator you would complain to his Zone Coordinator, and so on. If the coordinator you complain to fails to resolve the problem, then you can complain to his coordinator. For example, if you had a problem with a Hub Coordinator, you would first complain to his Network Coordinator. Then if the Network Coordinator does not resolve the problem, you would complain to his Regional Coordinator. Do not ever skip over a coordinator when filing a complaint. That in itself is annoying. (many thanks to Henk Wevers, who did most of this policy doc. Minor editing is all that was needed to bring it into conformance with the changed IFNA doc and the companion IPOLICY.TXT) ----------------------------------------------------------------- FidoNews 5-24 Page 36 13 Jun 1988 ================================================================= COLUMNS ================================================================= Jake Hargrove Fido 301/1 High Mesa Ranger's What Price Echo Mail This article is going to deal with a subject which is getting very close to my pocket book and many others as well. In recent months it seems echomail has not only become popular with SySop's but users as well. An the question has arisen who should pay for echomail. This question like most others is fair, and deserves an answer. Even if it may not be what most folks want to hear. In recent weeks the feed for most of this region (15) has been down. I find out by reading echomail, the feed is running six (6), 9600 baud HST modems (wish I just had one). An he is getting flamed left and right in almost every echomail area I read. Then I am politely reminded by a little bird on my shoulder. I do not know this guy from Adam, he is providing a service to me and many of the other nodes in the western United States, and his so called fellow sysops are Flaming him. So I ask the QUESTION. "WHAT IS THE PRICE OF ECHOMAIL?" Like most everyone else except for a few I started picking up echomail when it really got started. Presently I use two feeds, one here in Region 15, and one from Region 19. Both are long distance calls and presently average 10-15 minutes each. It just so happens both feeds have been affected by the loss of the western feed. So for a couple of weeks now, messages have been sporadic to say the least. I now carry 23 echo areas, some of which are used solely for myself, and most which are forwarded to other nodes locally. But I read every single message that comes into this board. Basically since I have very few users, because I have not advertised the BBS very much. The BBS is largely a message base, in fact recently when my internal clock was reset to the year 1990 by a game my son plays. I lost or rather had killed over 7 megs of messages because they were over 15 days old. Yes, I had read all of them but it makes you wonder. If I am a small system and have over 7 megs of messages what do some of the other larger systems have. Recently purchasing a 2400 Baud Ven-Tel modem I hope to cut my cost, I do not expect it to be cut in half or anything like that, even a 50 dollar cut off of 137.00 will help. An if I figure it right, a 50 dollar cut would pay for my new modem in about 8 months. FidoNews 5-24 Page 37 13 Jun 1988 I now turn the topic of this article to the real subject. Just who should pay for echomail? I say this cost MUST be shared by all of us. If it cost my feeds $80.00 each a month to pickup their echo mail, and they use a 9600 baud modem. You can figure the cost of your echo mail using the following formula. 9600 100% 75% 50% 25% 9600/9600 = 1 80.00 60.00 40.00 20.00 9600/2400 = 4 320.00 240.00 120.00 80.00 9600/1200 = 8 640.00 480.00 320.00 120.00 9600/300 = 32 2560.00 1920.00 1280.00 512.00 2400 100% 75% 50% 25% 2400/2400 = 1 320.00 240.00 120.00 80.00 2400/1200 = 2 640.00 480.00 320.00 120.00 2400/300 = 8 2560.00 1920.00 1280.00 512.00 1200 100% 75% 50% 25% 1200/1200 = 1 640.00 480.00 320.00 120.00 1200/300 = 4 2560.00 1920.00 1280.00 512.00 I am most certainly willing to support my feed in any way I can but if I were to pickup all the echomail he received in a months time frame, I would have already paid 4 times what he paid just to get mail from him. But since I do my planning a little bit ahead I am only picking up those areas I want to read. So my cost is is not going to be the full cost of echomail to him. An it would not matter to Ma Bell who gives them the money. If my feed decided he was no longer going to allow me to poll him for mail. If he was going to make all the calls and then charge me a rate comparable to his phone cost. He would in fact, be doing me a favor, except it would still cost me XX dollars per month. It is now up to me to decide what I am willing to pay for my end of echomail. So what I am going to PRESUME IS: 1. It will cost me to call my feed. 2. Or it will cost me to have him call. Either way, I will be paying out of my pocket. I now ask, which is easier? Of course, I call him. I do it at my own time, when he allows me to do so, normally between 0200 and 0500 in the morning. The cheapest time to call. So basically it means: ECHOMAIL is going to cost me exactly what I am willing to pay for it. As the local and Net 301 feed, I am making several proposals to those who I distribute mail to on how WE can solve this problem which will soon face us. They are the only ways I know of US maintaining our connection. FidoNews 5-24 Page 38 13 Jun 1988 So it all comes down to these few simple FACTS. What Price of EchoMail is what you and I are going to be willing to pay for it. I personally want it as cheap as I can get it. My wife wants it cheaper. Even if as she put it, it means cutting back in the number of areas I receive, or telling those nodes who I make distribution to locally presently at no cost, except to one who has already agreed to pay his fair share, they will have to find other means of obtaining the echos they want. But then if I was a distribution point I would not want 3 or 4 nodes from the same area making pickup. So one way or the other, MY price for EchoMail will be my monthly PHONE Bill. ----------------------------------------------------------------- FidoNews 5-24 Page 39 13 Jun 1988 Top Downloads: 5/27/8 - 6/3/88 A weekly report of the most popular downloads from contributing FidoNet systems. Report created on June 9. Contributing systems: 135/1 (380/2 - I guess you couldn't get through because of our disk problems). Because I'm getting ready to install, format and copy 170 floppies worth of files onto a new hard drive as well as change some of the look of RAM-SOFT, I'm just presenting you with a higly edited (not all files are listed) version of the system report from LogRpt. For those seeing this column for the first time, this is NOT the way it usually looks. Although we managed to be up for all but 3 national mail slots in the past two weeks, we have been down during the day quite often and the stats look sick compared to previous weeks. Hopefully in the 6/20 issue we'll be back to normal. (Our other sysop picked a great week to take a vacation!) Report for the days 27 May through 02 Jun for a total of 7 days Percentage of use per hour % .... ... 55| * * * * | 50| * * * * * * | 45| * * * * * * * | 40| * * * * * * * * * * | 35| * * * * * * * * * * * | 30| * * * * * * * * * * * * * * | 25| * * * * * * * * * * * * * * | 20| * * * * * * * * * * * * * * * | 15| * * * * * * * * * * * * * * * | 10| * * * * * * * * * * * * * * * * | 5| * * * * * * * * * * * * * * * * * * * * * | +------------------------------------------------------------+ 0 1 2 3 ... 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Statistics based on the board being available for 22.0 hours per day with a total of 50.0 calls possible per hour. Total number of calls: 185 Total minutes BBS was in use: 2501 Min. Average call duration : 13.52 Min. Utilization of the BBS : 32.48 % File transactions Average per day --------------------------------------- Downloads: 137 19.57 Uploads : 11 1.57 Number of new calls: 96 (starting from 0 users, that isn't bad) Busiest hour was : 0000 FidoNews 5-24 Page 40 13 Jun 1988 File Name # DL's ------------------------------------------ d:\opus\files\misc\arc-set.arc 9 d:\opus\files\info\oliomac.arc 3 e:\opus\files\comm\fixpcp11.arc 3 d:\opus\files\bbsp\colossus.arc 2 d:\opus\files\info\macpics2.arc 2 d:\opus\files\misc\firework.arc 2 d:\opus\files\misc\say.arc 2 d:\opus\files\util\clean.arc 2 d:\opus\files\util\faskbak.arc 2 e:\opus\files\comm\pcplus11.arc 2 d:\opus\files\bbsp\newsysop.arc 1 d:\opus\files\bbsp\renum40.arc 1 d:\opus\files\bbsp\xlatlist.arc 1 d:\opus\files\lang\a86a.arc 1 d:\opus\files\lang\csrturbo.arc 1 d:\opus\files\lang\cxmodem.arc 1 d:\opus\files\lang\d86a.arc 1 d:\opus\files\lang\edipage.arc 1 d:\opus\files\lang\f-m2doc.arc 1 d:\opus\files\lang\f-m2util.arc 1 d:\opus\files\lang\scrn-c.arc 1 d:\opus\files\lang\sort-bas.arc 1 d:\opus\files\lang\sorts.arc 1 d:\opus\files\lang\tccmisc.arc 1 d:\opus\files\util\bacopy.arc 1 d:\opus\files\util\colblnk1.arc 1 d:\opus\files\util\cpu1b.arc 1 d:\opus\files\util\dog101a.arc 1 d:\opus\files\util\emcach.arc 1 d:\opus\files\util\reboot.arc 1 d:\opus\files\util\rmap.arc 1 d:\opus\files\util\saytime.arc 1 d:\opus\files\util\sdir1.arc 1 d:\opus\files\util\show.arc 1 d:\opus\files\util\sortdir.pas 1 d:\opus\files\util\sst.arc 1 d:\opus\files\util\tt.arc 1 e:\opus\files\comm\dtpall.arc 1 e:\opus\files\comm\gt1400-3.arc 1 e:\opus\files\comm\gt1400-4.arc 1 e:\opus\files\comm\gt1400-5.arc 1 e:\opus\files\comm\ibmaux20.arc 1 e:\opus\files\comm\pcplusrt.arc 1 e:\opus\files\comm\ultra3.arc 1 e:\opus\files\comm\updload.arc 1 e:\opus\files\comm\xfer121.arc 1 Transfer methods total ----------------------------- SEAlink download/upload: 21 Telink download/upload: 8 Xmodem download/upload: 77 Ymodem download/upload: 11 Zmodem download/upload: 31 FidoNews 5-24 Page 41 13 Jun 1988 External download/upload: 0 If there are any other systems interested in having your download stats included in this weekly column, please send me your system via net-mail at 135/1. The complete system report from LogRpt so I can include utilization stats would be ideal but is not required. If there are filenames that may not fully indicate what the file is, please let me know. If there is a file you particularly want me to list, let me know. I need to have the information by Monday's Net-mail time in order to get the stats compiled. Please keep your reports at 7 or 8 days, Friday to Friday if possible and no longer than 10 days. (We can accept net-mail anytime of the day [when our HD works] and are PC-Pursuitable). James Gilbert RAM-SOFT Archive Library (9600HST) 1:135/1 ----------------------------------------------------------------- FidoNews 5-24 Page 42 13 Jun 1988 ================================================================= NOTICES ================================================================= Once you thought it was safe to go back into the water... BEACH : Beach and Resort Echomail returns! run by Randy Kobetich, the Pervert under the BoardWalk available directly from 150/199 or through appropiate channels. Mike J The Grey Sysop... ----------------------------------------------------------------- The Interrupt Stack 18 Jun 1988 Area Code 407 takes effect in East/Central Florida. All Sysops should adjust their Nodelist entries immediately. 25 Jun 1988 EuroCon II starts in Tiel, Holland. Sponsored by the Dutch Hobby Computer Club. Will run for 2 days. Contact Hans Lichthelm at 2:2/999 for information. 16 Jul 1988 A new areacode, 508, will form in eastern Massachusetts and will be effective on this date. The new area code will be formed from the current areacode 617. Greater Boston will remain areacode 617 while the rest of eastern Massachusetts will form the new areacode 508. 25 Aug 1988 Start of the Fifth International FidoNet Conference, to be held at the Drawbridge Inn in Cincinnati, OH. Contact Tim Sullivan at 108/62 for more information. This is FidoNet's big annual get-together, and is your chance to meet all the people you've been talking with all this time. We're hoping to see you there! 24 Aug 1989 Voyager 2 passes Neptune. If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- Latest Software Versions BBS Systems Node List Other FidoNews 5-24 Page 43 13 Jun 1988 & Mailers Version Utilities Version Utilities Version Dutchie 2.81 EditNL 4.00* ARC 5.21 Fido 12h* MakeNL 2.10* ARCmail 1.1 Opus 1.03b Prune 1.40 ConfMail 3.31 SEAdog 4.10 XlatList 2.86 EchoMail 1.31 TBBS 2.0M XlaxNode 1.02 MGM 1.1 BinkleyTerm 1.50* XlaxDiff 1.02 QuickBBS 2.01* ParseList 1.10 * 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 5-24 Page 44 13 Jun 1988 ================================================================= COMMITTEE REPORTS ================================================================= Don Daniels, President International FidoNet Association FidoNet 1:107/210 IFNA Status Report for June 1988 PROGRESS DURING THIS PERIOD General First of all, I'd like to report that FIDOCON '88 preparation is still charging ahead. There is a great deal of preparation and additional effort being expended to make this the biggest and best FIDOCON ever. From what I hear, there is an exciting key-note speaker lined-up: one of the innovators and "mavericks" of the industry. I'll let the Conference Organizing Committee give you the details when they're positive that everything is finalized, but it looks like this will be another highlight. The Committee seems to be going all out to provide a wide-range of topics, from the very technical to the important political issues that need to be resolved. If you hurry, I think you may still have a chance at the drawing for the U.S. Robotics 9600 HST modem, so get your registration in now! Meanwhile, quite a few other activities are underway that sound very exciting. Should they continue in the direction they appear headed, it looks like we will have a lot of work to do, but will stand a very good chance of bringing real distinction to FidoNet through IFNA. The first of these, headed up by David Drexler, involves support for the younger set. There already is a KID'S NET which was started by the Witherspoon family, I believe. They've given us some ideas and help and Dave has been able to make several contacts in related areas. In one such undertaking, several hundred schools in the U.S. and Australia are already linked through a commercial network supported as a pilot project by one of the major carriers. It looks like that support may not continue into the fall and there may well be a chance for us to step in and provide some real cost-effective assistance to the schools that wish to continue. In another project led by IFNA Vice-President Mark Grennan, a specially modified mailer is being developed that can be used by the blind. Several institutions that support the blind are very interested in the potential of this approach and have indicated various levels of support. There are still a few problems to be worked out, but hope is high that we can make quite a FidoNews 5-24 Page 45 13 Jun 1988 contribution to this segment of our population. Still another project deals with support for the deaf. Due to manning problems, we've had difficulty in getting this one underway. We could use help on all these areas, but particulary this one which has initial contacts in the D.C. area. These and other activities going on behind the scenes hold a great deal of promise for FidoNet to make even a far greater influence than it already has. But with this potential comes considerable responsibility and it it very necessary for us all to settle some of the political and technical issues that separate us, thereby making it possible for those that wish to and can support such beneficial endeavors to do so. Please, if you believe in such activities, make a real attempt to come to FIDOCON. We need your support and energy to clear some of the obstacles between us and some really worthwhile contributions to the public. ADMINISTRATION AND FINANCE Unfortunately, Greg Small, who filled the empty Chair of this committee, has been beset by some overpowering personal considerations and has had to drop out. This leaves us again, without a leader for this important area. Certain aspects are proceeding along regardless, such as the financial work by Leonard Mednick and various projects by Steve Bonine. But we do need someone who can organize a great many administrative services and requirements to make us all more efficient. BOARD OF DIRECTORS The BoD has resolved the technical difficulties encountered with its recent management changeovers. Voting reports appear weekly in IFNA, so I'll not repeat them here. BY-LAWS AND RULES No formal report was received from Steve Jordan. However, we have been involved in several discussions regarding some much-needed amendments to the By-laws. Steve's committee is finalizing the rules for this summer's vote on the suggested amendments. EXECUTIVE COMMITTEE As most of the members of the Executive Committee are forced to do double duty on other matters, the efforts involved in replacing Tom Marshall who resigned as Secretary due to personal and professional concerns, have taken up most of the available time. FidoNews 5-24 Page 46 13 Jun 1988 My personal thanks to Tom who has contributed a great deal of service to FidoNet. INTERNATIONAL AFFAIRS No official report was received from Henk Wevers, but he has told me that they are expecting 120 or more for EuroCon II. Those of us that will be attending are looking forward to this event - in my case, I expect it to provide additional input towards our preparation for FIDOCON. MEMBERSHIP SERVICES Phil Ardussi informs me that the tapes from last FIDOCON are finally ready and will be available at this year's conference. Plans are already underway for next year's conference. They are putting the finishing touches on the forms and processes for evaluating bids for FIDOCON '89. It is expected that bids will be requested and received in time to make the decision and announcement at this year's conference. NOMINATIONS AND ELECTIONS The chairmanship of this committee was just changed from David Garrett to Rob Barker on the request of the BoD. Although the By-laws don't specifically say so, it appears that their intent was to maintain separation between the IFNA Secretary and the functions of this committee. Therefore, as David Garrett has just been elected the new Secretary of IFNA, he was asked to relinquish the chair. Our thanks to David for his recent efforts in handling the nominations and working toward the establishment of the rules for the upcoming election. PUBLICATIONS No report was received on this matter from Tim Sullivan (who is presently concentrating his efforts on FIDOCON!). TECHNICAL STANDARDS No report was received from Randy Bush. ETHICS COMMITTEE No specific report was received from Bill Allbritten, but I did get a copy of a draft of a Standard of Ethics for the leadership of IFNA. I was very impressed with this document, as it appears, in addition to spelling out various standards of performance and conduct, to really provide the membership with an independent mechanism for monitoring the officers and directors of IFNA. FidoNews 5-24 Page 47 13 Jun 1988 There are still some details to be cleaned up, but I'm confident everyone will be impressed at the reasonable scope of this document. VP-TC Dave Dodell did not provide a report. FIDOCON LIAISON Tim Sullivan's report was summarized above. PROBLEMS As can be seen from the above, the extra burdens and lures of the encroaching summertime have cut into the remaining time available for FidoNet. This demonstrates that there are plenty of opportunities for others to get involved and take on some of the load. In fact, I would really like to call for a maximum limit on the number of "hats" an individual can wear, due to the difficulty so many have trying to meet the many other requirments of life and sysoping. PROGNOSIS FOR NEXT PERIOD We are really looking forward to some of the various projects currently underway coming to fruition. And of course, FIDOCON should be a marvelous opportunity for us to get together and continue the new understanding and desire to work towards solutions that seems to have started to take hold throughout the Net. ----------------------------------------------------------------- FidoNews 5-24 Page 48 13 Jun 1988 OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION Ken Kaplan 100/22 Chairman of the Board Don Daniels 107/210 President Mark Grennan 147/1 Vice President Dave Dodell 114/15 Vice President - Technical Coordinator Tom Marshall 107/524 Secretary Leonard Mednick 12/1 Treasurer IFNA BOARD OF DIRECTORS DIVISION AT-LARGE 10 Steve Jordan 102/2871 Don Daniels 107/210 11 Bill Allbritten 11/301 Hal DuPrie 101/106 12 Leonard Mednick 12/1 Mark Grennan 147/1 13 Rick Siegel 107/27 Brad Hicks 100/523 14 Ken Kaplan 100/22 Ted Polczyinski 154/5 15 Jim Cannell 128/13 Kurt Reisler 109/74 16 Vince Perriello 141/491 Robert Rudolph 261/628 17 Rob Barker 138/34 Greg Small 148/122 18 Christopher Baker 135/14 Bob Swift 140/24 19 Vernon Six 19/0 Larry Wall 15/18 2 Henk Wevers 2:500/1 Gee Wong 107/312 ----------------------------------------------------------------- FidoNews 5-24 Page 49 13 Jun 1988 FidoCon '88 - Cincinnati, Ohio At The Drawbridge Inn and Convention Center August 25-28, 1988 Attendee Registration Form Name: ____________________________________________________ Address: ____________________________________________________ Address: ____________________________________________________ City: _______________________ State: ____ Zip: ___________ Country: ____________________________________________________ Phone Numbers: Day: ____________________________________________________ Evening: ____________________________________________________ Data: ____________________________________________________ Zone:Net/ Node.Point: _______________________________________________ Your BBS Name: _______________________________________________ BBS Software: _____________________ Mailer: _________________ Modem Brand: _____________________ Speed: _________________ What Hotel will you be Staying at: ____________________________ Do you want to share a room? ______ Are you a non-smoker? ______ Do you want an in room point? ______ (Tower rooms at Drawbridge only) Do you need special accommodations? ______ (If so, please explain) ____________________________ ____________________________ FidoNews 5-24 Page 50 13 Jun 1988 Are you a non-Sysop? ______ Are you an IFNA Member? ______ If so, will you be attending the Sunday IFNA brunch/BoD meeting? ______ Additional Guests: ______ (not attending conferences) Comments: ____________________________________________________ ____________________________________________________ ____________________________________________________ Costs How Many? Cost --------------------------- -------- ------- Conference fee $60..................... ________ _______ ($75.00 after 7/31) Thursday Lunch $10.95 .............. ________ _______ Thursday Dinner $18.95 .............. ________ _______ Friday Lunch $10.95 .............. ________ _______ Friday Banquet $24.95 .............. ________ _______ Saturday Lunch $10.95 .............. ________ _______ ======== ======= Totals ................................ ________ _______ You may pay by Check, Money Order or Visa/MC Please send no cash. All monies must be in U.S. Funds. Checks should be made out to: "FidoCon '88" This form should be completed and mailed to: FidoCon '88 Registration P.O. Box 9294 Cincinnati, OH 45209 If you pay by Credit Card you may also register by Netmailing this completed form to 108/62 or 1/88 for processing. Please complete the information below and be sure to include a voice phone number above so that we can contact you for Credit Card FidoNews 5-24 Page 51 13 Jun 1988 verification. Rename this file ZNNNXXXX.REG where Z is your Zone number, N is your Net number, and X is your Node number. [ ] Visa [ ] MasterCard Name as it appears on credit card: ___________________________________________ Credit Card Number: ___________________________________________ Expiration Date: ___________________________________________ Signature: ___________________________________________ (If you mail in registration) ----------------------------------------------------------------- FidoNews 5-24 Page 52 13 Jun 1988 INTERNATIONAL FIDONET ASSOCIATION ORDER FORM Publications The IFNA publications can be obtained by downloading from Fido 1:1/10 or other FidoNet compatible systems, or by purchasing them directly from IFNA. We ask that all our IFNA Committee Chairmen provide us with the latest versions of each publication, but we can make no written guarantees. Hardcopy prices as of October 1, 1986 IFNA Fido BBS listing $15.00 _____ IFNA Administrative Policy DOCs $10.00 _____ IFNA FidoNet Standards Committee DOCs $10.00 _____ SUBTOTAL _____ IFNA Member ONLY Special Offers System Enhancement Associates SEAdog $60.00 _____ SEAdog price as of March 1, 1987 ONLY 1 copy SEAdog per IFNA Member Fido Software's Fido/FidoNet $100.00 _____ Fido/FidoNet price as of November 1, 1987 ONLY 1 copy Fido/FidoNet per IFNA Member International orders include $10.00 for surface shipping or $20.00 for air shipping _____ SUBTOTAL _____ HI. Residents add 4.0 % Sales tax _____ TOTAL _____ SEND CHECK OR MONEY ORDER IN US FUNDS: International FidoNet Association c/o Leonard Mednick, MBA, CPA 700 Bishop Street, #1014 Honolulu, HI. 96813-4112 USA Name________________________________ Zone:Net/Node____:____/____ Company_____________________________ Address_____________________________ City____________________ State____________ Zip_____ Voice Phone_________________________ Signature___________________________ -----------------------------------------------------------------