F I D O N E W S -- Vol.10 No.14 (05-Apr-1993) +----------------------------+-----------------------------------------+ | A newsletter of the | | | FidoNet BBS community | Published by: | | _ | | | / \ | "FidoNews" BBS | | /|oo \ | +1-519-570-4176 1:1/23 | | (_| /_) | | | _`@/_ \ _ | Editors: | | | | \ \\ | Sylvia Maxwell 1:221/194 | | | (*) | \ )) | Donald Tees 1:221/192 | | |__U__| / \// | Tim Pozar 1:125/555 | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: editors 1:1/23 | +----------------------------------------------------------------------+ | Internet addresses: | | | | Sylvia -- max@exlibris.tdkcs.waterloo.on.ca | | Donald -- donald@exlibris.tdkcs.waterloo.on.ca | | Tim -- pozar@kumr.lns.com | | Both Don & Sylvia (submission address) | | editor@exlibris.tdkcs.waterloo.on.ca | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies and other boring but important details, | | please refer to the end of this file. | +----------------------------------------------------------------------+ ======================================================================== Table of Contents ======================================================================== 1. Editorial..................................................... 2 2. Articles...................................................... 2 The Cynic's Sandbox, v2.0ReallyWideAlphaForAnyOne........... 2 Why Policy 4.1C deserves our serious attention.............. 4 Commodore Geos Echo Available............................... 6 Responce to Stanton McCandlish.............................. 6 OS2 echos................................................... 9 Policy Proposals: The Cart Before the Horse?................ 10 Rebuttal to an Anonymous Critic............................. 14 FidoNet Policy Document Version 5........................... 17 3. Fidonews Information.......................................... 48 FidoNews 10-14 Page: 2 05 Apr 1993 ======================================================================== Editorial ======================================================================== We Lied. There are TWO policy documents in this issue, although there won't be any more, probably. We are getting bulges of requests for information about sending mail from FidoNet to Internet, and queries from exotic sounding internet addresses about how to "get on" FidoNet. For example, to whom and where should we refer someone in the Dominican Republic who wants to start a BBS? Also, during said mail bulges i managed to lose an announcement about a Chinese language e-'zine and would its sender very kindly re-send it? Spring is coming easily la-de-da, cactuses between cabling on tables are sprouting little green things. I'm still waiting for my monitor to sprout. Why is it difficult to get anything started when beginnings happen so naturally in plant-life? Vine-like networks tangle around and i just watch. It is too easy to be inert and accepting unless some buttons are pushed and rewards are possible. Not much truly interesting seems to happen unless somebody tries something new simply to try something new. oh...whaa...excuse me, D.T. [ET in moments such as this] in muttering something over my shoulder about how God is a computer who invented man as a bootstrap loader... "man". Hrrrumph. Try wiring a net without gender changers. ======================================================================== Articles ======================================================================== The Cynic's Sandbox, v2.0ReallyWideAlphaForAnyOne R. Cynic It's Spring, it must be time for a policy proposal. Boy, and I was getting bored with Fight-O-Net. Now we have Pol5, Pol4.1c, caller ID, and another well-thought-out-type- III-packet-proposal-which-will-be-ignored-until-someone-writes- code. I don't think I've ever had so much fun with clothes on. I'd like to take this moment, if I may, to submit the R. Cynic Pol6 Proposal, which I hope you'll all examine with a 10x magnifier. Policy Six Final Version 1 April 1993 0. Legal Stuff This document is FraggleWare. To register, sing the Fraggle FidoNews 10-14 Page: 3 05 Apr 1993 Rock theme. You forgot the last verse. Try Again. 1. Overview Fight-O-Net is a whole buncha systems with little more than FTS-0001 in common, and sometimes, if they run FrontDoor, not even that. 2. Language The official language of Fight-O-Net is english, preferably with as many fancy technical words as you can think of to confuse the hopeless newbies and teen sysops. 3. The Rules 3.1 The Boss Fight-O-Net should be controlled by whoever's screaming the loudest for democracy. Anyone who wants it that badly should be allowed to go nuts trying to run it. 3.2 Complaints Policy Complaints should be referred to node 1/1, along with all other junk mail. If you send enough, you may wind up running Fight-O-Net! 3.3 Echomail policy Echomail, defined as mail with lots of Echos (Dupe Loops) and lots of missing mail (Caused by dupe killers) is already fascist and governed by non-democratically elected vengeful moderators who don't follow their own rules. It will be ignored by this document, except as precedent for the actions of The Boss. 3.3.1 Echomail renaming Echomail shall be more accurately known as FlameMail. 3.4 Excessively Annoying Systems Excessively Annoying Systems, those run by any member of the Good Old Boys network, shall be dropped from the nodelist until such time as hell freezes over. 3.5 Sense of proportion A sense of proportion is unimportant in Fight-O-Net. 4. Anthem The official song of Fight-O-Net is below. Sing to "America, the Beautiful", or "The Star Spangled Banner", or "We ain't gonna take FidoNews 10-14 Page: 4 05 Apr 1993 it" by Twisted Sister. Democracy, democracy, we pin our hopes on thee, and someday soon, we hope to have, a grunt for Z1C Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam, Spam. 5. Credits, acknowlegments, etc. Fight-O and Fight-O-Net are trademarks of Fight-O software, Inc. I'd also like to thank Nets 2605 and 2606, Richard Bash (for no apparent reason), Pablo Kleinman, Tom Jennings, my mother, and that cute redhead I had a crush on in 6th grade. Next time in the Cynic's Sandbox: Caller ID - For the man who has nothing to hide... ---------------------------------------------------------------------- Why Policy 4.1C deserves our serious attention Why 4.1C deserves our serious attention I read with great interest, two things in last week's edition (1013) of Fidonews; the article about DRAFT008 and the little article by Glen Johnson that preceded the full text of the 4.1C proposal. I'm the 'anonymous' person that wrote the original comparison article a few issues ago. I'm going to remain anonymous, and I'll tell you why. I've seen what has transpired in the many SYSOP-type conferences over the last three months with the policy debates. The group that developed 4.1C was the first on the scene, and they and their proposal were immediately attacked by a number of people for doing so. It was VERY clear to me, at least, that the reason many people assailed their document was because of who the authors were, not what the document said. Probably the most ludicrous of all the things I saw were the many utterly horrifying things said by one Bob Germer, who started calling members of Net 163 names because of their support for democratic reform in Fidonet. And this person developed a policy draft himself! The reason I did my article anonymously, is because I don't want my friends and members of the net I'm in to be categorized, or pre-judged or labelled because of the things -I- say. I offered my honest interperetation of both documents, and you all can take that for what its worth. FidoNews 10-14 Page: 5 05 Apr 1993 I called the other document BAKERPOL because it was distributed by Christopher Baker, the RC of Region 16. I don't know if he wrote it himself, nor do I care. But I called it what I did because I under- stand that he was the person that released it. I don't know Christopher Baker or the other guy, Ken Tuley, and it doesn't even matter. I didn't judge the proposals by the names attached to them, I judged them on their merits. I never much cared about Fidonet policy, because I get my mail, and that's all I ever really cared about. Sure, it bothered me a little that it seemed to be an all-male, political, barb throwing contest at times, but it really wasn't THAT big of an issue with me. Then 4.1C came out, and I read it. And it changed my view of things. Then I read the others that started coming out in rapid-fire succession after it. And they reinforced my new view of things. The 4.1C proposal isn't perfect. But it has something very significant in it; democracy. I've heard the authors of it continually extolling the virtues of what they call the 'one sysop, one vote' concept, and I must say, that I think that's a WONDERFUL concept, and the 4.1C proposal bears that out. I'm thrilled with the idea of letting regular people vote for their coordinators. Giving each sysop a vote brings us all back down to Earth; it puts us all on the same level with one another. After all, people will tend to support, and help, and cooperate, and work with coordinators that are there because we WANT them there as opposed to being PUT there, or elected by only select people (like NCs being the only people 'allowed' to vote for an RC) . Everyone pitches in, everyone has a say, and noone's vote is any 'stronger' than anyone elses. I think its a LOVELY idea. I like the 4.1C proposal over anything that has come out so far because it treats Fidonet as a group of PEOPLE, each with their own equal voice. And coordinators should find it equally appealing, as it will give them the 'warm & fuzzy' feeling of knowing that there's no QUESTION that they have the support of the people they're serving. We've nothing to fear from this proposed policy, I think it'd be good for us. The Regional Coordinators should allow a vote on it to take place. It's only fair. And then if it passes a vote, we'll ALL have an equal opportunity to participate in shaping Fidonet for the future. Give us a chance, please? FidoNews 10-14 Page: 6 05 Apr 1993 Commodore Geos Echo Available Commodore Geos Echo Available by Steve Dressler Even today there are still alot of 8 bit Commodore 64's and 128's out in the market place. Commodore has an operating system called GEOS. GEOS is the Windows environment of the Commodore Business Machines. I have started a GEOS Echo for all people interested in CBM in hopes to gain enough traffic to justify backbone status. The echo is on the E-List, but with little success to date. At the present time, there are around 25 messages a week and growing. People in Zone 3 may request a feed from 3:633/162. Zone 1 may request a feed at 1:154/92 or 1:170/202 or 1:170/610. Each feed is v.32bis, and mine (170/202) is a ZyXEL 19.2k. Steve Dressler is the moderator and Steven Guthrie is the co-moderator (VP of the Tulsa Area Commodore Users Group). Discussions are about, but not limited to, Commodore Geos related topics. It is suprising how serious people take their GEOS in the Commodore world. ---------------------------------------------------------------------- Responce to Stanton McCandlish Chris Farrar 1:246/20 - Windsor, Ontario, Canada 89:488/20 Caller ID Revisited In Fidonews 10-13, Mr. McCandlish had some things to say, and I would like to take the time here to refute them. In keeping with the statement from the Editor, any future responce on Caller ID will be made in the PHONES echo, available from the Fidonet backbone, or via netmail. Netmail, whether or not it has the PVT bit set, can and may be replied to and quoted publically in the PHONES echo. Systems running in the IMEX network, can find a similar conversation in the IMEX.TELECOM echo, available from your echo feed on the IMEX (zone 89) backbone. >I could be slammed harder. I did NOT say that callers should >not have to provide BBSs with correct address, name and phone >number. The last few criticisms of my letter have hinged on True, you didn't say that, but how to you intend to discover if the name, number, and address (if required) _is valid_? I don't know about his system, but every week I have at least a couple of twits who like calling in, and trying to gain access to my system. If they aren't twits, then Ronald Reagan, William Clinton, and Al Gore all decided to call my BBS, one after another, at 2 in the morning. Why don't I beleive that they are the caller's real names? Then again, FidoNews 10-14 Page: 7 05 Apr 1993 I used to have a user, James Bond, (a real person, I saw the birth certificate), who is a real person. With CLID, discovering there is a real Bond, and a fake Reagan, Clinton, et al is a piece of cake. >that there may be a problem. Again I did not say that CID is >Satan incarnate, rather that some thought should be given to its >use and that people should be patient and wait until policy has >been updated and nodelist flags defined to account for CID-only >systems. Is this so difficult to grasp? As for long distance But you have yet to give a valid reason WHY people should wait for new nodelist flags. The technology is available today, why shouldn't it be used? The answer is simple, there is no reason why it shouldn't be implemented. Also, why do we need nodelist flags? CLID can keep a user from connecting with a BBS without stopping a mailer from connecting for mail sessions, and how many users download the nodelist each week for a BBS list anyway. >callers: why verify them? What nut is going to call you long >distance, at THEIR expense to lie to you so they can get an >extra account to cheat SRE with, or whatever? It just isn't >likely. Sorry. There are nuts that will call to upload their favorite trojan and virii, lord knows I've found enough that LD callers have no uploading abilities until after they have been validated. There are people who do get their kicks from uploading virii, and doing it LD makes it harder to track them down. > And finally, the merits of Canadian vs US law is real >neat and all but totally irrelevant. READ the article, for Hardly irrelevant. Laws in countries are different, and you cannot expect that views will be identical between different countries. Living in a border city, I have seen enough people, on both sides of the border, who don't realize that when they pass the line down the middle of the Detroit River, that they are subject to different laws, and regulations. The number of Michigan motorists that get arrested at sobriety roadblocks is proof of that, as they claim them to be unconstitutional, and then want Detroit cops to come and get them, as they don't consider Windsor police officers having any jurisdiction over them. >chrissakes. And only last thing, I just want to emphasize yet >AGAIN that when I say CID harms privacy I am not refer- ring to >sysops, but rather to less savoury folks. By forcing caller ID, >sysops in effect demand that we send caller ID info to ALL >numbers. When the telcos come up with all call blocking that >can be temporarily disabled with a keypad code to dial one >number, then fine, CID your heart out. Until that time comes Why should we wait to implement CLID for your convienence? If you are calling "less savoury folks", you have several options: 1) Install a data line, and call them off it, so if they do call FidoNews 10-14 Page: 8 05 Apr 1993 you back, they will never reach you. 2) Call from work 3) Call from a pay phone 4) Petition whatever group that regulates phones in your state to allow either disabling on a per call basis, or switch to allowing blocking on a per call basis, by dialing your equivelant of *69. And, not everywhere has global blocking, such as there is where you live. Here in Ontario (Canada), the only style of blocking available is the per call, dial a * code, and then make your call, the same way you would go about temporarely disabling Call Waiting to make a data call. >you are doing everyone as disservice by demanding Caller ID >info. Why not USE CID if it is given, and voice verify the rest >without a hassle? Simple. Why should the system operator have to take the time to do voice verifications, when there are faster, easier, and more convienent ways of validation. Voice verification creates longer delays for validation of callers, involves either calling directly, and running up the sysop's phone bill, which is generally high enough already, or calling collect, in which case the sysop's phone number appears on the user's phone bill within a month, removing the sysop's right to privacy. You can then end up having to make several calls to voice verify, if the person isn't in when you call, etc. >PS: the idea that having CID blocking would make someone >prosecutable for un- authorized access is a very silly fantasy. I would suggest that you take a look at Section 342.1 of the Criminal Code (Canada). It specifically spells out what is considered the offence, and the punnishment. 342.1(1) puts it simply and clearly, and very easy to read and understand, as can be seen below: 342.1 (1) Every one who, fraudulently and without color of right, (a) obtains, directly or indirectly, any computer service, (b) by means of an electro-magnetic, acoustic, mechanical or other device, intercepts or causes to be intercepted, directly or indirectly, any function of a computer system, or (c) uses or causes to be used, directly or indirectly, a computer system with intent to commit an offence under paragraph (a) or (b), or an offence under section 430 in relation to data or a computer system is guilty of an offence and liable to imprisonment for a term not exceeding ten years, or is guilty of an offence punishable on summary conviction. (2) In this section, "computer program" means data representing instructions or statements that, when executed in a computer system, causes the computer system to preform a function; "computer service" includes data processing, and the storage or FidoNews 10-14 Page: 9 05 Apr 1993 retrieval of data; "computer system" means a device that, or a group of interconnected or related devices one or more of which, (a) contains computer programs or other data, and (b) pursuant to computer programs, (i) preforms logic and control, and (ii) may preform any other function; "data" means representations of information or of concepts that are being prepared or have been prepared in a form suitable for use in a computer system; "electro-magnetic, acoustic, mechanical or other device" means any device or apparatus that is used or is acapable of being used to intercept any function of a computer system, but does not include a hearing aid used to correct subnormal hearing of the user to not better than normal hearing. "function" includes logic, control, arithmetic, deletion, storage and communication or telecommunication to, from or within a computer system; "intercept" included listen to or record a function of a computer system, or acquire the substance, meaning, or purport thereof. R.S. 1985, c27 Section 430, as mentioned in the above, is in regards to mischief, and mischief in relation to data, including destruction of data. ---------------------------------------------------------------------- OS2 echos From: Byron Miller (1:106/433) Well, here is my first posting to fidonews, and i thought i would pass on some interesting info to my fellow OS/2 SysOps As you may have seen, OS/2 has been growing, and Very Rapidly. Many SysOps Are slowly Converting there BBS over to OS/2, but i hear lots of complaints about the limited supply of OS/2 speceific BBS software. Pete Norloff has taken the stand has started the OS2BBS_DEV echo... This echo is for the Discussion of OS/2 BBS programing and requests and ideas that people would like to see in a BBS System. Many OS/2 programmers are starting to find their way to the echo, and we are looking for some more talented people to jump in.. The following Systems carry the echo, and would happily send it to you upon request. 1:292/60 1:280/304 1:110/535 1:289/27 1:202/514 1:201/2104 1:273/714 FidoNews 10-14 Page: 10 05 Apr 1993 I Hope to see some great programmers jump in, and look forward to seeing the Best BBS packages for OS/2 anytime soon.. And while were discussing OS/2... you might like to find out more info so here are some of the Non-Backbone Echo's that Might be of Interest to All. OS2BEGIN Beginners Questions And Answers OS2BBS_DEV Developing/Programming OS/2 specific BBS software/utils OS2CDROM Using CD-ROMS with OS/2 OS2COMM Communications with OS/2 via networks such as TCP/IP OS2DP Development/Use of Databases under OS/2 OS2DOS Using/Configuring programs to run under OS/2 DOS box OS2GAMES Running games under OS/2, great info to get Games to work right OS2REXX Programming and using REXX under OS/2 OS2VIDEO Video Drivers, hardware, and configuring options OS2WPS Using the OS/2 "W"ork "P"lace "S"hell OS2WP Word Processing under OS/2 OS2_13 Using, Discussion about OS/2 1.3 TEAMOS2 Users sharing ideas on use of OS/2 and its promotion. These echos are available on MANY OS/2 BBS's and should be requestable from the nodes listed above. Hope to see many of you in Fidonet in these echos! Byron Miller SysOp of North Shore BBS (OS/2 BBS of Course) 1:106/433 ---------------------------------------------------------------------- Policy Proposals: The Cart Before the Horse? Jack Decker Fidonet 1:154/8 Policy Proposals: The Cart Before the Horse? I've been reading the articles on the proposed revisions to Policy 4, and while I agree that there is a crying need to replace Policy 4, I get the feeling that both proposals are an attempt to provide better ways to put out flames without ever addressing the actual cause of the fires. I just want to make a couple of comments that I wish the authors of these proposals would consider. First and most important, please let technology take care of technological problems. Fidonet policy is primarily a political document, telling us how we are supposed to interact with each other. The trouble is, it is so long that many sysops never read the whole thing, and fewer remember enough of what they read to really affect their day-to-day operations. Fidonet isn't a government, it's a hobby, so why try to make governmental type regulations? Suppose we could spend less time worrying about how people in Fidonet FidoNews 10-14 Page: 11 05 Apr 1993 relate to each other? We'd have fewer flames, our policy document could be shorter and more concise, and everyone would lead a generally happier life (one would hope so, anyway)! What are the major causes of flames and disagreements in Fidonet? No, I don't mean the APPARENT cause, I mean the ROOT cause. These are often two entirely different things. Many policies were invoked to solve specific problems that may have been known only to a few. These root problems were responsible for the creation of perhaps a whole body of policy (formal or informal) that may now be a problem in itself. As an example, consider that the ever-expanding size of the Fidonet nodelist has been responsible for a whole host of proposals, the net effect of which would be to exclude some nodes from the nodelist. Many of the arguments over what status points should have could be more easily resolved if points could somehow be included in the nodelist, but at this point NO ONE wants to see the nodelist grow any larger. Or consider the totally screwed up format of Fidonet echomail messages. I have yet to hear from anyone who does not agree that the current Fidonet message format leaves a lot to be desired (and is a programmer's nightmare!), but what you may not realize is that the lack of effective duplicate message control was in part responsible for some of the ridiculous geographic restrictions found in Fidonet policy (at least, that was the claim at the time the restrictions were added... more on that later). How do we deal with these problems? Unfortunately, because few seem to recognize the root cause of such problems, we attempt political fixes that no one's really happy with (not even the so-called power mongers after a while, because they become targets for all the flak). I would like to suggest that any new Policy document should give us some mechanism for effecting TECHNICAL changes to Fidonet that could do far more to help us solve our problems than any amount of words on paper ever could. Therefore, I'd like to make a couple of proposals for the next Policy document: First, give at least the IC, and hopefully others in Fidonet the right to open discussion on technical matters in Fidonet, with the idea of setting or revising Fidonet technical standards. This should be at least a semi-orderly process and should include specific time frames for each part of the process. Here's one possible outline of the process: 1) Initial discussion phase: Is it broke? Do we need to fix it? What would we like to see in any new proposals? (Example: Do we need a new nodelist format? Should we stop issuing a nodelist covering all zones? What are the problems with the present format?) 2) Request for proposals: In this phase we ask interested groups or individuals to submit FORMAL proposals for the new standard. There should be a deadline date for this! FidoNews 10-14 Page: 12 05 Apr 1993 3) Discussion of proposals: A time period where the proposals are made available to any interested party. Comments go back to the authors of the proposals, who basically have the freedom to modify their proposals based on user input. Consolidation of similar proposals would be encouraged. 4) Release of final draft of proposals: After comments have been received, the authors would release their final drafts of their proposals. 5) Vote on the proposals: At this point the proposals under consideration would be voted on. If no one proposal receives a clear majority, a runoff vote may be necessary. Again, a specific date should be set for the vote, lest it be put off indefinitely (it's only a hobby, so folks tend to procrastinate)! 6) Implementation of the proposals: This should be far enough in the future to allow software authors time to make any adjustments needed to their software. Again, the above is only a possible outline. My point is that we need SOME sort of mechanism like this, clearly defined in Policy. The current system (arguing the subject in the NET_DEV echo until everyone is sick of it!) doesn't make it. If the current system worked, something would have been done about the nodelist problem years ago. As it is, we are helpless to make needed technical changes because we have no official mechanism in place to make those changes. This is something that REALLY needs to be included in the next Policy, in my opinion. I mentioned the Fidonet message format earlier. Just about all the technically-minded folks agree it's a nightmare, yet I think probably thousands of person-hours of effort have gone into creating proposals for a new message format. Some were posted in NET_DEV, some were published in Fidonews, but in the end they all suffered the same fate: They were all eventually ignored! Not because the proposals were all bad, but because there's simply no process in place that allows them to be formally considered by the net as a whole. Now, I personally think we should just adopt the standard message format used in the Internet (as described in Internet document RFC-1136 and similar documents), possibly with some Fidonet-specific extensions (message header lines that start with "X-FTN-:" for Fidonet specific information). This would make us far more compatible with the Internet, and avoid all the pitfalls now associated with echomail-to-newsgroup conversion (something that a growing number of sysops seem to be interested in). But in any case, something needs to be done, because many of our flame wars can be traced to the message format! Why?!?, I hear you ask. Well, consider that the insane geographic restrictions found in Policy 4 were only added in that document... that is to say, there were no such restrictions in Policy 3 and earlier documents. And the important thing to keep in mind is that the justification for adding these restrictions was almost entirely based FidoNews 10-14 Page: 13 05 Apr 1993 on on the existence of dupe loops in echomail. Now, some of us may believe that wasn't the REAL reason (in fact, one report that came to me was that the restrictions were added at the request of ONE RC who didn't like the idea that nodes could "opt out" of being in HIS region) but it doesn't really matter; the point is that the (POLITICAL) restrictions were justified due to the (TECHNICAL) problems of echomail dupes! As it turned out, the restrictions didn't fix the problem (in fact, the greatest advances in duplicate message elimination have come about because of improved software that catches and rejects dupes) but we have to live with them. And, of course, the geographic restrictions remove the option of "voting with your feet" (in a figurative sense) if you can't get along with the NC or RC above you. I don't mean to sound provincial, but it surprises me especially that North American sysops who would scream bloody murder if told they could only shop at one particular supermarket or eat at one particular restaurant (based solely on where they live) will so easily accept the notion that they can participate in their hobby via only one point of contact based on their geographic location. Many of the disputes we have in Fidonet could be resolved rather painlessly (for all concerned) if folks who just plain don't like each other weren't forced to interact with each other. Consider all the messages you've read were someone didn't get along with their NC or RC... wouldn't it save us all a lot of anguish if that person could simply find another net to join? Yeah, I know that for some reason that concept is considered heresy in Fidonet, but I don't understand why. The Internet, and many other nets work quite well without imposing such stupid restrictions (although the Internet has what might be considered an opposite problem... because folks there AREN'T required to associate with each other, it sometimes happens that someone who wants a feed can't get one locally, because none of the local folks already connected to the Internet want to give a feed to the new person. I'm NOT saying we should go to that extreme... sysops should be ALLOWED to join their local net, but not REQUIRED to). So, along with some mechanism for getting technical changes implemented in Fidonet, I'd like to see the removal of sections of Policy that attempt to compensate for technical shortcomings with political solutions. The ridiculous geographic restrictions are a prime example, but there are other such things buried in there. Maybe we could even shorten Policy enough so that folks would READ it! Anyway, please give this some consideration, and please remember that Fidonet Policy affects all sysops in all zones, and we should not lightly add things to Policy just to resolve some specific local conflict. But above all, don't put the "cart before the horse" by just adding new regulations without giving us some way to fix the underlying technical problems. Let's start finding technical solutions to those problems! FidoNews 10-14 Page: 14 05 Apr 1993 Rebuttal to an Anonymous Critic A Non-Anonymous Reply on Policy Draft Differences Ken Tuley, 1:374/98 Having openly asked for comments and suggestions in every echomail and netmail contact in which I have discussed ideas for future Policy, I was a little disappointed to see the level of disinformation included in the article in FNEWSA12 by an anonymous "analyst". Hopefully, those who went on to read the draft itself could see through the smoke and mirrors of selective quoting and recombination of statements, but I feel compelled to respond for the sake of clarity. Also for clarity, I have taken the liberty of replacing references to the draft with its name as distributed [DRAFT008]. > [DRAFT008] 4.1C > NC,RC selection not specific, each net Democratic > has its own method elections > one sysop one > vote. Term is > No term two years These are specifically designated as being determined by local policies developed by the SYSOPS of those nets/regions. > (Policy 4.1C requires a 2/3 majority of the Zone Coordinators to > elect an Internation Coordinator. [DRAFT008] requires just a > majority of the ZCs and give control of the election to the RCs if > the ZCs can't seem to come up with a winner.) Given the difficulty 10 zone 1 RCs had deciding on a ZC, it seemed reasonable to allow a fall-back selection process that involved a larger voting pool. The difference between "majority" and "2/3" is a single person. > Replacement of By RC,ZC regardless 20% below can call > NC,RC of sysops a sysop election. > wishes. to replace,limited The interesting distinction here is that 4.1c continues to make the RC responsible for the NCs (and ZC for RCs), but provides no authority to act. DRAFT008 provides for the TEMPORARY replacement of an RC or NC sho is not performing his duties only until the local policy can be invoked to select a replacement. The *C is obligated to support the wishes of the majority of sysops in the affected net/region. FidoNews 10-14 Page: 15 05 Apr 1993 > The Policy 4.1C proposal gives SYSOPS the authority to recall or > replace coordinators whom they feel are not performing. What about the *C above who is responsible for his actions?? > [DRAFT008] on the other hand, gives unlimited authority to the RCs > to replace an NC, and unlimited authority to the ZC to replace an > RC. Not unlimited... The RC may remove an NC for failure to perform the duties listed in Fidonet Policy and HAVE THE NET MEMBERSHIP SELECT A REPLACEMENT. The same applies to the ZC for an RC. Under [DRAFT008], all 2000 sysops in a Region could object to the removal of their RC, yet the ZC would still have the authority to do so.) > Local policies > The 4.1C proposal keeps a unified Fidonet under one basic set of > guidelines. It also provides for the implementation of local > policies provided that they are not more RESTRICTIVE than 4.1C > itself. This is essentially the same in both drafts, except that DRAFT008 gives an example of one thing that might "ordinarily" be in a local policy. > [DRAFT008] allows for local definition of what should be net-wide. > Like what "excessively annoying" is.) Wrong! DRAFT008 refers to "Fidonet Policy" for the definition of excessively annoying. It simply requires that applicants for node numbers familiarize themselves with applicable local policies as well. > Points Access can be refused no change from > existing Since any sysop may refuse access to any user, neither of these is a change from existing policy. DRAFT008 simply reinforces the fact than running a mailer as a point does not automatically grant you access to all systems. > Excommunications Notice to next level no change from > required existing FidoNews 10-14 Page: 16 05 Apr 1993 No argument here. I would expect most excommunications to be appealed, so I believe it reasonable to notify the *C above if you have done so. It just prevents surprises. > Policy Ratification Can be selectively Whole document > changed by section. must be presented > (Fidonet has always adopted entire policy documents, not amendments > by section. The reasons why are even stated in current policy. The reason stated is "to simplify the process". I think the sysops of Fidonet are capable of dealing with sectional amendments, and allowing them helps to focus attention on the specific changes offered. Besides, "always" is a misdirected term, since provisions for adoption of new policies didn't even exist prior to the current policy. > (A significant change in 4.1C over current policy is that it moves > the level of approval of policy referendums DOWN a notch to the NC > level. [DRAFT008] still gives complete control over policy > referendums to the RCs) I have already stated in public discussions that I would support addition of a threshold for NCs to trigger a referendum, but the 4.1c proposal of 5% is absurd (that's 29 NCs at the present time). There are more nets than that in the state of Florida alone! Something like 50% of the RCs 'or' 20% of the NCs would be more reasonable (IMO). > How local policy comes into existence is not specified in > [DRAFT008], yet the *C structure is required to abide by it when > judging "excessively annoying". I don't know where this came from. The *C structure is required to abide by local policies in recognizing the *C selected under it, but the section on resolution of disputes that talks about excessively annoying behavior makes no reference to local policies. > [DRAFT008] introduces more uncertainty into Fidonet as there can be > as many "policies" on a local level as there are nets+regions+zones > and they may CONFLICT with each other. Granted, but they may not conflict with any policy above them. This is already the case. Some nets have policies on cost recovery, outbound netmail routing, hub responsibilities and other procedures that vary from one net to another. I don't see FidoNews 10-14 Page: 17 05 Apr 1993 this as a problem. The biggest difference between DRAFT008 and 4.1c is in where the responsibility lies to make the democratic process work. DRAFT008 puts it in the hands of the local sysops through encouragement of local policies consistent with Fidonet Policy. 4.1c puts it in the hands of the IC to develop some unknown future procedure for accomplishing its goals. ---------------------------------------------------------------------- FidoNet Policy Document Version 5 FidoNet Policy Document Version 5 Draft 008 03/12/93 1 Overview This document establishes the policy for sysops who are members of the FidoNet organization of electronic mail systems. FidoNet is defined by a NodeList issued weekly by the International Coordinator. Separate policy documents may be issued at the zone, region, or net level to provide additional detail on local procedures. Ordinarily, these lower- level policies may not contradict this policy, but will add procedural information specific to those areas, such as methods of coordinator selection. However, with the approval of the International Coordinator, local policy can be used to implement differences required due to local conditions. These local policies may not place additional restrictions on membership in FidoNet beyond those included in this document, other than enforcement of local mail periods. 1.0 Language To facilitate the largest possible readership, all international Fidonet documents will be written in English. Translation into other languages is encouraged. 1.1 Introduction FidoNet is an amateur electronic mail system. As such, all of its participants and operators are unpaid volunteers. From its early beginning as a few friends swapping messages back and forth (1984), it now (1993) includes over 20,000 systems on six continents. FidoNet is not a common carrier or a value-added service network and is a public network only in as much as the independent, constituent nodes may individually provide public access to the network through their systems. FidoNews 10-14 Page: 18 05 Apr 1993 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 describes the procedures which have been developed to manage the network. 1.2 Organization FidoNet systems are grouped on several levels, and administration is decentralized to correspond to these groupings. This overview provides a summary of the structure; specific duties of the coordinator positions are given later in the document. 1.2.1 Individual Systems and System Operators The smallest subdivision of FidoNet is the individual system, corresponding to a single entry in the nodelist. The system operator (sysop) formulates a policy for running the board and dealing with users if the sysop provides access to others through that node. The sysop must mesh with the rest of the FidoNet system to send and receive mail, and the local policy must be consistent with other levels of FidoNet. BBS operation is not required to be a Fidonet sysop. 1.2.1.1 Users The sysop is responsible for the actions of any user when they affect the rest of FidoNet. (If a user is annoying, the sysop is annoying.) Any traffic entering FidoNet via a given node, if not from the sysop, is considered to be from a user and is the responsibility of the sysop. (See section 2.1.3.) 1.2.1.2 Points A point is a FidoNet-compatible system that is not in the nodelist, but communicates with FidoNet through a node referred to as a bossnode. A point is generally regarded in the same manner as a user, for example, the bossnode is responsible for mail from the point. (See section 2.1.3.) Points are addressed by using the bossnode's nodelist address; for example, a point system with a bossnode of 114/15 might be known as 114/15.12. Mail destined for the point is sent to the bossnode, which then routes it to the point. In supporting points, the bossnode may make use of a private net number which should not be generally visible outside of the bossnode-point relationship. Unfortunately, should the point call another system directly (to do a file request, for example), the private network number will appear as the caller's address. In this way, points are different from users, since they operate FidoNet-compatible mailers which are capable of contacting systems other than the bossnode. Outside the local FidoNews 10-14 Page: 19 05 Apr 1993 bossnode, a point may be refused access to other Fidonet systems since points are considered users and sysops have full control over users' access to their systems. 1.2.2 Networks and Network Coordinators A network is a collection of nodes in a local geographic area, usually defined by an area of convenient telephone calling. Networks coordinate their mail activity to decrease cost. The Network Coordinator is responsible for maintaining the list of nodes for the network, and for forwarding netmail sent to members of the network from other FidoNet nodes. The Network Coordinator may make arrangements to handle outgoing netmail, but is not required to do so. The Network Coordinator is selected by the nodes of that net. Nets are encouraged to formulate policies regarding the mechanism for accomplishing this. 1.2.2.1 Network Routing Hubs Network Routing Hubs exist only in some networks. They may be appointed by the Network Coordinator, in order to assist in the management of a large network. The exact duties and procedures are a matter for the Network Coordinator and local policy to arrange, and will not be discussed here, except that a network coordinator may not delegate responsibility to mediate disputes. 1.2.3 Regions and Regional Coordinators A region is a well-defined geographic area containing nodes which may or may not be combined into networks. A typical region will contain many nodes in networks, and a few independent nodes which are not a part of any network. The Regional Coordinator maintains the list of independent nodes in the region and accepts nodelist segments from the Network Coordinators in the region. These are compiled to create a regional nodelist, which is then sent to the Zone Coordinator. A Regional Coordinator does not perform message-forwarding services for any nodes in the region. The Regional Coordinator may participate in netmail routing between the coordinator levels, but is not required to do so. Regional Coordinators are selected by the nodes of that region. Regions are encouraged to formulate policies regarding the mechanism for accomplishing this. 1.2.4 Zones and Zone Coordinators A zone is a large geographic area containing many regions, covering one or more countries and/or continents. The Zone Coordinator compiles the nodelist segments from all of FidoNews 10-14 Page: 20 05 Apr 1993 the regions in the zone, and creates the master nodelist and difference file, which is then distributed over FidoNet in the zone. A Zone Coordinator does not perform message-forwarding services for any nodes in the zone. The Zone Coordinator may participate in netmail routing among the coordinator levels, but is not required to do so. Zone Coordinators are selected by the Net and Regional Coordinators in that zone as representatives of the nodes to whom they provide service (see section 8.3). 1.2.5 Zone Coordinator Council In certain cases, the Zone Coordinators work as a council to provide advice to the International Coordinator. The arrangement is similar to that between a president and advisors. In particular, this council considers inter-zone issues. This includes, but is not limited to: working out the details of nodelist production, mediating inter-zone disputes, and such issues not addressed at a lower level of FidoNet. 1.2.6 International Coordinator The International Coordinator coordinates the joint production of the master nodelist by the Zone Coordinators. The International Coordinator acts as the chair of the Zone Coordinator Council and as the overseer of Fidonet-wide elections -- arranging the announcement of referenda, the collection and counting of the ballots, and announcing the results for those issues that affect FidoNet as a whole. The International Coordinator is selected by the Zone Coordinators. See section 7.2. 1.2.7 Top-down Organization. Checks and Balances. These levels act to distribute the administration and control of FidoNet to the lowest possible level, while still allowing for coordinated action over the entire mail system. Administration is made possible by operating in a top-down manner. That is, a person at any given level is responsible to the level above, and responsible for the level below. For example, a Regional Coordinator is responsible to the Zone Coordinator for anything that happens in the region. From the point of view of the Zone Coordinator, the Regional Coordinator is completely responsible for the smooth operation of the region. Likewise, from the point of view of the Regional Coordinator, the Network Coordinator is completely responsible for the smooth operation of the network. If a person at any level above sysop is unable to properly perform their duties, the coordinator at the next level may replace them. For example, a Regional Coordinator who fails to FidoNews 10-14 Page: 21 05 Apr 1993 perform may be replaced by the Zone Coordinator. Interim replacements will be appointed until such time as a formal replacement can be selected under the local or regional policies. Such appointments will be considered final in the absence of such policies. To provide for checks and balances at the highest level of FidoNet, there is an exception to this top-down organization. The International Coordinator is selected by a majority vote of the coordinators of the Zone Coordinators (see section 7.2). Similarly, decisions made by the International Coordinator can be reversed by the Zone Coordinator Council. Decisions made by other coordinators are not subject to reversal by a vote of the lower level, but instead are subject to the appeal process described in section 9.5. 1.3 Definitions 1.3.1 FidoNews FidoNews is a weekly newsletter distributed in electronic form throughout the network. It is an important medium by which FidoNet sysops communicate with each other. FidoNews provides a sense of being a community of people with common interests. Accordingly, sysops and users are encouraged to contribute to FidoNews. Contributions are submitted to the node listed in Fidonews and in the nodelist for that purpose; a file describing the format to be used is available from that and many other systems. 1.3.2 Geography Each level of FidoNet is geographically contained by the level immediately above it. A given geographic location is covered by one zone and one region within that zone, and is either in one network or not in a network. There are never two zones, two regions, or two networks which cover the same geographic area. If a node is in the area of a network, it should be listed in that network, not as an independent in the region. (The primary exception to this is a node receiving inordinate amounts of host-routed mail; see section 4.2). Network boundaries are based on calling areas as defined by the local telephone company. Even in the case of areas where node density is so great that more than one network is needed to serve one local calling area, a geographic guideline is used to decide which nodes belong to what network. Network membership is based on geographic or other purely technical rationale. It is not based on personal or social factors. There are cases in which the local calling areas lead to situations where logic dictates that a node physically in one FidoNet Region should be assigned to another. In those cases, with the agreement of the Regional Coordinators and Zone Coordinator involved, exemptions may be granted. Such exemptions FidoNews 10-14 Page: 22 05 Apr 1993 are described in section 5.6. 1.3.3 Zone Mail Hour Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are required to be able to accept netmail. Each Fidonet zone defines a ZMH and publishes the time of its ZMH to all other Fidonet zones. See sections 2.1.8 and Appendix 1. 1.3.4 Nodelist The nodelist is a file updated weekly which contains the addresses of all recognized FidoNet nodes. This file is currently made available by the Zone Coordinator not later than Zone Mail Hour each Friday, and is available electronically for download or file request at no charge. To be included in the nodelist, a system must meet the requirements defined by this document. No other requirements may be imposed. Partial nodelists (single-zone, for example) may be made available at different levels in FidoNet. The full list as published by the International Coordinator is regarded as the official FidoNet nodelist, and is used in circumstances such as determination of eligibility for voting. All parts that make up the full nodelist are available on each Zone Coordinator's and each Regional Coordinator's system. 1.3.5 Excessively Annoying Behavior There are references throughout this policy to "excessively annoying behavior", especially in section 9 (Resolution of Disputes). It is difficult to define this term, as it is based upon the judgement of the coordinator structure. Generally speaking, annoying behavior irritates, bothers, or causes harm to some other person. It is not necessary to break a law to be annoying. There is a distinction between excessively annoying behavior and (simply) annoying behavior. For example, there is a learning curve that each new sysop must climb, both in the technical issues of how to set up the software and the social issues of how to interact with FidoNet. It is a rare sysop who, at some point in this journey, does not manage to annoy others. Only when such behavior persists, after being pointed out to the sysop, does it becomes excessively annoying. This does not imply that it is not possible to be excessively annoying without repetition (for example, deliberate falsification of mail would likely be excessively annoying on the very first try), but simply illustrates that a certain amount of tolerance is extended. See section 9 for more information. 1.3.6 Commercial Use FidoNews 10-14 Page: 23 05 Apr 1993 FidoNet is an amateur network. Participants spend their own time and money to make it work for the good of all the users. It is not appropriate for a commercial enterprise to take advantage of these volunteer efforts to further their own business interests. On the other hand, FidoNet provides a convenient and effective means for companies and users to exchange information, to the mutual benefit of all. Network Coordinators could be forced to subsidize commercial operations by forwarding host-routed netmail, and could even find themselves involved in a lawsuit if any guarantee was suggested for mail delivery. It is therefore FidoNet policy that commercial mail is not to be routed. "Commercial mail" includes mail which furthers specific business interests without being of benefit to the net as a whole. Examples include company- internal mail, inter-corporate mail, specific product inquiries (price quotes, for instance), orders and their follow-ups, and all other subjects specifically related to business. 2 Sysop Procedures 2.1 General 2.1.1 The Basics As the sysop of an individual node, you can generally do as you please, as long as you operate a mailer compatible with FTS-0001 specifications, observe mail events, are not excessively annoying to other nodes in FidoNet, and do not promote or participate in the distribution of pirated copyrighted software or other illegal behavior via FidoNet. 2.1.2 Familiarity with Policy In order to understand the meaning of "excessively annoying", it is incumbent upon all sysops to occasionally re-read FidoNet policy. New sysops must familiarize themselves with this policy and any applicable local, regional or zone policies before requesting a node number. 2.1.3 Responsible for All Traffic Entering FidoNet Via the Node The sysop listed in the nodelist entry is responsible for all traffic entering FidoNet via that system. This includes (but is not limited to) traffic entered by users, points, and any other networks for which the system might act as a gateway. If a sysop allows "outside" messages to enter FidoNet via the system, the gateway system must be clearly identified by FidoNet node number as the point of origin of that message, and it must act as a gateway in the reverse direction. Should such traffic result in a violation of Policy, the sysop must rectify the situation as soon as notified. 2.1.4 Encryption and Review of Mail FidoNews 10-14 Page: 24 05 Apr 1993 FidoNet is an amateur system. Our technology is such that the privacy of messages cannot be guaranteed. As a sysop, you have the right to review traffic flowing through your system, if for no other reason than to ensure that the system is not being used for illegal or commercial purposes. Encryption obviously makes this review impossible. Therefore, encrypted and/or commercial traffic that is routed without the express permission of all the links in the delivery path constitutes annoying behavior. See section 1.3.6 for a definition of commercial traffic. 2.1.5 No Alteration of Routed Mail You may not modify, other than as required for routing or other technical purposes, any message, netmail or echomail, passing through the system from one FidoNet node to another. If you are offended by the content of a message, the procedure described in section 2.1.7 must be used. 2.1.6 Private Netmail The word "private" should be used with great care, especially with users of a BBS. Some countries have laws which deal with "private mail", and it should be made clear that the word "private" does not imply that no person other than the recipient can read messages. Sysops who cannot provide this distinction should consider not offering users the option of "private mail". If a user sends a "private message", the user has no control over the number of intermediate systems through which that message is routed. A sysop who sends a message to another sysop can control this aspect by sending the message direct to the recipient's system, thus guaranteeing that only the recipient or another individual to whom that sysop has given authorization can read the message. Thus, a sysop may have different expectations than a casual user. 2.1.6.1 No Disclosure of in-transit mail Disclosing or in any way using information contained in private netmail traffic not addressed to you or written by you is considered annoying behavior, unless the traffic has been released by the author or the recipient or is a part of a formal policy complaint. This does not apply to echomail which is by definition a broadcast medium, and where private mail is often used to keep a sysop-only area restricted. 2.1.6.2 Private mail addressed to you The issue of private mail which is addressed to you is more difficult than the in-transit question treated in the previous section. A common legal opinion holds that when you receive a message it becomes your property and you have a legal right to do with it what you wish. Your legal right does not excuse you from annoying others. FidoNews 10-14 Page: 25 05 Apr 1993 In general, sensitive material should not be sent using FidoNet. This ideal is often compromised, as FidoNet is our primary mode of communication. In general, if the sender of a message specifically requests in the text of the message that the contents be kept confidential, release of the message into a public forum may be considered annoying. There are exceptions. If someone is saying one thing in public and saying the opposite in private mail, the recipient of the private mail should not be subjected to harassment simply because the sender requests that the message not be released. Judgement and common sense should be used in this area as in all other aspects of FidoNet behavior. 2.1.7 Not Routing Mail You are not required to route traffic if you have not agreed to do so. You are not obligated to route traffic for all if you route it for any, except as required of a Net Coordinator if you hold that position. Routing traffic through a node not obligated to perform routing without the permission of that node may be annoying behavior. This includes unsolicited echomail. If you do not forward a message when you previously agreed to perform such routing, the message must be returned to the sysop of the node at which it entered FidoNet with an explanation of why it was not forwarded. (It is not necessary to return messages which are addressed to a node which is not in the current nodelist.) Intentionally stopping an in-transit message without following this procedure constitutes annoying behavior. In the case of a failure to forward traffic due to a technical problem, it does not become annoying unless it persists after being pointed out to the sysop. 2.1.8 Exclusivity of Zone Mail Hour Zone Mail Hour is the heart of FidoNet, as this is when network mail is passed between systems. Any system which wishes to be a part of FidoNet must be able to receive mail during this time using the protocol defined in the current FidoNet Technical Standards Committee publication (FTS-0001 at 2this writing). It is permissible to have greater capability (for example, to support additional protocols or extended mail hours), but the minimum requirement is FTS-0001 capability during this one hour of the day. This time is exclusively reserved for netmail. Many phone systems charge on a per-call basis, regardless of whether a connect, no connect, or busy signal is encountered. For this reason, any activity other than normal network mail processing that ties up a system during ZMH is considered annoying behavior. Echomail should not be transferred during ZMH. User (BBS) access to a system is prohibited during ZMH. File requests should not be honored during ZMH. FidoNews 10-14 Page: 26 05 Apr 1993 A system which is a member of a local network may also be required to observe additional mail events, as defined by the Network Coordinator. Access restrictions during local network periods are left to the discretion of the Network Coordinator as defined in local policy. 2.1.9 Private Nodes The rare exception to ZMH compliance is private nodes. Persons requesting private nodes should be supported as points if possible. A private listing is justified when the system must interface with many others, such as an echomail distributor. In these cases, the exact manner and timing of mail delivery is arranged between the private node and other systems. Such an agreement between a private system and a hub is not binding on any replacement for that hub. A private node must be a part of a network (they cannot be independents in the region.) Private listings affect each member of FidoNet, since they take up space in everyone's nodelist. Private listings which are for the convenience of one sysop (at the expense of every other sysop in FidoNet) are a luxury which is no longer possible. Non-essential redundant listings (more than one listing for the same telephone number, except as mandated by FTSC standards) also fall into this category. Sysops requesting private or redundant listings must justify them with a statement explaining how they benefit the local net or FidoNet as a whole. The Network Coordinator or Regional Coordinator may review this statement at any time and listings which are not justified will be removed. 2.1.10 Observing Mail Events Failure to observe the proper mail events is grounds for any node to be dropped from FidoNet without notice (since notice is generally given by netmail). 2.1.11 Use of Current Nodelist Network mail systems generally operate unattended, and place calls at odd hours of the night. If a system tries to call an incorrect or out-of-date number, it could cause some poor citizen's phone to ring in the wee hours of the morning, much to the annoyance of innocent bystanders and civil authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical. 2.1.12 Excommunication A system which has been dropped from the network is said to be excommunicated (i.e. denied communication). If you find that you have been excommunicated without warning, your coordinator was unable to contact you. You should rectify the problem and contact your coordinator. FidoNews 10-14 Page: 27 05 Apr 1993 Systems may also be dropped from the nodelist for cause. See sections 4.3, 5.2, and 9. It is considered annoying behavior to assist a system which was excommunicated in circumventing that removal from the nodelist. For example, if you decide to provide an echomail feed to your friend who has been excommunicated, it is likely that your listing will also be removed. 2.1.13 Timing of Zone Mail Hour The exact timing of Zone Mail Hour for each zone is set by the Zone Coordinator. See Appendix 1. 2.1.14 Non-observance of Daylight Savings Time FidoNet does not observe daylight savings time. In areas which observe daylight savings time the FidoNet mail schedules must be adjusted in the same direction as the clock change. Alternatively, you can simply leave your system on standard time. 2.2 How to obtain a node number You must first obtain a current nodelist so that you can send mail. You do not need a node number to send mail, but you must have one in order for others to send mail to you. The first step in obtaining a current nodelist is to locate a FidoNet bulletin board. Most bulletin board lists include at least a few FidoNet systems, and usually identify them as such. Use a local source to obtain documents because many networks have detailed information available which explains the coverage area of the network and any special requirements or procedures. Once you have a nodelist, you must determine which network or region covers your area. Regions are numbered 10-99; network numbers are greater than 99. Networks are more restricted in area than regions, but are preferred since they improve the flow of mail and provide more services to their members. If you cannot find a network which covers your area, then pick the region which does. Once you have located the network or region in your area, send a message containing a request for a node number to node zero of that network or region. The request must be sent by netmail, as this indicates that your system has FidoNet capability. You must set up your software so that the from-address in your message does not cause problems for the coordinator who receives it. If you pick the address of an existing system, this will cause obvious problems. If your software is capable of using address -1/-1, this is the traditional address used by potential sysops. Otherwise use net/9999 (e.g. if you are applying to net 123, set your system up as 123/9999). Many nets have specific FidoNews 10-14 Page: 28 05 Apr 1993 instructions available to potential sysops and these procedures may indicate a preference for the from-address. The message you send must include at least the following information: 1) Your name. 2) The phone number to be used when calling your system. 3) The name of your system. 4) The city and state where your system is located. 5) Your voice phone number. 6) Your hours of netmail operation. 7) The maximum baud rate you can support. 8) The type of mailer software and modem you are using. Your coordinator may contact you for additional information. All information submitted will be kept confidential and will not be supplied to anyone except the person who assumes the coordinator position at the resignation of the current coordinator. You must indicate that you have read, and agree to abide by, this document and all the current policies of FidoNet. Please allow at least two weeks for a node number request to be processed. If you send your request to a Regional Coordinator, it may forwarded to the appropriate Network Coordinator. 2.3 If You are Going Down If your node will be down for an extended period (more than a day or two), inform your coordinator as soon as possible. It is not your coordinator's responsibility to chase you down for a status report, and if your system stops accepting mail it will be removed from the nodelist. Never put an answering machine or any other device which answers the phone on your phone line while you are down. If you do, calling systems will get the machine repeatedly, producing large phone bills, which is very annoying. In short, the only thing which should ever answer the telephone during periods when the nodelist indicates that your node will accept mail is FidoNet-compatible software which accepts mail. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your coordinator. Systems have a tendency to "crash" now and then, so you will probably want your coordinator to know that it is a temporary condition if it happens while you are away. 2.4 How to Form a Network If there are several nodes in your area, but no network, a new network can be formed. This has advantages to both you and to FidoNews 10-14 Page: 29 05 Apr 1993 the rest of FidoNet. You receive better availability of nodelist difference files and FidoNews, and everyone else can take advantage of host-routing netmail to the new network. The first step is to contact the other sysops in your area. You must decide which nodes will comprise the network, and which of those nodes you would like to be the Network Coordinator. Then consult your Regional Coordinator. You must send the following information: 1) The region number(s), or network number(s) if a network is splitting up, that are affected by the formation of your network. The Regional Coordinator will inform the Zone Coordinator and the coordinators of any affected networks that a new network is in formation. 2) A copy of the proposed network's nodelist segment. This file should be attached to the message of application for a network number, and should use the nodelist format described in the current version of the appropriate FTSC publication. Please elect a name that relates to your grouping, for example SoCalNet for nodes in the Southern California Area and MassNet West for the Western Massachusetts Area. Remember if you call yourself DOGNET it doesn't identify your area. Granting a network number is not automatic. Even if the request is granted, the network might not be structured exactly as you request. Your Regional Coordinator will review your application and inform you of the decision. Do not send a network number request to the Zone Coordinator. All network number requests must be processed by the Regional Coordinator. 3 General Procedures for All Coordinators 3.1 Make Available Difference Files and FidoNews Each Coordinator is responsible for obtaining and making available, on a weekly basis, nodelist difference files and FidoNews. 3.2 Processing Nodelist Changes and Passing Them Upstream Each coordinator is responsible for obtaining nodelist information from the level below, processing it, and passing the results to the level above. The timing of this process is determined by the requirements imposed by the level above. 3.3 Ensure the Latest Policy is Available A Coordinator is responsible to make the current version of this document available to the level below, and to encourage familiarity with it. FidoNews 10-14 Page: 30 05 Apr 1993 In addition, a coordinator is required to forward any local policies received to the level above, and to review such policies. Although not required, common courtesy dictates that when formulating a local policy, the participation of the level above should be solicited. 3.4 Minimize the Number of Hats Worn Coordinators are encouraged to limit the number of FidoNet functions they perform. A coordinator who holds two different positions compromises the appeal process. For example, if the Network Coordinator is also the Regional Coordinator, sysops in that network are denied one level of appeal. Coordinators are discouraged from acting as echomail and software- distribution hubs. If they do so, they should handle echomail (or other volume distribution) on a system other than the administrative system. A coordinator's system should be readily available to the levels immediately above and below. Another reason to discourage multiple hats is the difficulty of replacing services if someone leaves the network. For example, if a coordinator is the echomail hub and the software-distribution hub, those services will be difficult to restore when that person resigns. 3.5 Be a Member of the Area Administered A coordinator must be a member of the area administered. That is, a Network Coordinator must be a member of that network by virtue of geography. A Regional Coordinator must be either a member of a network in the region or an independent in the region. A Zone Coordinator must be either a member of a network in the zone or a regional independent in the zone. The International Coordinator must be a Fidonet sysop. 3.6 Encourage New Sysops to Enter FidoNet A coordinator is encouraged to operate a public bulletin board system which is freely available for the purpose of distributing Policy, FidoNews, and Nodelists to potential new sysops. Dissemination of this information to persons who are potential FidoNet sysops is important to the growth of FidoNet, and coordinators should encourage development of new systems. 3.7 Tradition and Precedent A coordinator is not bound by the practices of predecessor or peers beyond the scope of this document and other applicable net, region or zone policies. In addition, a new coordinator has the right to review any decision made by predecessors for compliance with Policy, and take whatever actions may be necessary to rectify any situations not in compliance. FidoNews 10-14 Page: 31 05 Apr 1993 3.8 Technical Management The primary responsibility of any coordinator is technical management of network operations. Decisions must be made on technical grounds. 3.9 Review and Acceptance of Lower Policies Individual regions and nets are encouraged to formulate policies to deal with local issues not specifically covered in this document. It is the responsibility of coordinators to review policies submitted from lower levels for compliance with higher policies, and to support those policies whenever possible in deciding matters related to those areas. In the absence of procedures determined by local/regional policies, the coordinator should attempt to act in accordance with the interests and wishes of the majority of nodes in the affected area. 4 Network Coordinator Procedures 4.1 Responsibilities A Network Coordinator has the following responsibilities: 1) To receive incoming mail for nodes in the network, and arrange delivery to its recipients. 2) To assign node numbers to nodes in the network. 3) To maintain the nodelist segment for the network, and to send a copy of it to the Regional Coordinator whenever it changes. 4) To make available to nodes in the network new nodelist difference files, new issues of FidoNews, and new revisions of Network Policy Documents as they are received, and to periodically check to insure that nodes use up to date nodelists. 5) To make available to nodes in the network information regarding Fidonet elections and referenda, to solicit input from those nodes and to act as a representative of those nodes in such elections when appropriate. 4.2 Routing Inbound Mail It is your responsibility as Network Coordinator to coordinate the receipt and forwarding of host-routed inbound netmail for nodes in your network. The best way to accomplish this is left to your discretion. If a node in your network is receiving large volumes of mail you can request that the sysop contact the systems which are sending this mail and request that they not host-route it. If the FidoNews 10-14 Page: 32 05 Apr 1993 problem persists, you can request your Regional Coordinator to assign the node a number as an independent and drop the system from your network. Occasionally a node will make a "bombing run" (sending one message to a great many nodes). If a node in another network is making bombing runs on your nodes and routing them through your inbound host, then you can complain to the network coordinator of the offending node. (If the node is an independent, complain to the regional coordinator.) Bombing runs are considered to be annoying. Another source of routing overload is echomail. Echomail cannot be allowed to degrade the ability of FidoNet to handle normal message traffic. If a node in your network is routing large volumes of echomail, you can ask the sysop to either limit the amount of echomail or to stop routing echomail. You are not required to forward encrypted, commercial, or illegal mail. However, you must follow the procedures described in section 2.1.7 if you do not forward the mail. 4.3 Assigning Node Numbers It is your responsibility to assign node numbers to new nodes in your network. You may also change the numbers of existing nodes in your network, though you should check with your member nodes before doing so. You may assign any numbers you wish, so long as each node has a unique number within your network. You must not assign a node number to any system until you have received a formal request from that system by FidoNet mail. This will ensure that the system is minimally operational. The strict maintenance of this policy has been one of the great strengths of FidoNet. You may not assign a node number to a node in an area covered by an existing network. Further, if you have nodes in an area covered by a network in formation, those nodes must be transferred to the new network. You should use network mail to inform a new sysop of the node number, as this helps to insure that the system is capable of receiving network mail. If a node in your network is acting in a sufficiently annoying manner, you can take whatever action you deem appropriate, according to the circumstances of the case and due process. Notification must be given to the Regional Coordinator if that action taken is excommunication of a node. 4.4 Maintaining the Nodelist You should implement name changes, phone number changes, and so forth in your segment of the nodelist as soon as possible after FidoNews 10-14 Page: 33 05 Apr 1993 the information is received from the affected node. You should also on occasion send a message to every node in your network to ensure that they are operational. If a node turns out to be "off the air" with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to be marked DOWN for a maximum of two weeks, after which the line should be removed from the nodelist segment.) At your discretion, you may distribute a portion of this workload to routing hubs. In this case, you should receive the nodelist segments from the these hubs within your network. You will need to maintain a set of nodelist segments for each hub within your network, since you cannot count on getting an update from each hub every week. You should assemble a master nodelist segment for your network every week and send it to your Regional Coordinator by the day and time designated. It is suggested that you do this as late as is practical, so as to accommodate any late changes, balanced with the risk of missing the connection with your Regional Coordinator and thus losing a week. 4.5 Making Available Policies, Nodelists and FidoNews As a Network Coordinator you should obtain a new issue of FidoNews and a new nodelist difference file every week from your Regional Coordinator. The nodelist difference file is currently made available each Friday, and FidoNews is published each Monday. You must make these files available to all nodes in the network, and you are encouraged to make them available to the general public for download. You should also obtain the most recent versions of the Policy documents that bind the members of your network, and make those available to the nodes in your network. Policies are released at sporadic intervals, so you should also inform the nodes in your network when such events occur, and ensure the nodes are generally familiar with the changes. Policy, FidoNews, and the nodelist are the glue that holds us together. Without them, we would cease to be a community, and become just another random collection of bulletin boards. 5 Regional Coordinator Procedures 5.1 Responsibilities A Regional Coordinator has the following responsibilities: 1) To assign node numbers to independent nodes in the region. 2) To encourage independent nodes in the region to join existing networks, or to form new networks. 3) To assign network numbers to networks in the region and define their boundaries. FidoNews 10-14 Page: 34 05 Apr 1993 4) To compile a nodelist of all of the networks and independents in the region, and to send a copy of it to the Zone Coordinator whenever it changes. 5) To ensure the smooth operation of networks within the region. 6) To make new nodelist difference files, Policies, and issues of FidoNews available to the Network Coordinators in the region as soon as is practical. 7) To make available to Net Coordinators and independent nodes in the region information regarding Fidonet elections and referenda, to solicit input from the independent nodes and to act as a representative of those nodes in such elections when appropriate. 5.2 Assigning Node Numbers It is your responsibility to assign node numbers to independent nodes in your region. You may also change the numbers of existing nodes in your region, though you should check with the respective nodes before doing so. You may assign any numbers you wish, so long as each node has a unique number within your region. You should not assign a node number to any system until you have received a formal request from that system by FidoNet mail. This will ensure that the system is minimally operational. The strict maintenance of this policy has been one of the great strengths of FidoNet. You should use network mail to inform a new sysop of the node number, as this helps to insure that the system is capable of receiving network mail. If a node in your region is acting in a sufficiently annoying manner, you can take whatever action you deem appropriate, according to the circumstances of the case and due process. Notification must be given to the Zone Coordinator if the action taken is the excommunication of a node. If you receive a node number request from outside your region, you must forward it to the Regional Coordinator of the applicant's region. If you receive a node number request from a new node that is in an area covered by an existing network, then you must forward the request to the Coordinator of that network instead of assigning a number yourself. If a network forms in an area for which you have independent nodes, those nodes will be transferred to the local network as soon as is practical, unless those independent node assignments were made for reasons of high volume or commercial traffic. 5.3 Encouraging the Formation and Growth of Networks FidoNews 10-14 Page: 35 05 Apr 1993 One of your main duties as a Regional Coordinator is to promote the growth of networks in your region. You should avoid having independent nodes in your region which are within the coverage area of a network. There are, however, certain cases where a node should not be a member of a network, such as a system with a large amount of inbound netmail. See section 4.2. If several independent nodes in your region are in a local area you should encourage them to form a network, and if necessary you may require them to form a network. See section 2.4. 5.4 Assigning Network Numbers It is your responsibility to assign network numbers to new networks forming within your region. You are assigned a pool of network numbers to use for this purpose by your Zone Coordinator. As a part of this function, it is the responsibility of the Regional Coordinator to define the boundaries of the networks in the region. 5.5 Maintaining the Nodelist As a Regional Coordinator, you have a dual role in maintaining the nodelist segment for your region. First, you must maintain the list of independent nodes in your region. You should attempt to implement name changes, phone number changes, and so forth in this nodelist segment as soon as possible. You should also on occasion send a message to every independent node in your region to ensure that they are operational. If a node turns out to be "off the air" with no prior warning, you can either mark the node down or remove it from the nodelist segment. (Nodes are to marked DOWN for a maximum of two weeks, after which the line should be removed from the nodelist segment.) Second, you must receive the nodelist segments from the Network Coordinators within your region. You will need to maintain a set of nodelist segments for each network within your region, since you cannot count on getting an update from each Network Coordinator every week. You should assemble a master nodelist segment for your region every week and send it to your Zone Coordinator by the day and time designated. It is suggested that you do this as late as practical, so as to accommodate late changes, balanced with the risk of missing the connection with your Zone Coordinator and thus losing a week. 5.6 Geographic Exemptions There are cases where local calling geography does not follow FidoNet regions. In exceptional cases, exemptions to normal geographic guidelines are agreed upon by the Regional Coordinators and Zone Coordinator involved. Such an exemption is FidoNews 10-14 Page: 36 05 Apr 1993 not a right, and is not permanent. When a network is formed in the proper region that would provide local calling access to the exempted node, it is no longer exempt. An exemption may be reviewed and revoked at any time by any of the coordinators involved. 5.7 Overseeing Network Operations It is your responsibility as Regional Coordinator to ensure that the networks within your region are operating in an acceptable manner. This does not mean that you are required to operate those networks; that is the responsibility of the Network Coordinators. It means that you are responsible for assuring that the Network Coordinators within your region are acting responsibly. If you find that a Network Coordinator within your region is not properly performing the duties outlined in Section 4, you should take whatever action you deem necessary to correct the situation, up to and including removing the Net Coordinator from that position and having the net membership select a replacement. If a network grows so large that it cannot reasonably accommodate traffic flow during the Zone Mail Hour, the Regional Coordinator can direct the creation of one or more new networks from that network. These new networks, although they may be within a single local-calling area, must still conform to a geographical basis for determining membership. It is your obligation as Regional Coordinator to maintain direct and reasonably frequent contact with the networks in your region. The exact method of accomplishing this is left to your discretion. 5.8 Making Available Nodelists, Policies, and FidoNews As a Regional Coordinator, it is your responsibility to obtain the latest nodelist difference file, network policies, and the latest issues of FidoNews as they are published, and to make them available to the Network Coordinators within your region. The nodelist is posted weekly on Friday by the Zone Coordinator, and FidoNews is published weekly on Monday by the node indicated in the Fidonews and nodelist. Contact them for more details on how to obtain the latest copies each week. It is your responsibility to make these available to all Network Coordinators and independent nodes in your region as soon as is practical after you receive them. The method of distribution is left to your discretion. You are encouraged to make all these documents available for downloading by the general public. 6 Zone Coordinator Procedures 6.1 General FidoNews 10-14 Page: 37 05 Apr 1993 A Zone Coordinator for FidoNet has the primary task of maintaining the nodelist for the Zone, sharing it with the other Zone Coordinators, and ensuring the distribution of the master nodelist (or difference file) to the Regions in the Zone. The Zone Coordinator is also responsible for coordinating the distribution of Fidonet Policy documents and FidoNews to the Regional Coordinators in the zone. The Zone Coordinator is responsible for the maintenance of the nodelist for the administrative region. The Administrative Region has the same number as the zone, and consists of nodes assigned for administrative purposes not related to the sending and receiving of normal network mail. A Zone Coordinator is charged with the task of ensuring the smooth operation of the Zone. If a Zone Coordinator determines that a Regional Coordinator is not properly performing the duties outlined in section 5, whatever action deemed necessary may be taken, up to and including removing the Regional Coordinator from that position and having the nodes of the region select a replacement. The Zone Coordinator defines the geographic boundaries of the regions within the zone and sets the time for the Zone Mail Hour. The Zone Coordinator is responsible for creating new regions within the zone when regions become too large for efficient coordination by a single Regional Coordinator. The Zone Coordinator is responsible for reviewing and approving any geographic exemptions as described in section 5.6. The Zone Coordinator is responsible for insuring the smooth operation of gates between that zone and all other zones for the transfer of interzone mail. The Zone Coordinators are responsible for the selection of the International Coordinator. 6.2 Selection The Zone Coordinator is selected by a majority vote of the Net and Regional Coordinators within the zone, voting as representatives of their nodes (see section 8.3). 7 International Coordinator Procedures 7.1 General The International Coordinator has the primary task of coordinating the creation of the master nodelist by managing the distribution between the Zones of the Zone nodelists. The International Coordinator is responsible for definition of new zones and for negotiation of agreements for communication with FidoNews 10-14 Page: 38 05 Apr 1993 other networks. ("Other network" in this context means other networks with which FidoNet communicates as peer-to-peer, not "network" in the sense of the FidoNet organizational level.) The International Coordinator is also responsible for coordinating the distribution of Network Policies and FidoNews to the Zone Coordinators. The International Coordinator is responsible for coordinating the activities of the Zone Coordinator Council. The International Coordinator acts as the spokesman for the Zone Coordinator Council. In cases not specifically covered by this document, the International Coordinator may issue specific interpretations or extensions to this policy. The Zone Coordinator Council may reverse such rulings by a majority vote. These extensions are valid until such time as a policy referendum may be held to ratify or reject such extensions. 7.2 Selection The International Coordinator is selected (or removed) by an absolute majority vote of the Zone Coordinators with input from the Regional Coordinators. In the event that the Zone Coordinators are unable to select an International Coordinator by absolute majority, the International Coordinator will be selected by a majority of the Regional Coordinators. 8 Referenda The procedures described in this section are used to ratify a new version of FidoNet policy, which is the mechanism by which policy is changed. This procedure is also used to impeach a Zone Coordinator. 8.1 Initiation A referendum on policy modification is invoked when a majority of the FidoNet Regional Coordinators inform the International Coordinator that they wish to consider a proposed new version of Policy. 8.2 Announcement and Results Notification Proposed changes to Policy are distributed using the same structure which is used to distribute nodelist difference files and FidoNews. Results and announcements related to the referendum are distributed by the coordinator structure as a part of the weekly nodelist difference file. The International Coordinator provides copies to the editor of FidoNews for inclusion there, although the official announcement and voting dates are tied to nodelist distributions. If it is adopted, the International Coordinator sets the FidoNews 10-14 Page: 39 05 Apr 1993 effective date for a new policy through announcement in the weekly nodelist difference file and Fidonews. The effective date will be not more than one month after the close of balloting. 8.3 Eligibility to Vote Each member of the FidoNet coordinator structure at and above Network Coordinator is entitled to one vote. In the case of the position changing hands during the balloting process, either the incumbent or the new coordinator may vote, but not both. If a person holds more than one coordinator position, they still receive only one vote. Network Coordinators are expected to assess the opinions of the members of their network, and to vote accordingly. A formal election is not necessary, but the Network Coordinator must inform the net of the issues and solicit input. The Network Coordinator functions as the representative of the rank and file members of FidoNet. Regional Coordinators will fulfill this responsibility with regard to independent nodes in their regions. 8.4 Voting Mechanism The actual voting mechanism, including whether the ballot is secret and how the ballots are to be collected, verified, and counted, is left to the discretion of the International Coordinator. Ideally, ballot collection should be by some secure message system, conducted over FidoNet itself. In order to provide a discussion period, the announcement of any ballot must be made at least two weeks before the date of voting commencement. The balloting period must be at least two weeks. 8.5 Voting on a whole Policy Document or Amendments Policy may be changed as a whole document or by section as required. Sections changed must include all cross-references affected and the corresponding changes to those sections. Policy changes voted on as whole documents and approved will be incremented to the next whole number from the previous version number. Sectional changes (including multiple sectional changes approved in the same referendum) will increment the policy number to the next tenth of the current version number until nine tenths is reached. Sectional changes that would go beyond nine tenths will increment to the next whole number from the previous version number. 8.6 Decision of vote A Policy amendment is considered in force if, at the end of the balloting period, it has received a majority of the votes cast. For example, if there were 350 eligible voters, 100 of which cast a vote, then at least 51 affirmative votes would be FidoNews 10-14 Page: 40 05 Apr 1993 required to declare the amendment in force. In the case of multiple policy changes which are considered on the same ballot, a version must receive more than 50% of the votes cast to be considered ratified. 8.7 Impeachment of a Zone Coordinator 8.7.1 Initiation In extreme cases, a Zone Coordinator may be impeached by referendum. Impeachment of a Zone Coordinator does not require a Policy violation. An impeachment proceeding is invoked when a majority of the Regional Coordinators in a zone request the International Coordinator to institute it. 8.7.2 Procedure as in Policy Referendum The provisions of sections 8.2 and 8.3 apply to impeachment referenda. The definition of "majority" in section 8.6 applies. Only coordinators in the affected zone vote. 8.7.3 Voting Mechanism The balloting procedures are set, the votes are collected, and the results are announced by a Regional Coordinator chosen by the International Coordinator. The removal of the Zone Coordinator is effective two weeks after the end of balloting if the impeachment carries. 8.7.4 Limited to once per year The removal of a Zone Coordinator is primarily intended to be a mechanism by which the zone as a whole expresses displeasure with the way Policy is being interpreted. At one time or another, everyone is unhappy with the way policy is interpreted. In order to keep the Zone Coordinators interpreting policy as opposed to defending themselves, at least one full calendar year must elapse between impeachment referenda (regardless of how many people hold the position of Zone Coordinator during that year.) Should a Zone Coordinator resign during an impeachment process, the process is considered null and void, and does not consume the "once per year quota". 9 Resolution of Disputes 9.1 General The FidoNet judicial philosophy can be summed up in two rules: 1) Thou shalt not excessively annoy others. FidoNews 10-14 Page: 41 05 Apr 1993 2) Thou shalt not be too easily annoyed. In other words, there are no hard and fast rules of conduct, but reasonably polite behavior is expected. Also, in any dispute both sides are examined, and action could be taken against either or both parties. ("Judge not, lest ye be judged!"). It must be noted that it is someone's "behavior" (action) that is subject to this policy. The content of a person's words or opinions is not necessarily sufficient to be considered annoying in this context. Actions that would be considered excessively annoying behavior include activities that willfully disrupt the operations of one or more Fidonet systems; using non-existent or falsified node numbers with the intent of disguising the origin of mail traffic or of intercepting mail intended for the rightful owner of that node number; willfully compromising the integrity of an echomail conference after having direct links to that conference severed by the conference moderator; or illegal activities that involve, pertain to or utilize Fidonet as part of those activities. The first step in any dispute between sysops is for the sysops to attempt to communicate directly. Any complaint made that has skipped this most basic communication step will be rejected. Filing a formal complaint is not an action which should be taken lightly. Investigation and response to complaints requires time which coordinators would prefer to spend doing more constructive activities. Persons who persist in filing trivial policy complaints may find themselves on the wrong side of an excessively-annoying complaint. Complaints must be accompanied with verifiable evidence, generally copies of messages; a simple word-of-mouth complaint will be dismissed out of hand. Failure to follow the procedures herein described (in particular, by skipping a coordinator, or involving a coordinator not in the appeal chain) is in and of itself annoying behavior. 9.2 Problems with Another Sysop If you are having problems with another sysop, you should first try to work it out directly with the other sysop. If this fails to resolve the problem, you should complain to other sysop's Network Coordinator. If that sysop is not in a network, then complain to the appropriate Regional Coordinator. Should this fail to provide satisfaction, you have the right to follow the appeal process described in section 9.5. 9.3 Problems with your Network Coordinator If you are having problems with your Network Coordinator and feel that you are not being treated properly, you are entitled FidoNews 10-14 Page: 42 05 Apr 1993 to a review of your situation. As with all disputes, the first step is to communicate directly to attempt to resolve the problem. The next step is to contact your Regional Coordinator. If your case has merit, there are several possible courses of action, including a change of Network Coordinators or even the disbanding of your network. If you have been excommunicated by your Network Coordinator, that judgement may be reversed, at which point you will be reinstated into your net. If you fail to obtain relief from your Regional Coordinator, you have the right to follow the appeal process described in section 9.5. 9.4 Problems with Other Coordinators Complaints concerning annoying behavior on the part of any coordinator are treated as in section 9.2 and should be filed with the next level of coordinator. For example, if you feel that your Regional Coordinator is guilty of annoying behavior (as opposed to a failure to perform duties as a coordinator) you should file your complaint with the Zone Coordinator. Complaints concerning the performance of a coordinator in carrying out the duties mandated by policy are accepted only from the level immediately below. For example, complaints concerning the performance of Regional Coordinators would be accepted from Network Coordinators and independents in that region. Such complaints should be addressed to the Zone Coordinator after an appropriate attempt to work them out by direct communications. 9.5 Appeal Process A decision made by a coordinator may be appealed to the next level. Appeals must be made within two weeks of the decision which is being appealed. All appeals must follow the chain of command; if levels are skipped the appeal will be dismissed out of hand. An appeal will not result in a full investigation, but will be based upon the documentation supplied by the parties at the lower level. For example, an appeal of a Network Coordinator's decision will be decided by the Regional Coordinator based upon information provided by the coordinator and the sysop involved; the Regional Coordinator is not expected to make an independent attempt to gather information. The appeal structure is as follows: Network Coordinator decisions may be appealed to the appropriate Regional Coordinator. Regional Coordinator decisions may be appealed to the FidoNews 10-14 Page: 43 05 Apr 1993 appropriate Zone Coordinator. At this point, the Zone Coordinator will make a decision and communicate it to all affected parties. Zone Coordinator decisions may be appealed to the International Coordinator. The International Coordinator will make a decision and communicate it to all affected parties. Decisions of the International Coordinator may be reversed by a majority of the Zone Coordinators. If your problem is with a Zone Coordinator per se, that is, a Zone Coordinator has committed a Policy violation against you, your complaint should be filed with the International Coordinator, who will make a decision and submit it to the Zone Coordinator Council for possible reversal, as described above. A sample process is described in Appendix 3. 9.6 Statute of Limitations A complaint may not be filed more than 60 days after the date of discovery of the source of the infraction, either by admission or technical evidence. Complaints may not be filed more than 120 days after the incident unless they involve explicitly illegal behavior. 9.7 Right to a Speedy Decision A coordinator is required to render a final decision and notify the parties involved within 30 days of the receipt of the complaint or appeal. 9.8 Return to Original Network Once a policy dispute is resolved, any nodes reinstated on appeal are re- turned to the local network or region to which they geographically or technically belong. 9.9 Echomail Echomail is one of many uses of Fidonet. Echomail is treated as a use of Fidonet structure and is covered by Policy only to the extent that this use affects primary Fidonet operations. By its nature, echomail places unique technical and social demands on the net over and above those covered by this Policy. It should be noted that echomail distribution is a separate voluntary arrangement between consenting nodes and is distinctly different from the routing of netmail. In recognition of this, an echomail policy which extends (and does not contradict) general Policy, maintained by the Echomail Coordinators, and ratified by a process similar to that of this document, is recognized by the FidoNet Coordinators as a valid structure for dispute resolution on matters pertaining to echomail. 9.10 Case Histories FidoNews 10-14 Page: 44 05 Apr 1993 Some of FidoNet Policy is interpretive in nature. No one can see what is to come in our rapidly changing environment. While the history of previous complaints and decisions may be useful as guidance, each case must be decided on its own merits in the time and circumstances under which it occurs. 10. Credits, acknowledgments, etc. Fido and FidoNet are registered trademarks of Fido Software, Inc. Appendix -------- The Appendices of this document are exceptions to the normal ratification process and are included for information purposes. Appendix 1 may be changed by the appropriate Zone Coordinator, and other sections may be added or changed as needed by the International Coordinator. Appendix 1: Timing of Zone Mail Hour Zone Mail Hour is observed each day, including weekends and holidays. The time is based upon Universal Coordinated Time (UTC), also known as Greenwich Mean time (GMT). In areas which observe Daylight Savings Time during part of the year, the local time of zone mail hour will change because FidoNet does not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set for each zone by the Zone Coordinator. In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC. In each of the time zones, this is: Eastern Standard Time (GMT -5) 4:00 AM to 5:00 AM Central Standard Time (GMT -6) 3:00 AM to 4:00 AM Mountain Standard Time (GMT -7) 2:00 AM to 3:00 AM Pacific Standard Time (GMT -8) 1:00 AM to 2:00 AM Hawaii Standard Time (GMT -10) 11:00 PM to Midnight In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC. In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC. In each of the time Zones involved this is: GMT +12 Zone 6:00 AM to 7:00 AM (New Zealand) GMT +10 Zone 4:00 AM to 5:00 AM (East Australia, Papua New Guinea, Micronesia) GMT +9.5 Zone 3:30 AM to 4:30 AM (Central Australia) GMT +8 Zone 2:00 AM to 3:00 AM (Western Australia) In Fidonet Zone 4, Zone Mail Hour is observed from 0800 to 0900 UTC. FidoNews 10-14 Page: 45 05 Apr 1993 GMT -3 Zone 5:00 AM to 6:00 AM GMT -4 Zone 4:00 AM to 5:00 AM GMT -5 Zone 3:00 AM to 4:00 AM In Fidonet Zone 5, Zone Mail Hour is observed from 0100 to 0200 UTC. GMT +0 Zone 1:00 AM to 2:00 AM GMT +1 Zone 2:00 AM to 3:00 AM GMT +2 Zone 3:00 AM to 4:00 AM GMT +3 Zone 4:00 AM to 5:00 AM In Fidonet Zone 6, Zone Mail Hour is observed from 2000 to 2100 UTC. In each of the time zones involved this is: GMT +9 Zone 5:00 AM to 6:00 AM (Japan, Korea, Eastern Indonesia) GMT +8 Zone 4:00 AM to 5:00 AM (Hong Kong, Taiwan, Central Indonesia, Philippines) GMT +7 Zone 3:00 AM to 4:00 AM (Malaysia, Singapore, Thailand, Western Indonesia) Appendix 2: Sample Election Procedure 1. Qualifications and Terms The Coordinator serves a term of one year and may serve any number of consecutive terms. Any sysop listed in the appropriate segment of the Fidonet Nodelist at the time nominations are opened is eligible to run. A simple majority (50% + 1) of votes cast is required to elect a Coordinator. In the event that no candidate received a majority of votes, a run off election will be held between the two candidates with the greatest number of votes. 2. Nominations Nominations may be made either in a designated echo or by netmail to the election coordinator. Any netmail nominations received by the election coordinator will be cross-posted into the designated echo. Any sysop listed in the appropriate segment of the Fidonet nodelist may nominate any other eligible sysop for the position of Coordinator. Nominees must announce their consent to serve in order to be considered candidates in the election, and are encouraged to be available for discussion during the election process. A minimum of two weeks will be allotted for the nominating process. 3. Election Coordinator At the start of the election process, the appropriate Coordinator will appoint a non-candidate sysop as Election Coordinator. This sysop will have several responsibilities: FidoNews 10-14 Page: 46 05 Apr 1993 Collecting nominations, seconds and statements of consent to serve from netmail and the designated echo and finalizing the election slate. Posting the slate of candidates and the voting format instructions in the designated echo at the close of nominations. Submitting the slate of candidates and the voting format instructions to the Coordinator for distribution via netmail to all Net and/or Regional Coordinators. Collecting and tabulating votes submitted. Notifying the Coordinator of the election results and posting the election results in the designated echo. 4. Discussion Period Following the close of nominations and presentation of the slate of candidates, a minimum of two weeks will be allotted for discussion before voting begins. 5. Voting Procedures Net Coordinators in each net will distribute the slate of candidates, voting instructions and voting schedule to all members of their nets via netmail. Votes must be cast by the node sysops via netmail to the Election Coordinator. Due to changing technology, the exact format and mechanism of placing these votes will be determined by the Election Coordinator at the time of each election. Once a vote has been received and validated, it may not be changed. The Election Coordinator will announce the final counts within seven days of the close of voting. Challenges to the accuracy or completeness of the announced results must be placed via netmail to the Election Coordinator within seven days of the announcement of the results. A successful challenge will necessitate a new election to be initiated. 6. Installation of New Coordinator The newly elected Coordinator will be installed in the nodelist as soon as the transfer of control files and other necessary information can be coordinated between the incoming and outgoing Coordinators, but not later than two weeks from the announcement of final election results. Appendix 3: Sample Process for Resolution and Appeal of Complaints FidoNews 10-14 Page: 47 05 Apr 1993 The process of complaint and appeal available to all Fidonet members, as delineated in sections 9.1 through 9.8, follows a step by step procedure from the point at which a complaint has been filed. 1. Offender does something to warrant removal from Fidonet. 2. The Net Coordinator points out this activity to the offender and offers the opportunity to refrain. 3. The Net Coordinator records the response of the offender. 4. If the offender desists, the case is over. Otherwise; 5. The Net Coordinator issues a final warning to the offender stating that the nodelist entry will be removed permanently unless immediate cessation of the offense(s) follows this final warning. Repeating at a later date an offense for which a warning was previously given may be considered refusal to comply. 6. If the offender desists, the case is over. Otherwise; 7. The Net Coordinator notifies the offender of removal from the nodelist. 8. Net Coordinator records offender's final response (if any) and removes offender's node number from the nodelist if no new information is received. 9. Net Coordinator advises Regional Coordinator of complete chronology with documentation and the case is closed, or; 10. The offender appeals to the Regional Coordinator and offers other information contrary to the Net Coordinator's account and requests intervention and/or investigation. 11. If the Regional Coordinator refuses the appeal, the case is over. Otherwise; 12. The Regional Coordinator agrees to consider the appeal and advises the Net Coordinator to refrain from removal pending investigation of the appeal. 13. The Regional Coordinator finds appeal has no merit, advises Net Coordinator to proceed with node removal, and advises offender of finding and of the option to appeal to the Zone Coordinator, or; 14. The Regional Coordinator finds appeal has merit and advises Net Coordinator to retain the node's number and to appeal to the Zone Coordinator if unsatisfied. 15. Steps 10 through 14 may be repeated at the Zone Coordinator and International Coordinator levels if necessary. FidoNews 10-14 Page: 48 05 Apr 1993 Appendix 4: Fidonet Technical Standards The Fidonet Technical Standards Committee (FTSC) is a deliberative body charged with developing and maintaining technical standards for operations in a Fidonet Technology Network (FTN). All software used in Fidonet communications must be in compliance with the appropriate standards, which include: FTS-0001 A basic Fidonet technical standard, R Bush FTS-0002 (superseded by FTS-0005) FTS-0003 (superseded by FTS-0006) FTS-0004 Echomail specifications, B Hartman FTS-0005 The distribution nodelist, B Baker, R Moore FTS-0006 YOOHOO and YOOHOO/2U2, V Periello FTS-0007 SEAlink protocol extension, P Becker FTS-0008 Bark file-request protocol extension, P Becker FTS-0009 Message identification and reply linkage, j nutt Appendix 5: File Name Conventions For those systems accepting file requests via Fidonet, it is generally accepted practice that certain types of information will be available under commonly known alias names. The following are common file aliases: FILES List of files available for file request ABOUT Information about the individual system NODELIST Current full Fidonet nodelist NODEDIFF Current weekly Fidonet nodelist difference file FIDONEWS Current weekly issue of Fidonews POLICY Fidonet policy documents ---------------------------------------------------------------------- ======================================================================== Fidonews Information ======================================================================== ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ---------------- Editors: Sylvia Maxwell, Donald Tees, Tim Pozar Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello, Tom Jennings IMPORTANT NOTE: The FidoNet address of the FidoNews BBS has been changed!!! Please make a note of this. "FidoNews" BBS FidoNet 1:1/23 <---- NEW ADDRESS!!!! BBS +1-519-570-4176, 300/1200/2400/14200/V.32bis/HST(DS) Internet addresses: Don & Sylvia (submission address) editor@exlibris.tdkcs.waterloo.on.ca Sylvia -- max@exlibris.tdkcs.waterloo.on.ca FidoNews 10-14 Page: 49 05 Apr 1993 Donald -- donald@exlibris.tdkcs.waterloo.on.ca Tim -- pozar@kumr.lns.com (Postal Service mailing address) (have extreme patience) FidoNews 172 Duke St. E. Kitchener, Ontario Canada N2H 1A7 Published weekly by and for the members of the FidoNet international amateur electronic mail system. It is a compilation of individual articles contributed by their authors or their authorized agents. The contribution of articles to this compilation does not diminish the rights of the authors. Opinions expressed in these articles are those of the authors and not necessarily those of FidoNews. Authors retain copyright on individual works; otherwise FidoNews is copyright 1993 Sylvia Maxwell. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or FidoNews (we're easy). OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic form may be obtained from the FidoNews BBS via manual download or Wazoo FileRequest, or from various sites in the FidoNet and Internet. PRINTED COPIES may be obtained from Fido Software for $10.00US each PostPaid First Class within North America, or $13.00US elsewhere, mailed Air Mail. (US funds drawn upon a US bank only.) BACK ISSUES: Available from FidoNet nodes 1:102/138, 1:216/21, 1:125/1212, (and probably others), via filerequest or download (consult a recent nodelist for phone numbers). A very nice index to the Tables of Contents to all FidoNews volumes can be filerequested from 1:396/1 or 1:216/21. The name(s) to request are FNEWSxTC.ZIP, where 'x' is the volume number; 1=1984, 2=1985... through 8=1991. INTERNET USERS: FidoNews is available via FTP from ftp.ieee.org, in directory ~ftp/pub/fidonet/fidonews. If you have questions regarding FidoNet, please direct them to deitch@gisatl.fidonet.org, not the FidoNews BBS. (Be kind and patient; David Deitch is generously volunteering to handle FidoNet/Internet questions.) SUBMISSIONS: You are encouraged to submit articles for publication in FidoNews. Article submission requirements are contained in the file ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable from 1:1/23 as file "ARTSPEC.DOC". Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, Box 77731, San Francisco CA 94107, USA and are used with permission. FidoNews 10-14 Page: 50 05 Apr 1993 Asked what he thought of Western civilization, M.K. Gandhi said, "I think it would be an excellent idea". -- END ----------------------------------------------------------------------